GDPR Compliance Analysis of Functional Encryption
How can we use technological approaches to process data while protecting data privacy according to GDPR?
Joint work with Mats Kockmeyer.
Since the European General Data Protection Regulation (GDPR) has come into effect in 2018, data processors are committed to fulfill stricter requirements to process personal data in the European Union. As a result of the GDPR, the legal data processing opportunities in the traditional way will be highly restricted to protect the privacy of natural persons (data subject). Because of that, we will verify the GDPR compliance of some new technical approaches for processing personal data with reference of the effort to ensure privacy. In this article, we give a brief overview of the approach for practical application. In the course of that, we expound what anonymization and pseudonymization means. To get a versatile impression, we will take a look at the Functional Encryption as a cryptographic and Intel’s Secure Guard Extension (Intel SGX) as a system security technology.
Introduction
In these days, data is power. Therefore, it is important to regulate companies with the handling of personal data. This essential was implemented in the GDPR at the European level. Individual countries can extend this regulation with national law. The GDPR refers only to data of natural persons. This is an important aspect for the processing of data, that should be GDPR compliant.
Meaning of personal data
Data are considered to be personal if it is related to a natural person (defined in the GDPR article 4 section 1). Examples of this data are name, identification number, address, online information, physical or psychological aspects, cultural and social identification.
- Pseudonymized data are personal data, which are alienated. Thus, it is not possible to identify a natural person directly. In order to recover the identity of the data subject, the data processor needs some additional information. This kind of data is covered by the GDPR.
Figure 1 shows an example of pseudonymization. In order to pseudonymize a customer record, it is necessary to separate the personal information that enables direct identification. In this case, the name (firstname, lastname) is kept separately. In order to restore a reference between the data types, key information is required.
- Anonymized data are not related to natural persons and is not covered by the GDPR. In other words, this kind of data can be processed without any confirmation of the originally data subject.
Anonymization is exemplarily shown in Figure 2. In order to make a customer data record anonymous, it is necessary to completely remove all identifiers. In this case, the firstname and lastname are removed so that the remaining information cannot be assigned to a natural person and is therefore considered anonymous.
Strictness of the GDPR
A GDPR sets an approximate frame, which is necessary because of the regulation that cannot keep up with the rapid technological development of modern times due to the approval period. However, in order to practical orientation, this frame is more precisely defined by valid case law. There are two approaches to interpret the GDPR.
- The absolute approach considers all possibilities for the data processor to identify a data subject. Proportionality does not matter. It is assumed that each data processor has the maximum resources so that every theoretical chance is covered.
- The relative approach considers proportional possibilities for the data processor to identify a data subject. Under this approach, encrypted data, in particular, are only covered by the GDPR if the data processor is able to decrypt the data.
Recent publications compare the interpretation of GDPR and its strictness and show the tendency that the relative approach will apply [1, 3].
Encrypt to Anonymize
Regarding the relative interpretation of the GDPR, encrypt data is a possible way to anonymize data under the condition that the decryption key is no longer in the possible access of the data controller [4]. This finding leads to the idea to use a mechanism in the data processing, which restricts the access to personal data in order to that the resulting anonymous data no longer fall under the scope of the GDPR.
GDPR Compliance Analysis
In the following section we will recall two privacy-preserving techniques, one known as functional encryption whose security is based on cryptographic intractability assumptions and the other one being Intel’s secure enclave technology. Its security is based on hardware assumptions. We refer the reader to [2, 3] for additional information on the technologies.
Functional Encryption
First of all, the well-known public-key cryptography is briefly repeated to subsequently understand the extension of the functional encryption concept. The central component of a public-key cryptography system is the split of the decryption and encryption functions into two different keys. In a minimal setting, a PK system consists of three algorithms:
- Setup(λ) = (PK, SK)
The Setup algorithm takes the security parameter λ as input and outputs a public key PK for encryption and a secret key SK for decryption. - Enc(x, PK) = c
The Enc algorithm takes the information x and the public key PK as input and outputs the ciphertext c. - Dec(c, SK) = x
The Dec algorithm takes the ciphertext c and the secret key SK as input and outputs the plain text x.
The result is always binary. Either the participant is able to decrypt the cipher text and get all information or nothing. In functional encryption, there is no longer “one key” to decrypt the ciphertext, but many function-related secret keys that can produce different decryption results from a ciphertext. For example, it is possible to extract only the first three bits of a plain text. Especially for this purpose, there exists a function f and an associated secret key SK_f. The associated secret key is bounded and not applicable for another function. Furthermore, the participants should not be able to combine their keys to get access to resources that are not approved (this would be a collusion attack).
Let’s shape the functional encryption into algorithms.
- Setup(λ) = (MK, PK)
The Setup algorithm takes a security parameter λ as input and outputs a master key MK, which could be used to generate function-related secret keys and the public key PK. - Gen(MK, F) = (SK_f)
The Gen algorithm takes the master key MK and the function F as input and outputs the function related secret key SK_f. - Enc(PK, x) = c
The Enc algorithm takes the information x and the public key PK as input and outputs the cipher text c. - Dec(SK_f, c) = d
The Dec algorithm takes the cipher text c and the secret key SK_f as input and outputs the part information d=f(x). Note that the result d can also contain only a fraction of the actual information x.
Consider the following example: There is an encrypted customer record and a key SK_lastOrder for using the function f_lastOrder. The result of the function is exactly the lastOrder. Since the key can only be applied to this specific function, no further information can be obtained from the encrypted data set.
The access to individual information of a cipher can be controlled in great detail by the functional encryption. This property can be used to perform GDPR compliant data processing under the relative approach. Assuming that strong encryption has been selected, the data can initially be considered anonymously unless the decryption keys are known. Without any decryption key, there is no relative possibility of decrypting the data.
Anonymize Data with functional Encryption
If the Master Key MK is unknown to the data processor, the data processor cannot derive its own (functional) keys. As a result, only the functions whose function-dependent key is known can be used. If the desired result is to anonymize data, then encrypting the data is necessary plus the assurance that functional keys are issued that do not leak personal data (e.g. figure 3).
Pseudonymize data with functional Encryption
The GDPR conformity of the pseudonymized data can also be realized. For this purpose, it is assumed that two different keys are generated for a record. The key SK_anonymized allows access to all data that cannot be assigned directly to a person. The key SK_personal allows access to the personal data.
Under the assumption that the keys for the personal data are kept separately by organizational measures, we conclude that the requirements for GDPR compliant data processing are met.
Our research concludes that functional encryption is GDPR-compliant, if the underlying cryptographic hardness is valid.
Intel SGX
A different approach to process data GDPR compliantly is the system security solution using Intel SGX. In the 3rd quarter of 2015, the security extension has been introduced as part of the Skylake architecture. SGX provides a trusted platform for data processing and offers fast, scalable algorithms and security measures implemented in hardware.
Structure
In order to understand the functionality of Intel SGX and the deployment in the existing applications, the following components are essential:
- Dynamic random access memory (DRAM)
DRAM is volatile memory, which is contained in any computer. The components of Intel SGX are stored in the DRAM. - Processor Reserved memory (PRM)
PRM is a secure reserved memory on the DRAM, that is allocated when the system is starting. This area contains the EPC with the enclaves and their associated data. Access to the PRM is only possible through the CPU. - Enclave Page Cache (EPC)
For each enclave, the EPC handles the SGX Enclave Control Structure (meta Data like hash and size, SECS) and the Thread Control Structure (execution point into a enclave, TCS). However, the Version Array Page (VA Page) is a global directory. - Memory Management Unit (MMU)
The MMU is the only trusted unit, which regulates the access to the PRM and the contained enclaves. If unauthorized access occurs, the MMU redirects the request to a non-persistent memory or sends a signal fault. - Memory Encryption Engine (MEE)
The MEE handles the en- and decrypted tasks for the CPU.
The goal of the Intel SGX platform is to provide a secure environment. To ensure this, the developed programs must comply with the Intel SGX Program Guideline Policy. In order to fulfill the conditions, a program (more precisely, the program instructions in the memory) is divided into two parts:
- Secure
This component is called enclave and stored in the EPC. Enclaves are not allowed to communicate with each other directly. - Unsecure
This component is called enclave application and is stored in the unsecure DRAM. The insecure part acts as an interface to the secure part.
Secret Key for data en-/decrypted operations
The data is encrypted with AES, a symmetric encryption scheme. Thus the same key is used for en- and decryption. Due to the hardware implementation, the algorithm is very efficient in comparison to a pure software implementation [5]. The enclave exclusive secret key for encryption and decryption is derived from the two anchored secrets (Seal Secret and Provisioning Secret) inside the CPU. It should be mentioned that the entity Intel must be trusted, because they may be aware of the Provisioning Secret during the production. This key is used as input for the undocumented process that generates the Master Derivation Key. On the other hand, the Seal Secret is generated inside the CPU and therefore not known to Intel.
According to current state of knowledge, it is not technically possible to access the key from the CPU. To extract the key of the CPU, it would require a forensic investigation or physical access. We refer the reader to [6, 7] for additional information about possible attack examples, like cache attacks.
What is about the GDPR?
Intel SGX decrypts data within the enclave at runtime. For all other entities, the data is encrypted so that no external data access appears possible. Due to the fact that the data can only be decrypted inside the CPU, the relative approach of the GDPR is fulfilled, because there is no other relative possibility to decrypt the data, at least as long as the secret key is not leaked for AES encryption. Therefore, the data can be considered as anonymized. As a result of that, enclaved data does not fall under the protection of the GDPR. This claim is valid, if and only if AES is secure encryption scheme.
Our research concludes that enclaved data is GDPR-compliant, as long as the hardware implementation of AES is secure.
Use Case Implications — Saving Data Center Costs
Consider the following example. A company can outsource calculations on personal data to a data center without the data center being able to gain knowledge about the data. Intel SGX provides a secure platform. The concrete calculations are carried out inside the enclave. The data, which is located within this zone, appears to the operator of the data center as anonymous, because it is encrypted. As it is well known, encryption is a possible method of anonymizing data so that it no longer falls within the scope of the GDPR. Finally, it is no longer necessary for the company to conclude a data processing contract with the data center. This also means that data can be processed outside the European Union without violating the GDPR.
References
[1] Spindler, G., & Schmechel, P. (2016). Personal data and encryption in the European general data protection regulation. J. Intell. Prop. Info. Tech. & Elec. Com. L., 7, 163.
[2] Boneh, D., Sahai, A., & Waters, B. (2012). Functional encryption: a new vision for public-key cryptography. Communications of the ACM, 55(11), 56–64.
[3] Costan, V., & Devadas, S. (2016). Intel SGX Explained. IACR Cryptology ePrint Archive, 2016(086), 1–118.
[4] Alex Ewerlöf (May 31 2018). GDPR pseudonymization techniques https://medium.com/@alexewerlof/gdpr-pseudonymization-techniques-62f7b3b46a56
[5] Patrick Schmid and Achim Roos, P. S. & A. R. (2010, Februar 2). AES-NI Performance Analyzed; Limited To 32nm Core i5 CPUs. Called on 5. November 2019, https://www.tomshardware.com/reviews/clarkdale-aes-ni-encryption,2538.html
[6] Schwarz, M., Weiser, S., Gruss, D., Maurice, C., & Mangard, S. (2017, July). Malware guard extension: Using SGX to conceal cache attacks. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (pp. 3–24). Springer, Cham.
[7] Van Bulck, J., Minkin, M., Weisse, O., Genkin, D., Kasikci, B., Piessens, F., … & Strackx, R. (2018). Foreshadow: Extracting the keys to the intel SGX kingdom with transient out-of-order execution. In 27th USENIX Security Symposium (USENIX Security 18) (pp. 991–1008).
