The Next Frontier for Data Security: Protecting Data in Use
By: Ibm Security Guardium
Tags: Cybersecurity, Encryption, Data Security, Zero Trust, Data Privacy

Introduction

Sensitive data can exist in three states: In transit, in storage and in use. Tremendous progress has been made over the last several years to protect sensitive data in transit and in storage. But sensitive data may still be vulnerable when it is in use. For example, consider Transparent Database Encryption (TDE). While TDE ensures sensitive data is protected in storage, that same sensitive data must be stored in cleartext in the database bufferpool so that SQL queries can be processed. This renders the sensitive data vulnerable because its confidentiality may be compromised in several ways including memory-scraping malware and privileged user abuse. This concern around protecting data in use has been the primary reason holding back many organizations from saving on IT infrastructure costs by delegating certain computations to the cloud and from sharing private data with their peers for collaborative analytics. Confidential Computing and Fully Homomorphic Encryption (FHE) are two promising emerging technologies for addressing this concern and enabling organizations to unlock the value of sensitive data. This paper explores and contrasts both technologies.

Use Cases for Data in Use Protection

Until recently, sharing private data with collaborators and consuming cloud data services has been a constant challenge for many organizations. For some, the value derived from sharing data with collaborators and consuming cloud data services justifies accepting the risk that private data may be vulnerable while it is in use. But, for other organizations, such a trade-off is not on the agenda. What if organizations were not forced to make such a trade-off? What if we can ensure that data is protected not only in transit and in storage, but also in use? This would open the door for a variety of use cases such as the following:

· Secure database processing for the cloud: Cloud database services employ Transport Layer Security (TLS) to protect data as it transits between the database server and client applications. They also employ a variety of database encryption techniques to protect data in storage. However, when it comes to database query processing the data must reside in main memory in cleartext. FHE can be used to perform query processing directly on encrypted data, thus ensuring sensitive data is encrypted in all three states: In transit, in storage and in use. Confidential Computing does not enable query processing on encrypted data but can be used to ensure that such computation is performed in a Trusted Execution Environment (TEE) so that sensitive data is protected while it is in use.

· Secure data sharing for collaborative analytics: In the financial industry, organizations have a need to share private data with their peers to help prevent financial fraud. In the healthcare industry, organizations need to do the same to help develop cures for new diseases. In all such cases, organizations struggle with how to derive the desired outcome from sharing the private data while still complying with data privacy laws. FHE can be used to address this dilemma by performing the analytics directly on the encrypted data, ensuring that the data remains protected while in use. Confidential Computing can be used to ensure that the data is combined and analyzed within the TEE so that it is protected while in use.

· Saving IT costs by delegating computation to the cloud: Financial institutions train and deploy Machine Learning (ML) models to better understand their clients and tailor specific products for them. For example, the marketing department might want to understand a client’s propensity to contracting a loan within the next three months and tailor an offer for them. Financial institutions might want to save on storage costs by moving clients data to cheaper cloud storage and run the analytics there. However, this poses a problem for both the privacy of the clients data as well as the privacy of the ML models themselves. FHE can be used to address this challenge by encrypting the ML models and running them directly on encrypted data, ensuring both the private data and ML models are protected while in use. Confidential Computing protects the private data and ML models while in use by ensuring this computation is run within a TEE.

· Strengthening adherence to zero-trust security principles: As attacks on data in transit and on data in storage are countered by standard protection mechanisms such as TLS and TDE, attackers are shifting their focus to data in use. In this context, a multitude of attack techniques are employed to target data in use such as memory scraping, hypervisor and container breakout, and firmware compromise. FHE and Confidential Computing both strengthen adherence to zero-trust security principles by removing the implicit trust that applications would otherwise need to place in the underlying software stack to protect data in use.

Confidential Computing

Sensitive data may be vulnerable during computation as it typically resides in main memory in cleartext. Confidential Computing addresses this concern by ensuring that computation on such sensitive data is performed in a TEE. A TEE is a hardware-based mechanism that prevents unauthorized access or modification of such sensitive data.

Figure 1: Protecting Sensitive Data During Computation Using Secure Enclaves

Intel Software Guard Extensions (SGX) is one widely known example of confidential computing. It enables an application to define a private region of main memory, called secure enclave, whose content cannot be read or written by any process from outside the enclave regardless of its privilege level or CPU mode. This isolation protects the enclave even when the OS, hypervisor and container engine are compromised. Additionally, the enclave memory is encrypted with keys stored within the CPU itself. Decryption happens inside the CPU and only for code within the enclave. This means that even if a malicious entity were to physically steal the enclave memory, it will be of no use to them.

Two main approaches are being used today for Confidential Computing: Application SDKs and runtime deployment systems. The Intel SGX capability mentioned above is one example of the application SDKs based approach. In this approach, the developer is responsible for dividing their application into untrusted code and trusted code. The untrusted code runs normally on the OS, while the trusted code runs within the secure enclave. The SDKs provide the necessary APIs to create and manage secure enclaves. The Open Enclave SDK is another example of the application SDKs based approach. It is an open-source SDK that provides a level of abstraction to enable developers to build TEE based applications once and deploy on multiple hardware platforms. The application SDK based approach allows for better scrutiny of the trusted code since this is less code to review, but it does require changes to the application.

The goal of the runtime deployment system based approach is to enable applications to run in a TEE without having to rewrite them for a particular hardware platform or an SDK. Examples of solutions in this category include IBM Secure Execution for Linux (IBM Z15 and LinuxOne III) and the open-source project Enarx. Cost reduction and time to value are clearly the two biggest advantage of the runtime deployment system based approach. However, deploying applications without any modifications may prevent them from taking advantage of other features such as attestation, unless such applications have already been coded with that in mind.

Fully Homomorphic Encryption

Traditional encryption schemes such as the Advanced Encryption Standard (AES) can be relied upon for protecting data in transit and in storage. But they do not enable computation on encrypted data. In other words, data must be first decrypted before it can be operated upon. During this “Data in use” state, sensitive data can be vulnerable. FHE addresses this problem by enabling computation directly on encrypted data. So, what exactly is homomorphic encryption and what makes a homomorphic encryption scheme fully homomorphic?

A homomorphic encryption scheme is an encryption scheme that supports some form of computation on encrypted data. For instance, given a cleartext input x and its encrypted value E(x), it should be possible to compute E(f(x)) for some function f, without having access to x or any other secret information. In this context, many of the well-known encryption schemes exhibits some homomorphic properties. For example, with RSA, a cleartext input x is encrypted as E(x) = xᵉ mod m, where e is a public exponent and m is a public modulus. It is easy to see that, given two ciphertexts E(x) = xᵉ mod m and E(y) = yᵉ mod m, encrypting two cleartext inputs x and y, we can multiply them together and obtain (xy)ᵉ mod m, which is the encrypted value of xy. This means that RSA is homomorphic for multiplication.

Let us now consider the Paillier encryption scheme. With Paillier, a cleartext input x is encrypted as E(x) = gˣ rᵐ mod m², where g is the base, m is the modulus and r is random. It is easy to see that given two ciphertexts E(x) = gˣ rᵐ mod m² and E(y) = gʸ sᵐ mod m², encrypting two cleartext inputs x and y, we can multiply them together and obtain g⁽ˣ ᐩ ʸ⁾ (rs)ᵐ mod m², which is the encrypted value of x + y. This means that Paillier is homomorphic for addition. A homomorphic encryption scheme that supports only multiplication or only addition is called a partially homomorphic encryption scheme.

Early schemes that supported both multiplication and addition such as DGHV had a limit on the number of operations that can be carried on encrypted data and were called somewhat homomorphic encryption. In these schemes, a “noise” is added during encryption for security purposes. It turned out that this noise grows with each addition or multiplication operation and, passed a threshold, this noise becomes so significant that the ciphertext cannot be correctly decrypted. Fully Homomorphic Encryption (FHE) is therefore any scheme that supports an unbounded number of multiplications and additions on encrypted data. The breakthrough came in 2009 with Craig Gentry of IBM. His lattice-based encryption scheme was the first plausible FHE scheme. The key idea in Gentry’s work is called bootstrapping. Bootstrapping refers to the process of refreshing a ciphertext in order to produce a new ciphertext that encrypts the same data, but with a lower level of noise so that more homomorphic operations can be evaluated on it. Conceptually, bootstrapping can be thought of as decrypting the ciphertext with the secret key, and then re-encrypting the data, except that the secret key is not known and it is replaced by an encryption of the secret key, called the bootstrapping key. Bootstrapping is the core of most FHE schemes known to date.

Figure 2 illustrates how FHE can be used to delegate computation on sensitive data to the cloud while still maintaining full control of the privacy of such data.

Figure 2: Fully Homomorphic Encryption (FHE)

FHE is a form of asymmetric encryption, thus the pair of public key (pk) and secret key (sk) shown in the figure. Alice would encrypt her data with the secret key sk and share her public key pk with the cloud service, where it is used in the evaluation of function f on the encrypted data. When she receives the result, Alice would use her secret key to decrypt it and obtain f(x).

FHE schemes can be divided into three main categories depending on how they model computation:

· Boolean Circuits: Express computation as Boolean circuits and is most suitable for number comparisons. Examples of such schemes include GSW and TFHE.

· Modular Arithmetic: Express computation as integer arithmetic and is most suitable for integer arithmetic and scalar multiplication. Examples of such schemes include BGV and BFV.

· Approximate Arithmetic: Express computation as floating-point arithmetic and is most suitable for polynomial approximations and ML models. Examples of such schemes include CKKS.

Several open-source implementations of FHE exist today. They include IBM HELib, PALISADE and Microsoft SEAL. Some schemes such as CKKS are available in all three libraries, but others may not be available across all of them. For example, BGV is available only in IBM HELib and PALLISADE.

Comparing Fully Homomorphic Encryption and Confidential Computing

Fully Homomorphic Encryption and Confidential Computing are both emerging technologies for protecting data in use. They both help ensure the confidentiality of sensitive/private data while it is in use. Fully Homomorphic Encryption is based on cryptography and therefore its security is mathematically provable. On the other hand, Confidential Computing is based on Trusted Execution Environments and therefore its security is not mathematically provable. For example, while Trusted Execution Environments provide a high level of security through hardware-based isolation, they cannot protect against side channel attacks.

While Fully Homomorphic Encryption provides stronger privacy guarantees, it cannot guarantee the integrity of code execution. This is where Confidential Computing excels. By running code within a Trusted Execution Environment, Confidential Computing provides stronger guarantees when it comes to the integrity of code execution. Therefore, Fully Homomorphic Encryption and Confidential Computing should not be viewed as competing solutions. They are rather complementary.

Conclusion

Protecting data in use is the next frontier for data security. It enables organizations to save on IT infrastructure costs by delegating computation to the cloud in confidence. It also opens the door for collaborative analytics over private data while still complying with privacy mandates. Confidential Computing and Fully Homomorphic Encryption are key emerging technologies for protecting data in use and enabling those use cases. From a timeline perspective, Confidential Computing is more likely to be the technology that will be widely adopted first, particularly the runtime deployment systems type as those do not require any application changes. Some initial examples of this are actually available today such as the IBM Data Shield offering on the IBM Cloud or the ALWAYS ENCRYPTED database on Microsoft Azure. Fully Homomorphic Encryption has made tremendous progress over the last decade, but it needs to evolve beyond the low-level cryptographic libraries to facilitate its use and adoption in creating new applications. Some important steps in this direction are being made though. For example, the recently announced IBM HElayers SDK enables running AI workloads on encrypted data without having to understand the low-level cryptographic underpinnings. The IBM HElayers SDK includes a Python API that enables application developers and data scientists to use the power of FHE by supporting a wide array of analytics such as linear regression, logistic regression, and neural networks.

Further Reading

[1] Confidential Computing

https://confidentialcomputing.io/

[2] Fully Homomorphic Encryption

https://www.ibm.com/blogs/research/2020/12/fhe-progress-milestones/

[3] IBM HElayers

https://hub.docker.com/r/ibmcom/helayers-pylab