Integrating Intel SGX Remote Attestation with Transport Layer Security

Thomas Knauth, Michael Steiner, Somnath Chakrabarti, Li Lei, Cedric Xing, Mona Vij Intel Labs [email protected]

ABSTRACT An integral part of the Intel SGX architecture is the ability to perform attestation. The attester wants to Intel® Software Guard Extensions (Intel® SGX) is a convince the challenger that it is a genuine Intel SGX promising technology to enhance securely processing enclave running on an up-to-date platform. At the information in otherwise untrusted environments. An end of the attestation process the enclave has important aspect of Intel SGX is the ability to perform convinced the challenger that it is genuine. Based on remote attestation to assess the endpoint’s the enclave’s attested attributes, the challenger trustworthiness. Commonly, remote attestation is decides whether to trust the enclave or not. used to establish an attested secure channel to provision secrets to the enclave. Previous work has shown that remote attestation and secure channel establishment must be integrated to We integrate Intel SGX remote attestation with the protect against man-in-the-middle attacks [1]. At a establishment of a standard Transport Layer Security minimum, the remote attestation protocol should (TLS) connection. Remote attestation is performed result in a shared secret that can function as the basis during the connection setup by embedding the for a secure channel. The current Intel SGX SDK attestation evidence into the endpoints TLS provides an instance of this concept: remote certificate. Importantly, we neither change the TLS attestation is performed using a modified Sigma [2] protocol, nor does our approach require changes to protocol. After a successful protocol instance the existing protocol implementations. attester and challenger share a secret. We have prototype implementations for three widely However, a shared secret only partially solves the used open-source TLS libraries – OpenSSL, wolfSSL problem of secure communication. Bootstrapping a and mbedTLS. We describe the requirements, design secure channel based on a shared secret is possible, and implementation details to integrate SGX remote but inefficient since it duplicates work. Instead, we attestation with TLS to bind attested TLS endpoints to want to seamlessly integrate attestation with the Intel SGX enclaves. establishment of a standard secure channel. The end result is an attested secure channel through which 1. INTRODUCTION the participants can communicate. Intel SGX is a recent (2015) Intel processor extension available since the 6th Gen Intel® Core™ processors. In this white paper we describe our approach to Intel SGX enables application developers to construct combine Intel SGX remote attestation into the trusted execution environments – called enclaves – to existing Transport Layer Security (TLS) secure channel perform computation on commodity CPUs while protocol. Most importantly we do leave the TLS achieving previously untenable security protections. protocol unchanged, allowing us to reuse existing Even highly privileged software running concurrently implementations. Additionally, our approach works on the same hardware, say, the operating system, with existing extension points in widely used and and virtual machine monitor, cannot observe an well-vetted implementations of TLS. Not requiring enclave’s data in clear text. This is possible thanks to modified libraries and enabling developers already changes in the microarchitecture that enhances familiar with common secure channel API further, restriction-access to enclave memory by anyone eases adoption. The proposed scheme is independent except the enclave to which the memory belongs. of the TLS implementation and we provide prototypes

Version 2.0

each other. The enclaves perform a local message Application (2) (1) exchange to assess their identities and the fact that Application Challenger Enclave (3) (6) they share a common platform. Note that local attestation alone is insufficient to establish whether (4) (5) (7) the platform or the enclaves are genuine SGX enclaves. These facts can only be determined through Quoting Attestation remote attestation where the challenger typically is Enclave Veriﬁcation off-platform. User Platform Intel SGX attestation covers the identity of the Figure 1: Remote Attestation Example. The challenger software running in the enclave (e.g., MRENCLAVE is off-platform with respect to the attester. and MRSIGNER), non-measurable state, such as the enclave mode (e.g., debug vs. production), additional for three different popular TLS libraries – OpenSSL, data the enclave wants to associate with itself (e.g., a wolfSSL and mbedtls. manifest describing the software’s configuration), and a cryptographic binding to the platform TCB. This The remainder of the text is structured as follows: We information is bundled into a data structure called a first provide some background on Intel SGX remote report. An interested party inspects the attributes attestation and TLS in Section 2. Section 3 presents contained in the report to make a decision on the our approach to incorporate remote attestation into trustworthiness of the enclave. the TLS protocol. Section 4 gives implementation details and describes the API. In Section 5 we discuss The integrity and authenticity of the attestation future extensions and challenges. Section 6 discusses report is ensured differently depending on whether related work before concluding in Section 7. the interested party resides on the same platform as the attester. For attestation between enclaves on the 2. BACKGROUND same platform, the report is authenticated through a In this section we provide background information on report key. For remote attestation, a special quoting SGX local and remote attestation in general (Sec 2.1) enclave signs the report with an attestation key to followed by an overview of the EPID (Sec. 2.2) and create a quote. ECDSA (Sec. 2.3) remote attestation model and the Figure 1 illustrates a high-level remote attestation Transport Layer Security (TLS) protocol (Sec. 2.4). flow [5] where the challenger and verifier engage in a Readers familiar with either may want to skip ahead. modified Sigma protocol [2] to establish a shared secret. The protocol starts with the challenger 2.1. SGX ATTESTATION sending a nonce to the application to guarantee The concept of attestation was previously explored in freshness (Step 1). The application creates a manifest the context of Trusted Computing [3]. A secure co- that includes a response to the challenge as well as an processor, called Trusted Platform Module (TPM), ephemeral key to encrypt future communication with performed cryptographic operations, such as key the challenger (Steps 2 and 3). The application generation, signing and storing of keys, in a secure computes a hash of the manifest and includes this environment. In addition, a TPM can also attest the hash as user-defined data when creating the report. overall platform’s state and configuration to other Including a hash of the manifest into the report is interested parties [4]. The assessing party is called crucial, as this binds the ephemeral key to this challenger while the assessed party is the attester. enclave. Binding the key and enclave instance Based on the attestation, the challenger can decide together is crucial to avoid masquerading attacks [6] whether to trust the platform by comparing the [1] [7]. attester’s state to a reference value. Next, the enclave generates a report that summarizes Attestation is also an integral feature of the Intel SGX the enclave and platform state. The report includes architecture although the implementation details information on the platform (security version differ compared to TPMs. Intel SGX provides two number), enclave attributes, enclave measurement, attestation mechanisms [5] depending on where the software version, software vendor security version challenger and attester reside. Local attestation number, and additional user-provided data [8]. The allows two parties on the same platform to attest quoting enclave verifies and signs the report using the

attestation key (Step 4). The signed report, now called practice, reduces the barrier to entry and benefits the a quote, is returned to the application (Step 5) which overall Intel SGX ecosystem. passes it on to the challenger (Step 6). 2.3. ECDSA ATTESTATION The details of how the platform acquires the ECDSA-based attestation is an alternative attestation attestation key and how the quote can be verified model that allows third parties to build their own (Step 7) differs between the two remote attestation non-Intel attestation infrastructure. ECDSA benefits models. environments, such as data centers, where EPID’s privacy properties are unnecessary or deployment 2.2. EPID ATTESTATION constraints, like the requirement to communicate Initial versions of Intel SGX focused on privacy- with Intel back-end services during each attestation, sensitive client platforms. The Enhanced Privacy ID make EPID infeasible. ECDSA-based attestation [12] (EPID) protocol [9] allows systems to be identified as relies on standard ECDSA signatures (hence the genuine SGX platforms without revealing their name) as opposed to anonymous group signatures as identity in the process. This is important for use cases used in EPID. The quotes used to exchange involving client platforms where the service provider information about an enclave and the platform carry wants assurance on the availability of SGX, but the an ECDSA signature to convey their authenticity and end user wants to maintain privacy across integrity. attestations. With ECDSA-based attestation, Intel’s active With EPID attestation, the platform’s attestation key participation in the actual attestation flow is no is established through a blinded join protocol run longer required. Instead of going to the Intel between the platform and an Intel back-end service Attestation Service to have a quote verified, a verifier [9]. As a result, the platform has a private group key, can acquire all the necessary verification inputs the attestation key, to sign attestations with. Anyone without Intel’s active participation including a with access to the group public key can verify if the particular certificate, issued by Intel, to assess an signature was generated by one of the many group attestation. The Platform Certification Key (PCK) private keys without learning which specific group certificate can be obtained prior to an actual private key generated the signature. attestation taking place. Since the PCK certificate is Instead of publishing the group public keys, Intel set valid for extended time periods (i.e., years) it can be up an Attestation Service to verify quotes. Within the cached and reused across many attestations. EPID remote attestation model, a verifier sends the While Intel provides a reference implementation for quote to the Intel Attestation Service (IAS) which ECDSA-based attestation along with a software reply with an attestation verification report, library to generate and verify quotes [13], third confirming or denying the authenticity of the quote parties are free to set up their own attestation and the enclave it originates from [10]. The verifier infrastructure, including writing their own quoting inspects the attestation verification report to enclave. determine the enclave and platform’s trustworthiness. The reply from IAS includes the 2.4. TRANSPORT LAYER SECURITY original quote and can thus be verified by 3rd parties Transport Layer Security (TLS) is the de-facto industry other than the original challenger. standard to secure communication. It has been The Intel SGX SDK [11] provides the necessary APIs developed since 1995 and is still evolving, with TLS and primitives to remotely attest an enclave based on version 1.3 being the latest revision. Even with this the modified Sigma protocol outlined earlier. Note long history, subtle deficiencies are still discovered though, that the Sigma protocol only results in a occasionally [14]. Thus our strong motivation to build shared secret, not a secure channel. The application on a standard secure channel protocol instead of is left with the task to create a secure channel based custom solutions. on the shared secret. RA-TLS bridges this gap and Authentication. TLS not only protects the integrity integrates remote attestation into the establishment and confidentiality of data but also allows endpoint of the standard secure channel protocol TLS. This makes remote attestation easier to use securely in

ClientHello the certificate is valid. X.509 extensions are not regulated. Companies are free to introduce new SrvHello extensions in combination with the products they Certiﬁcate offer. To ensure interoperability, extensions can be SrvKeyExchange marked critical. If a client encounters a critical SrvHelloDone extension it is unaware of, it aborts the handshake. A client is, however, free to ignore an unknown non- ClientKeyExchange critical extension. ChangeCipherSpec Finished Trust Root. With TLS and the use of X.509 certificates to identify the endpoint, the trust root lies in the root Figure 2: TLS 1.2 Handshake Messages. certificate authorities. PKI users trust the root CAs to follow best practices and procedures before issuing authentication through the exchange of X.509 certificates to service providers. Alas, not all CAs and certificates. In a typical scenario where a browser their delegates are created equal and some may be (client) connects to a web site (server), only the server more trustworthy than others [15]. While browsers sends a certificate. The client uses the certificate to list hundreds of trusted CAs, scenarios other than confirm that it indeed connected to the intended web HTTPS on the internet may use a much smaller set of site. trusted roots.

TLS also allows both endpoints to authenticate each TLS Handshake. At the beginning of a TLS connection, other. Mutual authentication is frequently used with the client and server engage in a 3-way handshake1. known client populations, for example, in enterprise As part of the handshake, the two parties agree on settings, where only previously registered clients are the specifics of the cipher suite and the server allowed to connect. Again, trust in the endpoint is authenticates itself to the client by sending a conveyed through the exchange of certificates and certificate. While the client initially encrypts their verification through a certificate chain linking messages to the server using the server’s public key back to a trusted root certificate. obtained from the certificate, the two parties establish a mutual session key to use after the X.509 Certificates. The use of certificates for the handshake. purpose of identification is based on a Public Key Infrastructure (PKI). A set of trusted root certificate illustrates a typical TLS 1.2 handshake. The client authorities either create leaf certificates directly or initiates the handshake by sending a ClientHello delegate the responsibility to an intermediate message. The ClientHello includes a nonce, specifies certificate authority (CA). The intermediate CA can the client’s preferred cipher suites and any supported issue leaf certificates “on behalf of” the root CA. In TLS extensions. The server replies with a sequence of the case of securing web sites with TLS, the certificate three messages: ServerHello, Certificate, and represents a cryptographic binding of the web sites KeyExchange. After the server sends its domain name to the public key (subject key) ServerHelloDone message, the client continues the referenced in the certificate. When connecting to the exchange with its KeyExchange and HTTPS web site, the client verifies the certificate chain ChangeCipherSpec messages. After the handshake as well as that the distinguished name in the finishes successfully, the parties will have established certificate matches the domain it intended to connect a session key to authenticate and en-/decrypt future to. messages. A detailed description of each message and their meaning is available in the official TLS 1.2 Besides the distinguished name, X.509 certificates standard [16]. TLS 1.3 coalesced some previously can be used to bind arbitrary data to the key identity separate handshake messages to reduce the number in the form of X.509 extensions. Each extension is of round trips. Otherwise, the changes TLS 1.3 identified by an Object Identifier (OID). For example, introduces do not affect how it integrates with Intel the OID for the well-known extension Subject SGX remote attestation. Alternative Name (SAN) is 2.5.29.17. SAN allows the certificate to list multiple domain names for which

1We are focusing on TLS v1.2 here.

As part of the handshake, the server sends an X.509 legacy applications on Intel SGX [17] [18] [19] [20]. certificate to the client. The certificate states the The server obtains its Intel SGX identity and executes server’s public key, the certificate’s validity period, the steps necessary to obtain a report and a quote and domain name(s) the certificate is valid for, among from the platform’s quoting enclave. This is required other things. The client verifies this information and to successfully complete the remote attestation performs path validation to ensure the certificate workflow. chain terminates in a trusted root certificate. Additionally, the client should also check if the To achieve our goal of integrating remote attestation certificate has been revoked. In practice, this is only into the TLS handshake, we have to address two done for Extended Validation (EV) certificates, a objectives: First, we need to link the server’s RA-TLS special class of certificates used by high-value web key to a specific instance of an Intel SGX enclave. sites such as banks and insurance companies. If the Second, the server/attester must provide the client’s certificate validation logic indicates a problem necessary attestation evidence during the TLS with the certificate, the handshake is terminated. connection setup to convince the client/challenger that it is indeed connected to a veritable Intel SGX During the handshake, the server and client negotiate enclave. a symmetric session key to use after completing the handshake. The specifics of the key exchange and the 3.1. BINDING RA-TLS KEY TO ENCLAVE authentication depend on the chosen cipher suite. The enclave generates a new public-private RA-TLS For example, a cipher suite employing the Diffie- key pair at every startup. The RA-TLS key need not be Hellman Ephemeral key exchange, results in a new persisted since generating a fresh key on startup is key for each session. A unique session key provides reasonably cheap. Not persisting the key reduces the forward secrecy, that is even if the server’s key is key’s exposure and avoids common problems related compromised, an attacker cannot decrypt previously to persistence such as state rollback protection. recorded sessions since each session used an Interested parties can inspect the source code to ephemeral key independent of the server’s key. convince themselves that the key is never exposed outside of the enclave. 3. DESIGN In contrast to the PKI used in the modern web where RA-TLS links the RA-TLS key and enclave by including the trust root is a list of root certificate authorities a hash of the RA-TLS public key as user-data into the maintained by a handful of entities such as Google, Intel SGX report. Recall, that the report is generated Mozilla and Microsoft, we want to use Intel SGX as a by the attester and passed to the platform’s quoting hardware root of trust. To this end, we propose to enclave. The quoting enclave signs the report, include additional information into the X.509 vouching that the report was indeed generated by a certificate exchanged during a TLS handshake. In the genuine Intel SGX enclave on the local platform. At following, we explain which information we include in this point, there exists a cryptographically secured the certificate and how this information is validated. statement of the fact that the RA-TLS public key is bound to the Intel SGX enclave.IAS Intel We stay with the common scenario where a central server allows arbitrary clients to connect and the 3.2. ATTESTATION EVIDENCE clients want to verify the server’s identity during the To assess the server’s Intel SGX identity and link its connection setup. In the terminology of remote public key to the enclave instance, the client needs attestation, the server is the attester and the client access to the attestation evidence. We propose to the challenger. We focus on the classic client/server embed the attestation evidence as custom X.509 scenario to ease the explanation but our scheme also extensions in the server’s certificate. To this end, we covers mutual authentication/attestation. With introduce new X.509 extensions, each with their own mutual attestation, the client and server assume the unique object identifier (OID). Adding the attestation roles of attester and challenger at the same time. evidence into the certificate is less intrusive than, for example, introducing a new TLS extension which The server runs in an Intel SGX enclave and would require invasive changes to each TLS terminates the TLS connection inside the enclave. The implementation. By extending the certificate, we do server can either be constructed using the Intel SGX not require any changes to existing TLS libraries and SDK or any other framework/runtime to execute

use readily available hooks to verify the custom X.509 where the verifier only receives the quote and extensions. handles the verification independently. Depending on the scenario, it may be important which party has to Extending the certificate traditionally requires communicate with other external services during the resigning it by a CA. However, since we propose to use attestation flow. Intel SGX as a trust root, we can simply self-sign the certificate. Instead of relying on the CA to bind the 3.2.2. ECDSA ATTESTATION EVIDENCE domain name to the server’s identity/key, we rely For ECDSA-based attestation, we propose to include onIntel SGX to provide the identity. If a binding the following items as attestation evidence into the between the Intel SGX identity and a domain name is RA-TLS certificate. desired, we discuss one proposal how to incorporate this into the attestation flow in Section 5. Quote. The signed data structure produced by the quoting enclave. It contains the enclave’s code The specific attestation evidence embedded into the identity and various attributes. The quote is signed RA-TLS certificate differs between EPID and ECDSA- with the attestation key. The verifier can examine the based attestation as is described next. quote to determine whether to trust the enclave or not based on its SGX identity. 3.2.1. EPID ATTESTATION EVIDENCE For EPID-based attestation [9], we propose to embed TCB Info. Collection of attributes on the platform’s the following items as attestation evidence into the state where the quote was generated. A verifier can RA-TLS certificate. examine this to determine whether or not to trust the platform on which the attestation was performed. For Attestation Verification Report. This is the reply example, a verifier may decide to dismiss any received from the Intel Attestation Service (IAS) when attestation originating on a platform missing critical submitting a quote for verification [10]. IAS reports security updates. whether the quote was generated on a genuine Intel SGX platform by a genuine enclave. Embedded in the TCB Signing Chain. The TCB info is signed to assess report is a copy of the data produced by the enclave, authenticity and integrity. The certificate chain such as platform security version number, enclave required to verify the signature is included as part of identity (MRENCLAVE) and enclave signer the attestation evidence. (MRSIGNER) among other attributes. PCK Certificate. Intel publishes a PCK certificate for Attestation Verification Report Signature. The each SGX platform and TCB. The PCK certificate allows attestation verification report is signed by IAS. The a verifier to determine if the quote was produced on signature ensures that report is authentic and a genuine SGX platform. unmodified. PCK Signing Chain. The PCK certificate can be traced Attestation Report Signing Certificate. To verify the back to a trusted root certificate owned by Intel. The signature over the attestation report, the client must attestation evidence includes the entire certificate know the keys used to create the signature. This chain. The verifier is expected to check the signature information is conveyed in additional certificates on the PCK certificate to ascertain authenticity. included in the response from IAS. Certificate Revocation Lists. For the PCK certificates In addition to the above items the verifier also needs and intermediate CA certificates Intel also publishes the Attestation Report Signing CA Certificate to certificate revocation lists (CRLs) to notify a verifier of establish whether the Attestation Report Signing compromised keys. Certificate is trusted. This certificate forms the trust root and is thus not included in the RA-TLS certificate. Quoting Enclave Identity. The latest identity of Intel’s We expect the verifier to obtain it through a secure quoting enclave including its code measurement and out-of-band mechanism. security versions numbers. This allows the verifier to assess if the quoting enclave is from a trusted source Also note that in RA-TLS the attester communicates and received adequate security patches. with IAS since it assembles all the attestation evidence to be consumed by the verifier. This is The TCB Info, PCK Certificate and Certificate different to the flow depicted earlier in Figure 1 Revocation Lists are all signed and chain back to a

MRENCLAVE and MRSIGNER) against the expected Attestation (3) Server Enclave (5) Client identity. Veriﬁcation (4) (1) (2) 3.4. SECURITY PROPERTIES Quoting Typically, SGX attestations are produced at time of Enclave use, guaranteeing a fresh attestation. For RA-TLS, User Platform since the attestation is produced when the key is Figure 3: Message flow for EPID-based remote generated, additional mechanisms are needed. attestation using TLS. First, freshness of the exchanged messages is guaranteed by TLS itself: nonces at the record layer trusted root key possessed by Intel. The verifier is protect against replays. Freshness of the attestation expected to have the root key’s certificate (or the evidence can be determined through time stamps expected public key) either embedded or to attached to it. With EPID-based attestation, the otherwise obtain it securely out-of-band. attestation verification report has a time stamp. Similarly, with ECDSA-based attestation, the TCB info 3.3. RA-TLS CERTIFICATE VALIDATION and certificate revocation lists have a validity period. The receiver of the RA-TLS certificate must verify the Based on the available time stamps a verifier might SGX attestation evidence contained within. The reject them as too old. concrete steps differ based on the attestation method. Protocol-wise, the verification happens The security of the RA-TLS key is ensured by Intel SGX. during the standard TLS handshake. If any of the The quote binds the key to a particular enclave verification steps fail, the endpoint aborts the instance. By design, only the enclave has access to the handshake to terminate the TLS connection. key. An attacker would need to break the Intel SGX security model or exploit application-specific EPID Attestation Verification. To verify the EPID vulnerabilities to compromise the key. Users can attestation evidence a challenger must complete the inspect the source for code paths that intentionally following steps: (1) Verify the signature on the expose the key. We do not intend to persist the key Attestation Report Signing Certificate against the across enclave restarts. Instead, a new key is Attestation Report Signing CA Certificate (which is generated at each startup and, possibly, periodically trusted). Only if validation passes do we have at runtime for long running services. Usage of the key assurance that the report was signed by a trusted is further minimized when a cipher suite with a Diffie- attestation service. (2) Verify the report signature Hellman Ephemeral key exchange is used. In this case, against the report using the Attestation Report the RA-TLS key is only used during the handshake and Signing Certificate to ascertain that the attestation a per-connection ephemeral Diffie-Hellman key report is genuine and unmodified. protects the subsequent communication.

ECDSA-based Attestation Verification. In general, a A classic problem with traditional PKI is the verifier must undertake the following steps to regeneration of certificates, either because the determine the trustworthiness of an enclave on a certificate expired or the key was compromised, particular platform [12]: (1) Verify the integrity of the which is time-consuming and expensive. Since we signature chain from the quote to the Intel-issued PCK root trust in the Intel SGX hardware, we can self-sign certificate. (2) Verify no keys in the chain have been the certificate. This allows us to have short expiration revoked. (3) Verify the quoting enclave is from a times and regenerate certificates periodically. suitable source and up-to-date. (4) Verify the status Whenever we change the RA-TLS key, we do need to of the Intel SGX TCB described in the chain. generate a new quote to reflect this. Short certificate RA-TLS Verification. Independent of whether EPID or validity periods and fresh attestations also protect ECDSA attestation is used, the verifier must check if challengers from connecting to revoked platforms. the hash of the RA-TLS certificate’s public key is For example, with EPID attestation, the attester will present in the enclave’s report. This is how the RA-TLS no longer be able to obtain a valid attestation report key is tied to a particular enclave instance. Finally, the from the Intel Attestation Service if a platform was verifier compares the enclave’s identity (e.g., revoked in the meantime.

01 WOLFSSL_CTX* ctx; API subscription key to talk to the respective backend 02 ... 03 char key[2048]; char crt[8192]; services. 04 int key_len = sizeof(key); 05 int crt_len = sizeof(crt); Besides the actual TLS library, we also encapsulate the 06 07 create_key_and_x509(key, &key_len, Intel SGX SDK specific functionality into separate 08 crt, &crt_len); functions. For example, the RA-TLS library uses the 09 10 wolfSSL_CTX_use_certificate_buffer(ctx, Intel SGX SDK to obtain the quote. If the Intel SGX SDK 11 crt, crt_len, SSL_FILETYPE_ASN1); 12 is not available, for example, because a different 13 wolfSSL_CTX_use_PrivateKey_buffer(ctx, der_key, framework is used [19] [18] [20] to execute the 14 der_key_len, SSL_FILETYPE_ASN1); program on Intel SGX hardware, we provide an Figure 4: An example, based on the wolfSSL library, using alternative implementation of the required the attester API. Functions exported by the remote functionality independent of the Intel SGX SDK. attestation library are in bold. Hence, integrating our library with other SGX For ECDSA-based attestation, if the verifier is frameworks is possible and low overhead. concerned about the attestation evidence’s freshness, it is possible to independently obtain some Next, we describe the programming interface in of it instead of relying on the material contained terms of the attester and the challenger. Depending within the RA-TLS certificate. This applies in particular on the scenario, either can be the server or client in a to certificate revocation lists to ensure none of the traditional distributed computing setting. If mutual keys used to sign attestation evidence or the PCK key attestation is desired, and this is supported by our have been revoked. Especially for verifiers that library and TLS, the client and server will in fact themselves run inside an enclave it may be difficult to assume the role of attester and challenger at the determine if the attestation evidence is past its same time. validity period without access to a trusted time source. 4.1. ATTESTER Traditionally, the server/attester reads the key and 4. IMPLEMENTATION certificate from stable storage into memory before We implemented RA-TLS for EPID-based attestation serving it to other parties. It is the attester’s using three different TLS libraries: wolfSSL [21], responsibility to apply sufficient security measures to mbedtls [22], and OpenSSL [23]. ECDSA-based safeguard the key at rest. attestation in RA-TLS is currently only implemented in 2 Instead we propose to generate a new key and wolfSSL . Overall, the implementation is structured certificate whenever the attester enclave starts. The into two main components: (1) the RA-TLS key and key and certificate are ephemeral and shall not be certificate generations for the attester. (2) The RA-TLS persisted past the attester’s lifetime. The attester’s certificate validation for the challenger. The RA-TLS C API consists of one function library exposes a set of functions for use by the create_key_and_certificate that outputs the key attester and challenger. The library is linked into the and the corresponding certificate. To keep the application like any other standard library. interface generic, the key and certificate are encoded The code clearly separates the TLS library-specific in standard DER format. parts (hash computation, certificate generation and illustrates the flow of messages sent by the server validation, and key generation) from the library when it initializes. The server runs inside an Intel SGX agnostic aspects (extended validation steps). This enclave. Before accepting any client connections, the allows us to reuse the library-agnostic parts when server generates a new key and creates a self-signed porting RA-TLS to other TLS libraries. The interface to X.509 certificate including the extensions mentioned the RA-TLS library is largely independent of the in the previous section. The TLS library is configured attestation model expect for a structure to pass in to use this certificate as the server certificate for new configuration parameters. For example, EPID requires client connections. a Software Product ID (SPID) while ECDSA requires an

2 RA-TLS uses Intel’s Data Center Attestation attestation evidence which uses OpenSSL as a Primitives [13] for the actual verification of the backend.

01 int cert_verify_cb(int preverify, whether the certification chain terminates in a 02 WOLFSSL_X509_STORE_CTX* store) { 03 trusted root certificate. 04 WOLFSSL_BUFFER_INFO* crt = store->certs; 05 int ret = verify_sgx_cert_extensions( All the TLS libraries we have examined allow the user 06 crt->buffer, 07 crt->length); to specify a custom certificate validation function. 08 return !ret; The custom validation function either extends the 09 } 10 built-in verification logic or overrides it depending on 11 int main(int argc, char* argv[]) { 12 ... how it is used. Using these hooks/callbacks, we 13 wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, implement all the required changes to the challenger 14 cert_verify_callback); 15 ... without modifying the TLS library itself. 16 WOLFSSL_X509* crt = 17 wolfSSL_get_peer_certificate(ssl); The certificate validation hook indicates the 18 19 int der_len; successful validation through the return value. The 20 const byte* der = 21 wolfSSL_X509_get_der(crt, &der_len); caller uses the hook’s return value to either continue 22 the handshake or abort it. The hook calls the function 23 sgx_quote_t quote; 24 get_quote_from_cert(der, der_len, "e); verify_sgx_cert_extensions exported by our 25 sgx_report_body_t* body = "e.report_body; library. If the verification succeeds, the function 26 27 if (0 != memcmp(body->mr_enclave.m, returns 0. Otherwise, the function returns 1. 28 golden_mr_enclave, 29 SGX_HASH_SIZE)) { exit(1) }; The application gets access to the Intel SGX identity 30 ... 31 } and platform attributes through a complimentary function get_quote_from_cert to extract the Intel Figure 5: An example, based on wolfSSL library, using the challenger API. Functions exported by the remote SGX quote from the X.509 certificate. The quote attestation library are in bold. contains information on Intel SGX identity attributes such as MRENCLAVE and MRSIGNER as well as To create the certificate, the server must go through platform related attributes such as the CPU security the usual steps to perform remote attestation: create version number. Challengers use the attributes to a report, pass the report to the quoting enclave, and, decide whether the remote end meets their security finally, send the quote to IAS to receive an attestation requirements. It is also the application which must verification report. These steps must be performed at perform authorization based on the SGX identity startup (and every time the server’s key changes at while the RA-TLS library performs the authentication. runtime). If it is desirable to maintain the same key across server restarts, the key can be sealed to the illustrates how to use the challenger API in a wolfSSL- enclave’s identity. based application. First, we define a custom certificate verification function cert_verify_cb with We illustrate the usage of the attester API in . In this the signature expected by the wolfSSL library (lines 1– particular example we use the wolfSSL library to 9). This verification callback simply wraps our library configure an endpoint accepting connections. After function doing the extended certificate validation. defining the data structures to hold the key and Later on, we register the certificate verification certificate (lines 3–5) we call our library function to callback with the wolfSSL library (lines 13–14). After create a new key and certificate (lines 7–8). the TLS handshake finished successfully, we obtain Subsequently the attester calls the wolfSSL function access to the peer’s DER encoded certificate (lines to use the newly generated key (lines 10–11) and 16–21). Next, the challenger extracts the quote from certificate (lines 13–14) with incoming connection the DER encoded certificate (lines 23–25). The peer’s requests. The simple and intuitive API enables MRENCLAVE value is compared against a reference developers to integrate our library easily into existing value to verify the SGX identity (lines 27–29). applications. Even though the example is based on wolfSSL, the 4.2. CHALLENGER flow is similar for other TLS libraries. The data The challenger extends the existing certificate structures and function signature will be different, validation logic. To determine if a server certificate is but the interface exposed by our library is generic to valid, the TLS library performs a standard set of make interoperability with other TLS libraries easy. checks: it verifies the certificate’s expiration status, if the certificate’s content matches its signature and

5. LIMITATIONS AND EXTENSIONS the number of times the certificate must be We discuss limitations and considerations when transmitted. pursuing seamless attestation via extended X.509 A significant portion of the attestation evidence certificates. consists of infrequently changing certificate chains Non-standard X.509 extensions. We embed the SGX and revocation lists. While it is certainly convenient to identity information in custom X.509 extensions. have all the attestation evidence available from a X.509 extensions can be marked as critical. If a client single source, it may be more cost effective if the encounters an unknown critical extension, the default verifier obtains these long-lived inputs through a is to abort the connection. If the attester only expects different channel and caches them. As a result, the Intel SGX-aware clients, it is sensible to mark the attester does not need to transmit the long-lived extensions critical. If the client includes Intel SGX- evidence with every TLS handshake. unaware legacy clients, the extensions should not be Self-signed certificate. The attester creates a self- marked critical to allow backwards compatibility. A signed certificate that represents its identity. This legacy client may still complain about a self-signed may pose problems with legacy clients. For example, certificate. in the case of HTTPS, clients expect a known trusted Clients wishing to make use of the Intel SGX identity CA to sign the certificate. If the certificate is self- included in the X.509 certificate need to extract this signed, the client’s certificate validation logic will data. To reuse existing APIs, it may make sense to fold abort the handshake. A self-signed certificate will also the Intel SGX identity attributes into established lose the binding between the server’s domain name X.509 fields. For example, the Common Name (CN) and the key as vouched for by the CA. attribute could hold a copy of MRENCLAVE. When A solution around this dilemma is to have a trusted validating the certificate’s Intel SGX extensions fields, CA sign the extended certificate. With protocols such the verifier must verify that the Intel SGX values as the Automated Certificate Management encoded in the common attributes match the ones Environment (ACME) to streamline the issuance of embedded in the quote. certificates [24], this is one possibility to combine Certificate size. Including all the attestation evidence traditional X.509 identities with Intel SGX identities. into the RA-TLS certificate increases its size Alternatively, if the attester has access to an significantly compared to established use cases. For intermediate CA certificate, this can be used to sign example, a typical HTTPS certificate is around 1100 the Intel SGX-extended certificate. In this way, the byte (DER format)3 while an RA-TLS certificate is leaf certificate chains back to a PKI trust root, albeit around 6200 bytes for EPID attestation and at least at the added burden to securely handle the 11,000 bytes for ECDSA attestation. intermediate CA’s key.

The size increase of the certificate may be relevant for Certificate Revocation Lists (CRLs). For ECDSA, the attesters that establish new connections frequently verifier does not know if TCB information or PCK CRLs since the certificate’s size dominates the overall are current. An attacker may break a platform and use handshake-related traffic volume. Also, some TLS outdated CRLs to convince a verifier of its implementations use statically allocated buffers that trustworthiness. A non-enclave verifier can inspect might be too small to hold a large certificate leading the CRLs validity period to determine if they are to failed validations. outdated. Due to the lack of a trusted time source this is impossible for a verifier running in an enclave. One option is to compress the attestation evidence stored in the certificate. A lightweight and fast To protect against outdated CRLs and certificates, compression algorithm such as LZ can already reduce instead of relying on CRLs contained in the RA-TLS the certificate’s size by about 50%. If the client certificate, the verifier may want to obtain CRLs population is stable, TLS session resumption reduces independently at appropriate intervals. Alternatively, it might make sense to introduce an OCSP service or OCSP-staple responses of the API endpoints serving

3 17-09-12-1505178001-https_get_443_certs.gz -- We https://scans.io/data/rapid7/sonar.ssl/20170912/20 used this data set for the certificate related statistics.

the TCB info and PCK certificates. Ultimately though, extensions already plague the overall security of TLS even the stapled versions of PCK certificates and TCB [28]. information may be outdated and assessing the freshness of the attestation evidence requires a Armknecht et al. [1] also identified the channel trusted time source within the enclave. binding problem as crucial to the value remote attestation provides. Armknecht et al. propose a 6. RELATED WORK generic protocol that combines key exchange and remote attestation to avoid relay/masquerading The TLS protocol provides authentication, integrity, attacks. However, they do not integrate the generic and privacy for data transmitted across untrusted protocol into any existing secure communication communication lines. However, people have protocol like TLS or IPsec. We integrated our solution cautioned that “Using encryption on the Internet is with three existing open-source TLS libraries, making the equivalent of arranging an armored car to deliver it directly usable to applications building on those credit-card information from someone living in a libraries. cardboard box to someone living on a park bench.” [25]. The reason being that it is far easier to subvert In subsequent work [29], Armknecht et al. propose the endpoint than the channel. alternative protocols to address performance concerns with software that frequently needs to Leveraging novel hardware security features, like provide attestations. Since our work is based on Intel Intel SGX, makes it significantly harder to subvert the SGX, as opposed to a TPM, these performance endpoint. Still, moving the endpoint into an enclave is concerns do not apply. Attestation is cheap and its insufficient. What is needed is a way to bind the overall cost dominated by the communication latency endpoint to a particular execution context, i.e., an to IAS. Since challengers do not contact the enclave. Otherwise, the system is susceptible to relay attestation service there is no attestation-related attacks, where a compromised endpoint claims to communication overhead added to the TLS have certain properties, but the properties actually handshake. The information required to assess the pertain to a third system also controlled by the channel binding properties are embedded in the attacker. certificate and the challenger can verify them locally.

Previously work in this direction [7] falls under the Most similar to RA-TLS is the Finite State Attestation general umbrella of Trusted Computing [3] and Protocol (FSA) proposed by Paverd [30]. While FSA focused on Trusted Platform Modules as the ultimate uses TPM attestations, it also proposes to bind the trust anchor. Intel SGX enables a more performant secure channel to the attestation by embedding a and versatile solution compared to a resource fingerprint of the ephemeral TLS key into the constrained TPM. Hence, it is worth revisiting the attestation. problem of secure channel binding in the context of Intel SGX. 7. CONCLUSIONS Intel SGX offers a unique opportunity to enhance In [6] the authors introduce an attestation extension secure computation in otherwise untrusted to TLS. The peers exchange attestation information environments. An integral part of Intel SGX is the during the handshake. They used provisions within ability to obtain an attestation on the properties of TLS to incorporate the additional information [26]. the enclave and its platform. Integrating remote This particular TLS extension seems to be superseded attestation seamlessly with a standard secure by HelloExtensions messages in more recent versions channel protocol greatly simplifies the use of remote of TLS. We decided to embed the additional channel attestation in practice. We developed a library that binding information into the certificate to minimize conveniently encapsulates the attestation flow and changes to the TLS library. Introducing new messages verification behind a simple API. Using this interface, [27], would have required changes to the library itself. developers can rely on the added assurance remote Extending the certificate validation logic is achieved attestation provides their application without having by calling TLS library hook functions from the to deal with the intricacies of implementing it application. It does not require any changes to the TLS correctly. library, making it easier to maintain and port to new TLS libraries. Complex interactions between existing A proof of concept implementation of remote attestation integrated into the TLS handshake is

available at https://github.com/cloud-security- https://software.intel.com/sites/default/files/ research/sgx-ra-tls managed/48/88/329298-002.pdf.

Acknowledgements [9] S. Johnson, V. Scarlata, C. Rozas, E. Brickell and The authors thank Vincent R. Scarlata and Daniel E. F. Mckeen, Intel® Software Guard Extensions: Smith for comments on earlier drafts of this paper. EPID Provisioning and Attestation Services, REFERENCES 2016. [10] "Attestation Service for Intel® Software Guard Extensions (Intel® SGX): API Documentation," [1] F. Stumpf, O. Tafreschi, P. Röder, C. Eckert and [Online]. Available: others, "A robust integrity reporting protocol https://software.intel.com/sites/default/files/ for remote attestation," in Second Workshop on managed/7e/3b/ias-api-spec.pdf. Advances in Trusted Computing (WATC’06 Fall), 2006. [11] "Intel® Software Guard Extensions SDK for Linux* OS," [Online]. Available: [2] H. Krawczyk, "SIGMA: The ‘SIGn-and- https://download.01.org/intel-sgx/linux-2.0 MAc’approach to authenticated Diffie-Hellman /docs/Intel_SGX_SDK_Developer_Reference_ and its use in the IKE protocols," in Annual Linux_2.0_Open_Source.pdf. International Cryptology Conference, 2003. [12] V. Scarlata, S. Johnson, J. Beaney and P. [3] "The Trusted Computing Group," [Online]. Zmijewski, "Supporting Third Party Attestation Available: https://trustedcomputinggroup.org. for Intel® SGX with Intel® Data Center Attestation Primitives," 2018. [4] TPM Main Specification Level 2 Version 1.2, Revision 116, Trusted Computing Group(R), [13] I. Corp., "Intel SGX Data Center Attestation 2011. Primitives (DCAP)," [Online]. Available: https://github.com/intel/ [5] I. Anati, S. Gueron, S. Johnson and V. Scarlata, SGXDataCenterAttestationPrimitives. "Innovative technology for CPU based attestation and sealing," in Proceedings of the [14] A. Delignat-Lavaud, C. Fournet, M. Kohlweiss, J. 2nd International Workshop on Hardware and Protzenko, A. Rastogi, N. Swamy, S. Zanella- Architectural Support for Security and Privacy, Béguelin, K. Bhargavan, J. Pan and J. K. 2013. Zinzindohoué, "Implementing and proving the TLS 1.3 record layer," in IEEE Symposium on [6] F. Armknecht, Y. Gasmi, A.-R. Sadeghi, P. Security and Privacy (SP), 2017. Stewin, M. Unger, G. Ramunno and D. Vernizzi, "An Efficient Implementation of Trusted [15] "The (Decentralized) SSL Observatory," Channels Based on Openssl," in Proceedings of [Online]. Available: the 3rd ACM Workshop on Scalable Trusted http://www.usenix.org/events/sec11/tech/ Computing, New York, NY, USA, 2008. slides/eckersley.pdf.

[7] K. Goldman, R. Perez and R. Sailer, "Linking [16] "The Transport Layer Security (TLS) Protocol Remote Attestation to Secure Tunnel Version 1.2 (RFC 5246)," [Online]. Available: Endpoints," in Proceedings of the First ACM https://tools.ietf.org/html/rfc5246. Workshop on Scalable Trusted Computing, New York, NY, USA, 2006. [17] A. Baumann, M. Peinado and G. Hunt, "Shielding applications from an untrusted cloud [8] "Intel® Software Guard Extensions with haven," in USENIX Symposium on Programming Reference," Oct 2014. [Online]. Operating Systems Design and Implementation Available: (OSDI), 2014.

[18] S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. [26] "TLS Handshake Message for Supplemental Martin, C. Priebe, J. Lind, D. Muthukumaran, D. Data (RFC 4680)," [Online]. Available: O'Keeffe, M. L. Stillwell, D. Goltzsche, D. Eyers, https://tools.ietf.org/html/rfc4680. R. Kapitza, P. Pietzuch and C. Fetzer, "SCONE: Secure Linux Containers with Intel SGX," in [27] "Transport Layer Security (TLS) Extensions: Proceedings of the 12th USENIX Conference on Extension Definitions (RFC 6066)," [Online]. Operating Systems Design and Implementation, Available: https://tools.ietf.org/html/rfc6066. Berkeley, 2016. [28] K. Bhargavan, A. D. Lavaud, C. Fournet, A. [19] C.-C. Tsai, D. E. Porter and M. Vij, "Graphene- Pironti and P. Y. Strub, "Triple handshakes and SGX: A practical library OS for unmodified cookie cutters: Breaking and fixing applications on SGX," in 2017 USENIX Annual authentication over TLS," in IEEE Symposium on Technical Conference (USENIX ATC), 2017. Security and Privacy, 2014.

[20] S. Shinde, D. Le Tien, S. Tople and P. Saxena, [29] F. Stumpf, A. Fuchs, S. Katzenbeisser and C. "PANOPLY: Low-TCB Linux Applications with Eckert, "Improving the Scalability of Platform SGX Enclaves," in Network and Distributed Attestation," in Proceedings of the 3rd ACM System Security Symposium, 2017. Workshop on Scalable Trusted Computing, New York, NY, USA, 2008. [21] "wolfSSL," [Online]. Available: https://www.wolfssl.com/. [30] A. Paverd, "Enhancing Communication Privacy Using Trustworthy Remote Entities," University [22] "mbedTLS," [Online]. Available: of Oxford, 2015. https://tls.mbed.org. [31] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. [23] "OpenSSL," [Online]. Available: Rozas, H. Shafi, V. Shanbhogue and U. R. https://www.openssl.org. Savagaonkar, "Innovative instructions and software model for isolated execution," in [24] R. Barnes, J. Hoffman-Andrews and J. Kasten, Proceedings of the 2nd International Workshop "Automatic Certificate Management on Hardware and Architectural Support for Environment (ACME), internet draft (work-in- Security and Privacy, 2013. progress)," [Online]. Available: https://tools.ietf.org/html/draft-ietf-acme- acme-08.

[25] G. Spafford, "The Risks Digest 19.37," [Online]. Available: http://catless.ncl.ac.uk/ Risks/19.37.html.

Intel provides these materials as-is, with no express or implied warranties. All products, dates, and figures specified are preliminary, based on current expectations, and are subject to change without notice. Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at http://intel.com. Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance. Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries. *Other names and brands may be claimed as the property of others.