Europe has a long tradition of data protection: The Data Protection Directive was issued in 1995 and was in effect for more than 20 years before it was replaced by the General Data Protection Regulation (GDPR). However, regional data protection cannot permit unhindered flows of personal data into areas with lesser protection. The GDPR permits transfers to countries without adequate protection only under certain conditions, i.e. the data exporter must take appropriate precautions.

The EU and the USA had therefore reached an agreement: Data importers in the USA could certify themselves according to the requirements of the Safe Harbor agreement and were then considered safe recipients. However, the Safe Harbor Agreement was terminated by a ruling of the European Court of Justice, following a complaint of Max Schrems, an Austrian data protection activist (Schrems I ruling). The EU and the USA replaced it with an improved agreement called the Privacy Shield. Switzerland followed this in each case which is why there was also a CH-US Privacy Shield that allowed transmissions from Switzerland to certified recipients in the USA.

The European Court of Justice abolished the Privacy Shield with immediate effect in its ruling from July 2020 (Schrems II ruling). It concluded that US law allows too extensive access to data with too little legal protection.

As an alternative to the Privacy Shield, the data exporter and the data importer could enter data transfer contracts. This happened almost always on the basis of a set of contracts recognized by the EU, the so-called Standard Contractual Clauses (or Model Clauses). These clauses have not been abolished by the European Court of Justice. But the ECJ has raised serious concerns since an agreement with a US importer cannot prevent access by the authorities. These concerns also apply to all other unsafe states and the Federal Data Protection and Information Commissioner (FDPIC) also believes that these clauses can only be sufficient in exceptional cases.

It is clear that the fundamental problem of undesired data access cannot be solved by contracts alone. Therefore, technical measures are focused that prevent such data access or at least make it more difficult. Access protection by means of data encryption is one of the most important measures and is widely used. The FDPIC also expressly referred to BYOK (Bring Your Own Key) and BYOE (Bring Your Own Encryption). This article covers the most common terms and measures related to the encryption of data located in the cloud or off-premises, respectively.

Data Encryption in the Cloud

For the following sections, it is useful to remember some basic principles of data encryption. Simply put, the goal of data encryption in this context is to protect data from unauthorized access. This is achieved by transforming data into an unreadable form so that it can only be converted back into its readable from by authorized parties. In the field of cryptography, the following terms are used:

Data can be stored (data at rest), processed (data in use) or transported (data in motion). Naturally, data must also be protected while in motion for example by means of transport encryption. However, transport encryption will not be discussed further in the following chapters since corresponding measures such as using TLS or VPNs have been well established independently of cloud applications.

The goal that data can only be read by authorized parties is achieved by making the key required for its decryption accessible to only these parties. The management and protection of cryptographic keys is therefore extremely important. This brief observation alone already suggests that some practical challenges arise:

• Who generates the keys?
• How are they disseminated to authorized parties in a secure way, without being compromised by others?
• How can the secrecy of the keys be guaranteed while they are in use?
• What must be done in case the keys fall into the wrong hands or get lost?

Besides the challenges of key management, the following facts are important for the subsequent considerations:

• The encryption and decryption of data always requires using a key. If these processes are performed in the cloud, the corresponding cloud application or encryption function must be able to access the key.
• Processing encrypted data always follows this principle: Read encrypted data → decrypt data → process data → encrypt and store data. During these processes, data that is encrypted or decrypted is present in plain text in the memory of the system that performs these processes.
• Encrypted data cannot be interpreted in terms of its content (which is precisely the purpose of encryption), therefore cloud applications can usually not process encrypted data.

Hardware Security Modules (HSM)

Cryptographic processes are often performed in software, i.e. within an application or by an operating system. A complete isolation of these processes from other processes on the same system cannot be achieved by this. A system administrator can access the systems memory and influence the cryptographic process or read the data or the encryption key. Hardware security modules can be used to reduce this attack surface.

An HSM is a specialized hardware device for cryptographic applications. A software application can communicate with the HSM via an interface and use its cryptographic functions. These are mainly the secure generation and management of cryptographic keys as well as all processes that use these keys. It is essential that the secret keys are generated in the HSM and never leave it. HSMs therefore have a number of protection measures implemented.

Several cloud providers enable their customers to use HSMs. The HSM itself is managed by the cloud provider, but the customer can use its functionalities. For example, HSM-based key management in the cloud could be implemented this way. To be able to rely on the security provided by an HSM, one must also be able to rely on the fact that the protected keys can never leave the HSM. It is therefore advisable to check exactly how the keys are generated, managed and used for each application that uses the HSM.

Bring Your Own Key (BYOK)

The term BYOK refers to a model in which the customer or the data owner generates and uses its own cryptographic keys and ideally has sole access to them. However, the BYOK model has weaknesses and practical challenges that are important to know:

• The generation of key material outside of the cloud provider requires a secure transport of these keys into the corresponding cloud application. Various manufacturers of hardware security modules offer solutions that promise that the key material transported and imported into the cloud is always reliably protected during this entire process. However, this requires the use of hardware supported by the cloud provider and results in additional administrative effort.
• At the time of processing, the data resides as plain text in the memory of the processing system. Parties with access to the systems memory such as the cloud provider’s system administrators can therefore read this data. This also holds true when using an HSM because although the data is encrypted and decrypted in the HSM, processing by applications takes place outside of the HSM.
• When HSMs are not used, the key is also present in the system’s memory and can also be read by parties with access to it.
• Even if an HSM is deployed an application can use it in an insecure way, for example by using key material outside of the HSM.
• The actual encryption process with or without an HSM takes place in the cloud, i.e. in systems that are controlled by the cloud provider. The cloud provider could install backdoors for unauthorized data access or use its own encryption keys.

Bring Your Own Encryption (BYOE)

A pure BYOK model allows control over the keys, but not over the cryptographic algorithms. Bring Your Own Encryption (BYOE) differs from that by adding the possibility to manage the cryptographic algorithms. There are even solutions that allow to bring in your own cryptographic functionalities. From a security point of view, these additional control options play an insignificant role and the above points are also largely applicable for a BYOE model.

Hold Your Own Key (HYOK)

Several cloud service providers have developed more advanced models allowing for higher degrees of data confidentiality. One of them is called Hold Your Own Key (HYOK) and refers to a process where data is encrypted before it even enters the cloud and the key material is not transferred to the cloud.

The goal of this model is to prevent the plain text data from ever entering the cloud. Provided that a proper implementation is used, this is can be a suitable approach to prevent unwanted data access. However, it usually causes serious impacts on the functionality of cloud applications. Because the data content is completely inaccessible to the cloud provider, a fact sometimes called data opacity, most applications work only partially or not at all. For this reason, this method is typically only used for a few, selected data areas, for example individual documents or sensitive fields in a database. On the other hand, data that only needs to be stored and in the cloud and doesn’t require cloud processing can easily be encrypted before it is transferred to the cloud. An example for this would be storing encrypted backups in the cloud.

Double Key Encryption

Double Key Encryption is a term used by Microsoft for a data encryption model that uses two different keys. One is under the control of Microsoft, the other one is controlled by the cloud user only. From a security perspective, this model differs only slightly from the HYOK model. Here too, the challenge lies in the fact that the cloud applications cannot read the data content and therefore function only partially or not at all.

Tokenization

Tokenization replaces plain text data with irreversible, non-sensitive placeholders (tokens). In contrast to encryption, tokenization does not use a key in conjunction with a mathematical algorithm to transform sensitive data. With tokenization, it is possible to ensure that the replaced data has the same length and data type as the original data. This is a clear advantage over data encryption since data tokenized in this way can be processed by cloud applications, unlike traditionally encrypted data. However, there are also disadvantages. While tokenization can be used quite well for structured data fields such as credit card numbers, it is not well suited for unstructured data such as entire documents.

Instead of a key, tokenization uses a mapping table (sometimes called token database or token vault) to associate the plain text data with the tokens. These mapping tables can grow large and can have negative effects on application performance. Tokens can only be transformed back into the original data by accessing the mapping table while encrypted data only needs the correct key to be decrypted. Therefore, tokenized data can be less suited for sharing with authorized parties than encrypted data but tokenization can be combined with encryption.

Tokenization is commonly implemented by using specialized on-premise solutions. To enable applications to correctly process tokenized data, the tokenization solution must specifically support the respective applications.

Comparison of the Encryption Models

The following table summarizes important properties of the described encryption models, assuming their correct implementation.

* The keys could also be generated without using an on-premise HSM and could then be transferred to the cloud but this would seriously compromise their confidentiality.

Conclusion

When used correctly, all described models can help to increase data protection the cloud. However, none of them provides complete protection against third-party access or can result in a severe impact on the functionality of cloud applications. It is therefore necessary to carefully analyze the relevant threat scenarios and threat actors and to choose the most suitable model on this basis. For example, a Bring Your Own Key scenario can effectively protect against unauthorized access to data at rest, but it cannot prevent access by the cloud provider. Comprehensive protection of data essentially always requires a combination of different measures and must cover the entire data life cycle.

Aside from specific scenarios such as storing data in the cloud, using cloud applications while completely protecting data against any undesired access are two goals that are ultimately incompatible. Therefore, marketing promises should not be blindly trusted and a risk-based approach with a carefully selected balance between functionality and data protection is required.

About the Author

Tomaso Vasella has a Master in Organic Chemistry at ETH Zürich. He is working in the cybersecurity field since 1999 and worked as a consultant, engineer, auditor and business developer. (ORCID 0000-0002-0216-1268)

Links

• https://docs.microsoft.com/en-us/azure/information-protection/configure-adrms-restrictions
• https://docs.microsoft.com/en-us/microsoft-365/compliance/double-key-encryption