Intel Software Guard Extensions (SGX) is a set of instructions that helps the host machine in creating compact secure containers known as enclaves that can be used to execute sensitive processes protected from the outside. The SGX was a technology introduced by Intel Corporation in 2015 for its 6th generation processors. The enclaves created by the SGX are protected areas to execute CPU instructions without any interference. Even on a compromised machine, these enclaves prevent breaches with their access control policies, thus making it inaccessible by the host machine, the BIOS, hypervisor, and the superuser too. The Intel Software Guard Extension is often used to protect sensitive information like credentials, secret keys and identities preserving their confidentiality and integrity. Few of the main features of this technology include its remote and local attestations and sealing/unsealing of information.
1. Sealing/Unsealing Data
Sealing and Unsealing is one of the features that the Intel Corporation provides with its Intel SGX technology used for securing data outside an enclave. The secure containers created by the SGX are destroyed once the process exits and all the data inside is destroyed. However, there is a situation wherein the information inside the enclave has to persists for future use. If this data has to be re-used in the future, certain actions have to be taken by the enclave to store this information outside before it is destroyed. Sealing of data helps to encrypt the data that has to be stored outside the enclave with a special key that can be derived from the hardware inside the enclave only. Thus this encryption provides assurances of integrity, confidentiality and authenticity on the data. Every time the data has to be accessed, a new enclave has to be initialised and the key has to be granted to the enclave by the hardware. The Intel SGX supports two policies for these Sealing/Unsealing Keys [4].
1.1. Sealing to Enclave Identity
The enclave identity is represented by the value of MRENCLAVE, which is a cryptographic hash of the enclave logs right from the time it was built to being initialised. As a result, different enclaves would have different MRENCLAVE values. Sealing to enclave identity would restrict access of the sealed data only to instances of the same enclave. Other enclaves or even different versions of the same enclave would not be able to access the sealed data.
1.2. Sealing to Signing Identity
The signing identity is provided by the authority that signs an enclave before it could be distributed. This identity is represented by the MRSIGNER value and is the same for all enclaves that have common signing authorities. As a result, sealing to signing identity allows the same sealing key to be shared by multiple enclaves and different versions of enclaves that were all signed by the same authority. This restricts the access of sealed data only to instances of enclaves signed by other authorities.
2. Local (Inter-Platform) Attestation
Applications on a single platform may often need to communicate with one another to perform some high level of function. While communicating, the enclave of one application must prove its identity and authenticity to the other enclave(s) from different applications on the same local platform. The Intel SGX provides a trusted hardware mechanism called as Local Attestation for the same. For this, the enclave that needs to communicate with the other one generates a report with the help of the Hardware proving its identity, proof of the existence and other details. This report can then be given to the other enclave for verification. The authentication mechanism used for the Local Attestation comprises of symmetric cryptography where only the enclaves verifying and providing the report have access to the shared key.
2.1. Working
Step 1 — Provisioning request
The enclave (A) that needs to communicate requests a local attestation from the other enclave (B) running on the same platform. After receiving the request, the other enclave replies by providing its MRENCLAVE identity to enclave A.
Step 2 — Report Creation
Once receiving the MRENCLAVE identity from enclave B, enclave A asks the hardware to create a report destined form enclave B with its proof of identity, proof of existence and other details. This report is then sent to Enclave B.
Step 3 — Report Verification
Once received, enclave B asks the hardware to verify the report send by enclave A verifying that both are on the same platform. Enclave B can then reply with its report using the MRENCLAVE identity of enclave A from the report provided. This report is sent to enclave A for the same verification process.
Step 4 — Key provisioning
Once verified the report by enclave B, the secret key is then shared via a secured channel.
3. Remote (Inter-Platform) Attestation
Remote attestation is a way in which a remote node can prove that it was configured and initialised with the right version of an Intel SGX enclave on its machine. It ensures that the enclave is running over a trusted environment without any external interference and malicious software. This technique is often used when communicating with external nodes to share sensitive information over a secured channel using symmetric and asymmetric cryptography. This inter-platform communication process is guarded by a secure channel that uses the public and private keys of the remote node ensuring the integrity of the channel. The secrets that are sent over this secure channel are also secured by using the famous Diffie Hellman Key Exchange algorithm which ensures that no malicious user can access the information being exchanged even if the channel is compromised [1]. This adds a second layer of security to the information being communicated. Before explaining the entire attestation and key exchange process some terminology will be briefly explained below.
3.1. Terminology
3.1.1. Quoting Enclave
The quoting enclave is a secured container that is present on every SGX enabled machine apart from the application enclave that is responsible for performing the sensitive instructions. The Quote enclave oversees creating a report that is used for remotely attesting a remote device. This report is used by the Trusted Remote Authority (TRA) and the intel attestation service to verify the remote attestation of the device. The quote enclave receives a report from the main enclave with details of is initialization, version and code running inside. This report is then verified by the quoting enclave, signed, and provided to the TRA.
3.1.2. EPID
The Intel Enhanced Privacy ID (EPID) enable nodes over the network to sign objects without their identity being exposed. This helps the signing process being anonymous as it cannot be backtracked to any of the signers over the network. It is an extension of the Direct Anonymous attestation scheme [2] by E Brickell et al. This is done by dividing all the available signers into groups based on similarities of their processors. Once the signers are categorized, the signing can happen with the private signing key of each node and those signatures can be verified by the public key of the group only. As a result, it is easy to find out which group a node belongs to, however, which node has signed the objects will never be exposed.
3.1.3. Signature Revocation List (SigRL)
The Signature Revocation List also called SigRL, is a list of all the signatures of the nodes that are not trusted. This list of backlisted signatures is signed by the revocation authority and hence the name. Every time an untrusted signature is obtained, the revocation authority will add that signature to the previous list (SigRL), update the list and sign it with its private key. After which the corresponding key of the malicious signer will be revoked. This ensures that all the signers maintain their authenticity. The EPID scheme benefits from this list which is absent in the traditional Direction Anonymous attestation scheme.
3.2.Working
3.2.1. Step 1 — Provisioning request
The provisioning request is the first step of the remote attestation (RA) process wherein the remote node requests the Trusted Remote Authority (TRA) to initiate the RA flow and provide the secret key which would be used for encryption/decryption in its enclave. Every remote node is initialised with the public key of the TRA so that it can communicate securely only with the intended remote authority. Once the request has been sent, the TRA then replies by challenging the remote node with the help of an attestation request. This request is usually in the form of a nonce. Other details of the communication and message are a dependant of the TRA.
3.2.2. Step 2 — Extended Group Id Provision (msg0)
Once the challenge is received at the client end (RN), it will initiate the RA process. First, the application makes an ECALL to enter the enclave, then using the ‘sgx_ra_init()’ method it initiates the RA process and gets the DHKE context parameter which would be used in the future to exchange the key. During this method call, it passes the public key of the challenger (TRA). The next step the client performs is the generation of the group ID (GID) which is a part of the EPID scheme. This is done by calling the ‘sgx_get_extended_epid_group_id()’ method. The GID forms msg0 that is sent to the TRA. This GID has to be verified by the TRA to continue the attestation process. Once verified, the TRA sends a signal to the RN.
3.2.3. Step 3 — Temporal Key Provision (msg1)
On receiving the green light from the TRA, the client continues with the RA process. The first step of the client is the creation of its ephemeral (temporal) public key which would be used by it and the TRA for secure communication. The client then generates the msg1 as a response to the TRA. For this is envokes the ‘sgx_ra_get_msg1()’ which accepts the public key of the TRA, the DHKE context and a pointer to the function to create the client DHKE secret. Together, the ephemeral key and the contents of the method invoked are combined and sent across to the TRA forming msg1.
3.2.4. Step 4 — Service Provider ID and SIgRL Provision (msg2)
This is where the Intel Attestation Service (IAS) comes in picture. During this step, the challenger (TRA) generates its DHKE context parameter (Gb) using the values of the DHKE context in the request is received from the RN. It also requests the IAS to generate the SigRL for the GID sent by the client. After verifying the SigRL provided by the IAS, it generates the Key definition key and mentions value in the Quote_type variable. The SigRL, KDK, Quote_type and the public key of the TRA (SPID) are combined to form msg2 and are sent to the client.
3.2.5. Step 5 — Quote Provision (msg3)
On receiving msg2 from the TRA, the client verifies the TRA signature and the SigRL list. It then sends the report from the msg3 to the quoting enclave which is present on the same machine to create a quote. In short, it calls the ‘sgx_ra_get_msg3_trusted()’ method which returns the quote that was generated by the quoting enclave on successful verification of the encryption/decryption enclave. This generated quote forms msg3 which are signed by the RN and sent to the TRA.
3.2.6. Step 6 — Secret key Provision (msg4)
This is the final step wherein the TRA verifies the quote provided in the previous step. This is done by using the EPID certificate to check the sign over the quote. The quote is then sent to the IAS who verifies its details and provides details of the enclave functioning over a remote node. Once verified, the TRA finally sends msg4 containing the result of the quote verification as well as the secret. The secret which is shared over the secure channel is also encrypted using the DKHE algorithm.
4. Applications
With the above-mentioned features of the Intel SGX, multiple applications from different domains have leveraged the security measures of the Intel SGX. Christian Priebe et al [5] proposed a unique database engine guaranteeing confidentiality, integrity and freshness for data and queries. The system named as EnclaveDB achieved this by placing its sensitive information like its tables, indexes and metadata inside an enclave. This enclave being protected by Intels trusted hardware ensures that the data is safe from a malicious database administrator too. The data and metadata were also sealed and stored over the disk thus providing easy access to the enclave while initialising it. Ben A Fisch et al [6] have designed a novel system for functional encryption of information with the help of Intel SGX. It does so by using the local and remote attestation process of SGX technology. The authors have described functional encryption as a powerful cryptographic tool that facilitates non-interactive fine-grained access control to encrypted data. Thus without having access to the actual data, a remote node can compute a function over it and get only the result of the function. To respond, the information is decrypted in an enclave and a function is computed over the decrypted data. The decryption process is centrally handled by a trusted remote authority who provisions the decryption key.
Juan Wang et al [7] have designed an enhanced attestation system that helps in constructing trusted terminals and services and can be used in an Internet of Things (IoT) embedded system. The authors also present a policy-based mechanism way wherein sensitive data like secret keys, policy details, credentials, are all sealed using the enclave-specific keys. SGX-Log is a system designed by Vishal Karande et al [8] that helps to preserve log records of a system using the Intel Software Guard Extension technology. They designed a logging system that ensures the safety of its logging data from malicious users. For this, the authors used the sealing mechanism of SGX to protect the program code as well as the log data in both the disk and the memory from being altered. Java is one of the most used programming languages and often several applications written in java are running on untrusted infrastructure including public clouds. As a result, research on using SGX in Java is exponentially increasing and flourishing. Luigi Coppolino from the University of Naples et al [9] has compared the various techniques and approaches that are used to secure Java applications with Intel SGX. A per their findings, the SCONCE, SGX-LKL and SGX-JN were the most promising techniques and a comparative analysis on the same was completed by the authors.
References
1. Diffie, W. and Hellman, M., 1976. New directions in cryptography. IEEE transactions on Information Theory, 22(6), pp.644–654.
2. Brickell, E., Camenisch, J. and Chen, L., 2004, October. Direct anonymous attestation. In Proceedings of the 11th ACM conference on Computer and communications security (pp. 132–145).
3. Johnson, S., Scarlata, V., Rozas, C., Brickell, E. and Mckeen, F., 2016. Intel® software guard extensions: Epid provisioning and attestation services. White Paper, 1, pp.1–10.
4. Anati, I., Gueron, S., Johnson, S. and Scarlata, V., 2013, June. Innovative technology for CPU based attestation and sealing. In Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy (Vol. 13, p. 7). ACM New York, NY, USA.
5. Priebe, C., Vaswani, K. and Costa, M., 2018, May. Enclavedb: A secure database using SGX. In 2018 IEEE Symposium on Security and Privacy (SP) (pp. 264–278). IEEE.
6. Fisch, B., Vinayagamurthy, D., Boneh, D. and Gorbunov, S., 2017, October. Iron: functional encryption using Intel SGX. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 765–782).
7. Wang, J., Hong, Z., Zhang, Y. and Jin, Y., 2017. Enabling security-enhanced attestation with Intel SGX for remote terminal and iot. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 37(1), pp.88–96.
8. Karande, V., Bauman, E., Lin, Z. and Khan, L., 2017, April. Sgx-log: Securing system logs with sgx. In Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security (pp. 19–30).
9. Coppolino, L., D’Antonio, S., Mazzeo, G. and Romano, L., 2019. A comparative analysis of emerging approaches for securing java software with Intel SGX. Future Generation Computer Systems, 97, pp.620–633.