CLOUD Act, GDPR Changing Data Protection Game
GDPR is yesterday’s news; the CLOUD Act also poses challenges for companies in Europe: U.S. authorities may also access data that is physically located in Europe if it has been processed or stored by U.S. hosting or cloud providers, or their branches in other countries. U.S. providers, therefore, recommend that their customers technically disguise data. But does this protect data from being accessed?
In addition to the providers themselves, the General Data Protection Regulation (Art 32) also points out that personal data must either be encrypted or pseudonymized. Both options pose a challenge for data in the cloud.
Encryption: Where is the Key?
When encrypting or decrypting data, a key should always be kept at hand—and should be kept secret. This begs the question of how such a key can be securely transferred to the cloud or discreetly managed. There are two competing approaches here.
Bring Your Own Key
BYOK, or Bring Your Own Key, is the idea that customers store encrypted data on the platform of a cloud provider and generate the key themselves. Ideally, only the customer can access the key. However, a pure BYOK solution has weak points because the cloud provider has the encryption software used, and thus, the possibility of generating a master key itself. This allows the provider to decrypt encrypted data. The provider may even have to grant authorities in the country in which they are based access to the encryption. The CLOUD Act does not explicitly require cloud providers to decrypt data, but it also does not specifically prohibit it. Otherwise, the protective purpose of this rule—namely, to obtain certain data—would be ineffective. That is why providers can be involved in data decryption without being in violation of the CLOUD Act.
The cloud provider also has the server hardware used for storage. As soon as data is decrypted in the cloud, both the key and the data to be processed must inevitably be transferred to the server’s main memory. Anyone with physical or virtual access to the server or the operating system can copy the main memory, extract decrypted data or fish out the key.
Bring Your Own Encryption
BYOE, or Bring Your Own Encryption, goes one step further. Here the customers don’t just generate the key; they also obtain and manage a suitable crypto-algorithm. Encryption is no longer the responsibility of the cloud provider. However, commercial encryption tools do have a drawback; their source code is not usually disclosed. As such, nobody knows if there are back doors built into these commercial solutions.
If open source is used for encryption, customers will at least usually find clean code. However, it should be noted that open source tools for encryption usually only offer single-user solutions. They do not allow groups or administration of different keys. Moreover, they are often not as easy and smoothly integrated to use as the GDPR prescribes for “privacy by design.”
In conclusion, there is no perfect solution for all encryption requirements in the cloud. In addition, some regulators classify encryption in the cloud as unacceptable because it is mathematically reversible and can be intercepted in the cloud.
Tokenization
Compared to encryption, tokenization is a fundamentally different approach to pseudonymization. Here, pseudonymized values are randomly assigned to the original values and this modified data is transferred to the cloud instead of the original. The primary risk of decryption is lower, especially since there is no mathematical relationship between the original and the encryption value. The actual data, as well as the token mapping table, is then usually stored in the physical control area of the company with a need for secrecy.
At second glance, however, this procedure is also a drawback. Without a token mapping table, tokens can never be used to assign pseudonymized and original data. Anyone who hijacks this token mapping table can then tamper with the data themselves to change the assignment or link.
Encoding the token mapping table increases its relative security. As a consequence, the speed and convenience of data processing will suffer. SaaS or IoT applications can’t be operated in this way. And whether encrypted or hidden by token, metadata generated around data processing is always readable.
Solution: The Right Cloud Provider
Neither encryption nor tokenization offers absolute security. The combination of both technologies, i.e., the correct key handling paired with the use of tokens, already affords an acceptable level of protection. However, a prerequisite also must be met here: The customer should choose a hosting or cloud service provider that cannot be legally forced to make pseudonymized data readable. For example, the U.S. CLOUD Act does not prohibit U.S. cloud providers from decrypting data—on whatever terms. The current Huawei case shows that U.S. authorities are not afraid to block foreign software and hardware. German and European providers have to act more in the interests of the customer. And the GDPR, as the sole legal regulation, forces all data-processing companies to exercise the greatest possible care in the interest of the customer.
