04.12.2024
CompTIA A+ Certification: Your Comprehensive Guide
Posted by Marbenz Antonio on April 19, 2022
Over the last several years, significant progress has been achieved in protecting sensitive data in transit and storage. But sensitive data may still be vulnerable when it is in use. Consider the case of transparent database encryption (TDE). While TDE protects sensitive data in storage, the same data must be put in cleartext in the database buffer pool for SQL queries to be performed. This makes the sensitive data susceptible since its confidentiality might be compromised by memory-scraping malware or privileged user misuse, among other things.
Many firms have been hesitant to save money on IT infrastructure by outsourcing some calculations to the cloud and sharing private data with their peers for collaborative analytics because of concerns about data security. Two promising developing solutions for addressing this challenge and helping enterprises to realize the value of sensitive data are confidential computing and fully homomorphic encryption (FHE). What exactly are these things, and how do they differ?
Many businesses have struggled with sharing confidential data with collaborators and adopting cloud data services until recently. For some, the benefits of sharing data with collaborators and using cloud data services outweigh the danger of personal data becoming susceptible while in use. But, for other groups, such a trade-off is not on the table. What if companies were not required to make such a trade-off? What if data could be safeguarded not just during transmission and storage, but also during use? This would allow for a wide range of applications:
Because sensitive data is often stored in cleartext in the main memory, it may be susceptible during processing. Confidential computing tackles this issue by guaranteeing that sensitive data computations are done in a TEE, which is a hardware-based system that prohibits unauthorized access or change of sensitive data.
Figure 1: Protecting Sensitive Data During Computation Using Secure Enclaves.
One well-known example of secret computing is Intel Software Guard Extensions (SGX). It enables an application to construct a private portion of main memory, termed a secure enclave, whose content cannot be read or written by any process from outside the enclave regardless of its privilege level or central processing unit (CPU) mode. Even if the operating system (OS), hypervisor, or container engine are all hacked, the enclave is protected by this isolation. Furthermore, the enclave memory is encrypted using keys stored in the CPU. Only code within the enclave is decrypted inside the CPU. This means that a malevolent entity would be useless if they managed to physically take the enclave memory.
For confidential computing, there are two primary options today: application software development kits (SDKs) and runtime deployment systems. The Intel SGX capability mentioned above is one example of the application SDK-based approach. The developer is in charge of partitioning the program into untrusted and trustworthy code in this technique. The OS executes the untrusted code normally, while the secure enclave runs the trustworthy code. The SDKs give you the tools you need to build and manage secure enclaves.
Another example of an application SDK-based solution is the Open Enclave SDK. It’s an open-source SDK that adds a layer of abstraction to TEE-based programs, allowing developers to create them once and distribute them across numerous hardware platforms. Because there is less code to analyze, the application SDK-based method provides for easier analysis of the trusted code, although it does need application modifications.
The purpose of the runtime deployment system-based method is to enable apps to operate in a TEE without having to rebuild them for a particular hardware platform or SDK. IBM Secure Execution for Linux (IBM Z15 and LinuxOne III) and the open-source project Enarx are two examples of solutions in this category. The runtime deployment system-based method has two major advantages: cost savings and faster time to value. However, deploying apps without making any changes may prohibit them from making use of other capabilities, such as attestation, unless they have been developed specifically for this purpose.
Traditional encryption systems, such as the advanced encryption standard (AES), may be relied upon to safeguard data in transit and storage. They do not, however, allow for calculation on encrypted data. To put it another way, data must first be encrypted before it can be used. Sensitive data might be exposed in this ‘data in use’ condition. FHE solves this problem by allowing computation on encrypted data directly. So, what precisely is homomorphic encryption, and what comprises a completely homomorphic encryption scheme?
A homomorphic encryption technique enables some type of computation on encrypted data. For example, given a cleartext input x and its encrypted value E(x), computing E(f(x)) for some function f should be doable without having access to x or any other secret information. Many well-known encryption methods display homomorphic features in this situation. A cleartext input x, for example, is encrypted as E(x) = xe mod m using RSA, where e is a public exponent and m is a public modulus. It is simple to see that, given two ciphertexts E(x) = xe mod m and E(y) = ye mod m, encrypting two cleartext inputs x and y, we can add them together and obtain (XY)e mod m, which is the encrypted value of XY. This means that RSA is homomorphic for multiplication.
Take, for example, the Paillier encryption technique. A cleartext input x is encrypted using Paillier as E(x) = gx rm mod m2, where g is the base, m is the modulus, and r is the random number. Given two ciphertexts E(x) = gx rm mod m2 and E(y) = gy sm mod m2, which encrypt two cleartext inputs x and y, we can easily multiply them together to produce g(x+y) (rs)m mod m2, which is the encrypted value of x + y. Paillier is homomorphic for addition in this sense. A homomorphic encryption scheme that allows just multiplication or only addition is called a partly homomorphic encryption scheme.
The number of operations that could be performed on encrypted data was limited in early systems that supported both multiplication and addition, such as DGHV. As a result, they’re known as relatively homomorphic encryption. For security reasons, a ‘noise’ is added during encryption in some systems.
This noise appears to increase with each addition or multiplication operation. This noise can accumulate to the point that the ciphertext cannot be decoded correctly. As a result, FHE refers to any technique that allows for an infinite amount of multiplications and adds on encrypted data.
Craig Gentry of IBM made the breakthrough in 2009. The first conceivable FHE scheme was his lattice-based encryption technique. The critical idea in Gentry’s work is called bootstrapping. Bootstrapping is the process of refreshing a ciphertext to create a new ciphertext that encrypts the same data but with less noise, allowing for more homomorphic operations to be evaluated on it.
Bootstrapping is the process of decrypting the ciphertext using the secret key and then re-encrypting the data. The secret key, on the other hand, is unknown. It is replaced with an encryption of the secret key, termed the bootstrapping key. Most FHE systems that have been discovered so far are based on bootstrapping.
Figure 2 shows how FHE may be utilized to delegate sensitive data processing to the cloud while keeping complete control over data privacy.
Figure 2: Fully Homomorphic Encryption.
FHE is an asymmetric encryption method, which necessitates the usage of a public key (pk) and a secret key (sk), as seen in the diagram. Alice uses the secret key sk to encrypt her data and provides her public key pk with the cloud service, which is used to evaluate function f on the encrypted data. When Alice receives the result, she decrypts it with her secret key and obtains f (x).
Depending on how they describe computing, FHE systems may be split into three categories:
There are several open-source FHE implementations available now. IBM HELib, PALISADE, and Microsoft SEAL are three of them; certain schemes, like CKKS, are accessible in all three libraries, while others aren’t. BGV, for instance, is only accessible in IBM HELib and PALISADE.
Both FHE and confidential computing are new technologies that help safeguard data in use. They assist in maintaining the privacy of sensitive/private data while it is in use. Because FHE is based on cryptography, its security can be mathematically proven. Confidential computing, on the other hand, is built on TEE. As a result, its safety cannot be mathematically proven. TEE, for example, can give a high level of security due to hardware-based isolation, but it can’t defend against side-channel attacks.
While FHE gives higher privacy assurances, it cannot provide code execution fidelity. This is where confidential computing excels. Confidential computing provides higher assurances for the integrity of code execution by executing programs within a TEE. As a result, FHE and secret computing should be seen as complementary rather than competing solutions.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com
