Patent Application
20190065406
The present disclosure pertains in general to data processing systems and in particular to computer security.
Intel Corporation has created an Intel® architecture extension designed to increase the security of application code and data. This technology is referred to under the name or trademark of “Intel® Software Guard Extensions” or “Intel® SGX.” This technology helps application developers to protect select code and data from disclosure or modification. Intel® SGX makes such protection possible through the use of enclaves. As described in greater detail below, one aspect of an enclave is that it provides a protected area of execution in memory. In particular, a data processing system may use an enclave to prevent hardware and software that reside outside of an enclave from accessing or modifying code and data inside that enclave. Thus, an enclave may protect the code and data in that enclave from disclosure or modification. Therefore, a data processing system may use an enclave to protect the state of the code in that enclave. In particular, as indicated by the Wikipedia® entry for “Software Guard Extensions,” Intel® SGX involves a set of central processing unit (CPU) code instructions “that allows user-level code to allocate private regions of memory, called enclaves, that are protected from processes running at higher privilege levels.” Application developers can cause a data processing system to put application code into an enclave by using special instructions in the processor architecture and by using software that has been made available to developers via the Intel® SGX software development kit (SDK). In addition, Intel® SGX includes features which enable an enclave to provide cryptographic proof of its identity to a remote entity. Intel® SGX features also support remote attestation.
Also, some data processing systems may use similar technology from other manufacturers to manage enclaves and to support remote attestation.
For purposes of this disclosure, an “enclave” is a portion of the random access memory (RAM) of a data processing system (e.g., a set of pages) that is protected by the data processing system from software that runs in the data processing system at a higher privilege level than the software in the enclave. For instance, the OS in a data processing system may be unable to access the portion of RAM that has been allocated to an application in that data processing system, once that portion of RAM has been configured as an enclave. An enclave may also be referred to as a “trusted execution environment.” Also, for purposes of this disclosure, software that executes within an enclave may be referred to as “enclave-protected software” (EPS), and software that executes outside of that enclave may be referred to as “external software.”
In many cases, it may be desirable or necessary for EPS to communicate securely with external software. However, conventional technology leaves developers of EPS with the non-trivial task of securing extra-enclave communications. Accordingly, the developer of EPS may also develop a custom communication protocol to enable the EPS to communicate securely with external software. However, developing and using a custom communication protocol may present various disadvantages. For instance, developing a custom communication protocol may substantially increase the amount of work required of the developer of the EPS. Also, the custom communication protocol may require customization of the external software. In addition, a custom communication protocol may not be as secure or reliable as a well-established, standardized communication protocol.
Features and advantages of the present invention will become apparent from the appended claims, the following detailed description of one or more example embodiments, and the corresponding figures, in which:
A conventional data processing system typically includes a processor in communication with RAM. The data processing system may load the software into the RAM for execution. That software may include an operating system (OS) that runs at a high level of privilege and one or more applications that run at a lower level of privilege. For instance, the OS may run in ring 0, and the applications may run in ring 3. In an older data processing system, the software in ring 0 may be able to access all of the RAM, but an application in ring 3 may only be able to access the portion of RAM that has been allocated to that application.
As indicated above, a newer data processing system may include technology that can be used to prevent software (e.g., an OS) which runs at a high level of privilege from accessing memory that has been allocated to an application which runs at a lower level of privilege. In particular, a newer data processing system may include technology that enables an application to run in an enclave. In one embodiment, a data processing system may use technology like Intel® SGX to manage enclaves and to support remote attestation. More information on enclaves and on Intel® SGX is available on the Internet at locations such as the following sites (identified as suffixes to be appended to the end of the root address of “software.intel.com”): /en-us/sgx and/en-us/sgx/resource-library. More information is also available at locations such as the following sites (identified as suffixes to be appended to the end of the root address of “software.intel.com/en-us/blogs”): /2013/09/26/protecting-application-secrets-with-intel-sgx and/2016/05/04/introduction-to-intel-sgx-sealing. In other embodiments, data processing systems may use similar technology from other manufacturers to manage enclaves and to support remote attestation.
As indicated above, for purposes of this disclosure, software that runs in an enclave may be referred to as “enclave-protected software” or “EPS,” and software that runs outside of that enclave may be referred to as “external software.” The EPS may be an application, for instance. And the external software may be different application in a different enclave, for instance. Also, communications from an endpoint in an enclave to an endpoint outside of that enclave (i.e., communications between EPS and external software) may be referred to as “extra-enclave communications.” When the endpoints for extra-enclave communications reside in different enclaves, the extra-enclave communications may be referred to as an “inter-enclave communications.”
As indicated above, it may be desirable or necessary for EPS to communicate securely with external software. In other words, it may be desirable or necessary to protect extra-enclave communications. For purposes of this disclosure, technology for protecting extra-enclave communications may be referred to as technology for “extra-enclave communication protection” (EECP).
As indicated above, a conventional enclave does not automatically protect the extra-enclave communications of the EPS. In other words, in a conventional system, if the EPS communicates with an endpoint outside of the enclave, the system does not automatically provide EECP. Accordingly, as indicated above, the developer of the EPS may also develop a custom communication protocol to enable the EPS to communicate securely with external software. For instance, one approach to provide for EECP would be for the endpoints to use Intel® SGX attestation as a one aspect of a custom protocol for secure extra-enclave communications. For instance, to establish a shared secret between two endpoints via a modified SIGMA protocol, that approach could use a software interface that is exposed by the Intel® SGX SDK. (More information about SIGMA protocols may be obtained from the Wikipedia® entry for “Proof of knowledge.”) Thus, EPS could establish a shared secret with external software as one aspect of a custom protocol to provide for EECP. But establishing a shared secret solves only part of the secure communication challenge, since the endpoints would also need to implement a secure channel abstraction (for reading and writing), based on the shared secret.
By contrast, in an embodiment according to the present disclosure, endpoints use the conventional Transport Layer Security (TLS) protocol to implement EECP. TLS is a cryptographic communications protocol that provides communications security between two endpoints. Those endpoints may reside in separate data processing systems, and they may communicate over a computer network. Alternatively, those endpoints may reside in the same data processing system. The protocol referred to as “Secure Sockets Layer” (SSL) was a predecessor of TLS. Vetted implementations of TLS include implementations such as those referred to as “OpenSSL,” “mbed TLS,” “wolfSSL,” and others.
In one embodiment, the endpoints may use the TLS 1.2 protocol and its corresponding standard request for comments (RFC) 5246. (Additional information on RFC 5246 is available on the Internet at www.rfc-base.org/rfc-5246.html.) Nevertheless, EECP as described herein, may be adapted to future versions of TLS or to other protocols using public key certificates to authenticate endpoints. One embodiment may be based on the current remote attestation flow for TLS. However, EECP may be adapted to future iterations of the attestation flow, for instance by changing the specific fields embedded in the public key certificate. Additional information pertaining to attestation may be found in the article entitled “Attestation Transparency: Building secure Internet services for legacy clients” by Jethro Beekman, John Manferdelli, and David Wagner, dated Mar. 15, 2016.
In the field of digital communications, a handshake is an automated sequence of interactions between two endpoints that enables the endpoints to establish a communication session or channel. During that sequence of interactions, the endpoints exchange information that the endpoints then use to establish the communication channel. After successful completion of the handshake, the endpoints may conduct regular communications via that established channel. For instance, during the handshake for a secure communication channel, the endpoints may exchange information pertaining to the keys that will be used to encrypt and decrypt the messages that will subsequently be sent via that secure channel.
As indicated above, the present disclosure describes technology for securing extra-enclave communications. In particular, the present disclosure describes technology for establishing trust between EPS and external software, in connection with a handshake process to establish a TLS channel between the EPS and the external software. For purposes of this disclosure, technology for establishing trust between EPS and external software, in connection with a handshake process to establish a TLS channel between the EPS and the external software, may be referred to as “enclave trust establishment technology” (ETET). In one embodiment, as described in greater detail below, ETET may include a certificate creation module that is used by an attester such as a server application and a certificate verification module that is used by a challenger such as a client application.
For purposes of this disclosure, the term “trust” refers to one or more determinations made by a first endpoint concerning the expected reliability of a second endpoint. The first endpoint may make trust determinations based on one or more attributes of the second endpoint. Those attributes may pertain to the hardware and/or software security features of the second endpoint, the integrity of one or more components of the second endpoint, the identity of the entity that created one or more components of the second endpoint (e.g., whether the developer of a component is the expected developer or an approved developer), etc. For instance, as described in greater detail below, if a client is trying to establish a TLS session with a server, during the handshake process, the client may receive data from the server pertaining to one or more attributes of the server, and the client may determine whether or not the server is trustworthy, based at least in part on that data.
To illustrate EECP and, in particular, ETET, the present disclosure refers to two different endpoints: a challenger and an attester. One aspect of ETET is that the challenger is trying to establish a secure channel (e.g., a TLS channel) to an attester that runs in an enclave. Another aspect of ETET is that the attester is trying to show the challenger that the attester is indeed in a genuine, trustworthy enclave. In addition, the attester wants to tie the secure channel to the attester's enclave. To enable those ends to achieved (e.g., to show the challenger that the attester is trustworthy), as described in greater detail below, the attester obtains a platform attestation report (PAR) and a corresponding quote regarding the identity of the attester and the integrity of attester's enclave. The attester may automatically perform the operations needed to obtain the PAR and the corresponding quote at startup, for instance.
Moreover, Intel® SGX enables the attester to include arbitrary user data in the PAR and in the quote, and the attester uses those abilities to tie a TLS key pair of the attester to this particular enclave instance. For purposes of this disclosure, the term “TLS key pair” refers to the public/private key pair which includes the public key for the attester to send to the challenger during the TLS handshake process as part of the server-hello message. However, the attester need not directly include the public key (of the TLS key pair) in the PAR. Instead, the attester may include a cryptographic hash of the public key. Nevertheless, by including the hash of that public key, the attester enables the challenger to determine that the PAR does indeed pertain to the enclave of the attester. In other words, the cryptographic hash of the public key binds the PAR to the enclave of the attester.
In addition, the attester may send the quote to a remote attestation service operated by a third party (e.g., “Intel® Attestation Service” (IAS) or a remote attestation service provided by any other suitable provider), and that attestation service may reply with a signed attestation verification report. (For purposes of this disclosure, data processing system 120 (or the entity that controls data processing system 120) may be referred to as the “first party, the developer of server application 146 may be referred to as the “second party,” and any other entity may be referred to as a “third party”.) The attester may send that signed attestation verification report to the challenger, and the challenger may use the signed attestation verification report to determine whether or not the attester is trustworthy.
In particular, in one embodiment, the attester generates a unique, ephemeral public/private key pair as the TLS key pair, and the private key never leaves the enclave of the attester. The attester also generates a public key certificate with one or more extensions that include fields which tie the certificate to this enclave and which enable the challenger to verify that the attester is indeed in a genuine, trustworthy enclave. For purposes of this disclosure, a public key certificate with fields that enable the challenger to verify that the attester is in a genuine, trustworthy enclave may be referred to as an “enclave trust establishment (ETE) certificate.” Similarly, those fields may be referred to collectively as an “ETE extension.” In one embodiment, the fields in the ETE extension are specific to Intel® SGX. In other embodiments, those fields may be designed to contain data from other technologies for managing enclaves. In one embodiment, to exchange identity-related information, the endpoints use an ETE certificate that is formatted as an X.509 certificate. More information on X.509 certificates is provided in the Wikipedia® entry for “X.509” at en.wikipedia.org/wiki/X.509. In one embodiment, an ETE certificate is formatted like an X.509 certificate, and it includes at least one ETE extension.
Depending on identity requirements, an ETE certificate can be self-signed (i.e., signed by the attester in the enclave) or signed by a trusted third party. The attester sends the ETE certificate to the challenger during the TLS handshake process. The challenger then performs specific checks on the enclave of the attester, based on the certificate's ETE extension. Those checks may be performed in addition to or in place of some or all of the standard certificate-verification operations. If the challenger is able to verify the data in the ETE extension, the TLS handshake continues and may complete as normal. During or after the handshake, the challenger may also extract other fields of interest from the certificate (e.g., fields providing a measurement or identity of the enclave of the attester and/or fields pertaining to an entity that is responsible for the content of the attester) to perform access control and authentication.
The present disclosure describes one or more embodiments or scenarios involving a client application as the challenger and a server application as the attester. In particular, the server application and the client application use ETET to facilitate EECP.
As illustrated, data processing system 120 includes a processor 130 in communication with RAM 140, nonvolatile storage (NVS) 134, and a network interface controller (NIC) 122. Data processing system 120 may also include various other hardware components in communication (directly or indirectly) with processor 130. Data processing system 120 may copy software from NVS 134 into RAM 140 for execution.
In the embodiment of
In one embodiment, NVS 134 also includes an ETE library 141 and a TLS library 142, and those libraries include modules for performing cryptographic operations such as certificate parsing, hash sum processing, signature processing, etc. Server application 146 and/or client application 144 may use code from ETE library 141 and TLS library 142 to perform some or all of the operations described below with regard to providing for EECP. For instance, TLS library 142 may include code for performing conventional TLS operations, and ETE library 141 may include code for establishing enclave trust in connection with a TLS handshake process.
In particular, ETE library 141 may include a certificate creation module (CCM) 147 that server application 146 uses to create an ETE certificate 190, as described in greater detail below. ETE library 141 may also include a certificate validation module (CVM) 149 that client application 144 uses to validate ETE certificate 190 (e.g., to perform extended certificate verification), as described in greater detail below.
In one embodiment, CCM 147 is statically linked into server application 146, and CVM 149 is statically linked into client application 144. Accordingly, in
As described in greater detail below, ETET may be implemented, at least in part, by extending an X.509 certificate with certain fields pertaining to a server enclave (e.g., fields for authentication information provided by Intel® SGX or similar technologies and fields for third-party verification) and by utilizing existing library extension points to include code for certificate creation and certificate verification, in such a way as to enable a challenger to place confidence in the information in the certificate extension.
Server enclave 170 may also include additional items to facilitate ETET. For instance, as illustrated in
In the embodiment of
In particular,
In one embodiment, as illustrated in
Referring again to
Initialization causes processor 130 to perform a launch preparation process. Part of that launch preparation process is for processor 130 to complete its measurement of server enclave 170. That measurement is depicted in
Referring again to
As shown at block 316 of
However, if server enclave 170 passes authentication, processor 130 then uses a private key belonging to processor 130 to sign PAR 136, as shown at block 328. In one embodiment, that private key is part of enhanced privacy key (EPK) group. For purposes of this disclosure, an EPK group is a group of keys that includes a public key and two or more private keys, where the public key can be used to verify signatures that have been generated with any of the private keys. For instance, an EPK group may be generated according to technology provided by Intel Corporation under the name or trademark of Intel® Enhanced Privacy ID (EPID). For purposes of this disclosure, the private keys from an EPK group may be referred to as “private EPKs,” and the public key from an EPK group may be referred to as a “public EPK.” For instance,
As shown at block 332, server application 146 may then send server enclave quote 138 to TPAS 80 for third-party verification. As shown at block 340, TPAS 80 then determines whether server enclave quote 138 is valid. For instance, TPAS 80 may use public EPK 131 to determine whether processor signature 133 in server enclave quote 138 is valid, including whether server enclave quote 138 has good integrity, and whether processor signature 133 was created with an approved private EPK, which would indicate that the source of server enclave quote 138 (i.e., data processing system 120) has approved security features, including proper support for enclaves. In other embodiments, TPASs may use other techniques to verify quotes and similar types of messages from enclaves. If server enclave quote 138 is not valid, TPAS 80 may return an error message, as shown at block 342, and the process may then end.
However, if server enclave quote 138 is valid, as shown at block 344, TPAS 80 may generate AVR 81, and TPAS 80 may then use a TPAS private key 83 (as shown in
After server application 146 receives attestation verification reply 82 from TPAS 80, the process of
However, if server application 146 did not receive an error from TPAS 80, server application 146 may extract attestation verification evidence 84 from attestation verification reply 82, as shown at block 224. As shown at block 226, server application 146 may then use attestation verification evidence 84 to build ETE certificate 190.
In one embodiment, ETE certificate 190 is a formatted as public key certificate such as an X.509 certificate, and it includes an ETE extension that includes fields to provide for ETE. For instance, the fields in the ETE extension may contain identity information for server enclave 170. For example, in one embodiment, the fields include Intel® SGX-related identity information such as (a) an enclave measurement (MRENCLAVE) and (b) a so-called “Signing Identity” (MRSIGNER) provided by an authority (e.g., the developer of server application 146) which signs the enclave prior to distribution.
In addition or alternatively, those fields includes data that enables the challenger (client application 144) to verify (i) that the attester (server application 146 and/or server enclave 170) is indeed a genuine enclave and (ii) that the public key of the attester in ETE certificate 190 (SEPK 174) is tied to this enclave instance. For instance, those fields may contain data associated with third-party verification of server enclave 170. Accordingly, in the embodiment of
In particular, server application 146 populates various fields in the ETE extension 191 of ETE certificate 190 (as shown in
As shown at block 228 of
As shown at block 410 of
In addition, server application 146 may send ETE certificate 190 to client application 144, as illustrated by the third arrow in
As shown at block 420 of
As shown at blocks 250 and 252 of
For instance, as shown in
Once server application 146 received EncryptedPS from client application 144, server application 146 uses server enclave private key 173 to decrypt EncryptedPS into the “premaster secret” value. Server application 146 then uses the “client random,” “server random,” and “premaster secret” values to generate a “master secret” value that matches the value generated by client application 144. Client application 144 and server application 146 may then use that “master secret” value to generate one or more TLS session keys, to be used to protect subsequent communications between client application 144 and server application 146. For instance, client application 144 and server application 146 may use a TLS session key after client application 144 and server application 146 send each other “change cipher specification” and “finished” messages, as shown near the bottom of
Consequently, if server enclave 170 does not have the private key that corresponds to SEPK 174, server enclave 170 will not be able to decrypt EncryptedPS. Therefore, server enclave 170 will not be able to generate the proper “master secret” value, or any TLS session keys based on that “master secret” value.
As has been described, ETET enables developers to leverage protocols like SSL and/or TLS to set up secure channels between applications in enclaves and applications outside of those enclaves. The technology described herein may be used to seamlessly integrate features such as those provided by Intel® SGX remote attestation into a standard TLS channel protocol. Accordingly, ETET may be used with existing TLS libraries and with the existing TLS channel abstraction. However, the X.509-based identity is augmented with attestation attributes like those provided by Intel® SGX or similar technologies. For instance, an attester may use an SSL/TLS certificate as a carrier for attestation and related identity information derived from Intel® SGX technologies or similar technologies. An attester may also bind its TLS key pair to its enclave by embedding a cryptographic hash of the public key as user data into the enclave's report/quote. Integrating ETET according to the present disclosure into an application may be more straightforward, secure, reliable, and flexible than the attempting to integrate other methods of attestation.
Many different types of data processing systems may use ETET to advantage in many different kinds of environments or deployments. For instance, Intel® SGX provides attractive features for the cloud space, and ETET may enhance the capabilities of data processing systems in that environment. In at least one embodiment, ETET enables a data processing system to use Intel® SGX to protect cloud applications by excluding the privileged software from the TCB. Therefore, ETET may be important to fully realize the potential and value of Intel® SGX or similar technologies for cloud security. Moreover, by using ETET, a cloud application can easily support attestation by simply integrating SSL. As a result, Intel® SGX or similar technologies could be adopted more easily and quickly.
The present teachings may be used to provide a secure channel protocol that benefits from Intel® SGX and/or related technologies, and that protocol may be public and standardized. For instance, the present teachings may be used to provide transparent encryption of inter-enclave communication using SSL/TLS, with Intel® SGX and/or related technologies for local and remote attestation for authentication. Thus, ETET may be used to bring authentication information such as that provided by Intel® SGX or similar technologies into the SSL/TLS protocol, thereby enabling applications to easily access that authentication information.
In at least one embodiment, ETET may be implemented as an integrated solution that provides an attested secure channel. For instance, a developer may use ETET instead of (a) using the SIGMA remote attestation protocol to establish a shared secret and then (b) using a custom or proprietary secure channel on top of that shared secret. For instance, a developer may use ETET to provide a secure channel instead of building a secure channel on top of SIGMA using, for example, TLS with the SIGMA key used as a pre-shared key (PSK) for TLS. Alternatively, a developer may use ETET to provide a secure channel instead of running remote attestation inside an unauthenticated TLS channel. ETET thus allows the developer to avoid issues regarding secure channel binding and the breaking of abstraction layers for applications. Moreover, existing applications that do not use Intel® SGX or similar technologies may already use TLS to secure communications. ETET may make it easy to port these applications to Intel® SGX or similar technologies, to provide attested secure channels.
Although certain example embodiments are described herein, one of ordinary skill in the art will understand that those example embodiments may easily be divided, combined, or otherwise altered to implement additional embodiments. In the present disclosure, expressions such as “an embodiment,” “one embodiment,” and “another embodiment” are meant to generally reference embodiment possibilities. Those expressions are not intended to limit the invention to particular embodiment configurations. As used herein, those expressions may reference the same embodiment or different embodiments, and those embodiments are combinable into other embodiments. In light of the principles and example embodiments described and illustrated herein, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles.
Also, as described above, a device may include instructions and other data which, when accessed by a processor, cause the device to perform particular operations. For purposes of this disclosure, instructions which cause a device to perform operations may be referred to in general as software. Software and the like may also be referred to as control logic. Software that is used during a boot process may be referred to as firmware. Software that is stored in nonvolatile memory may also be referred to as firmware. Software may be organized using any suitable structure or combination of structures. Accordingly, terms like program and module may be used in general to cover a broad range of software constructs, including without limitation application programs, subprograms, routines, functions, procedures, drivers, libraries, data structures, processes, microcode, and other types of software components. Also, it should be understood that a software module may include more than one component, and those components may cooperate to complete the operations of the module. Also, the operations which the software causes a device to perform may include creating an operating context, instantiating a particular data structure, etc. Any suitable operating environment and programming language (or combination of operating environments and programming languages) may be used to implement software components described herein.
A medium which contains data and which allows another component to obtain that data may be referred to as a machine-accessible medium or a machine-readable medium. In one embodiment, software for multiple components is stored in one machine-readable medium. In other embodiments, two or more machine-readable media may be used to store the software for one or more components. For instance, instructions for one component may be stored in one medium, and instructions another component may be stored in another medium. Or a portion of the instructions for one component may be stored in one medium, and the rest of the instructions for that component (as well instructions for other components), may be stored in one or more other media. Similarly, software that is described above as residing on a particular device in one embodiment may, in other embodiments, reside on one or more other devices. For instance, in a distributed environment, some software may be stored locally, and some may be stored remotely. Similarly, operations that are described above as being performed on one particular device in one embodiment may, in other embodiments, be performed by one or more other devices.
Accordingly, alternative embodiments include machine-readable media containing instructions for performing the operations described herein. Such media may be referred to in general as apparatus and in particular as program products. Such media may include, without limitation, tangible non-transitory storage components such as magnetic disks, optical disks, dynamic RAM, static RAM, read-only memory (ROM), etc., as well as processors, controllers, and other components that include data storage facilities. For purposes of this disclosure, the term “ROM” may be used in general to refer to nonvolatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc.
It should also be understood that the hardware and software components depicted herein represent functional elements that are reasonably self-contained so that each can be designed, constructed, or updated substantially independently of the others. In alternative embodiments, many of the components may be implemented as hardware, software, or combinations of hardware and software for providing the functionality described and illustrated herein. In some embodiments, some or all of the control logic for implementing the described operations may be implemented in hardware logic (e.g., as microcode in an integrated circuit chip, as a programmable gate array (PGA), as an application-specific integrated circuit (ASIC), etc.).
Additionally, the present teachings may be used to advantage in many different kinds of data processing systems. Such data processing systems may include, without limitation, accelerators, systems on a chip (SOCs), wearable devices, handheld devices, smartphones, telephones, entertainment devices such as audio devices, video devices, audio/video devices (e.g., televisions and set-top boxes), vehicular processing systems, personal digital assistants (PDAs), tablet computers, laptop computers, portable computers, personal computers (PCs), workstations, servers, client-server systems, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframe computers, mini-computers, and other devices for processing or transmitting information. Accordingly, unless explicitly specified otherwise or required by the context, references to any particular type of data processing system (e.g., a PC) should be understood as encompassing other types of data processing systems, as well. A data processing system may also be referred to as an apparatus. The components of a data processing system may also be referred to as apparatus.
Also, unless expressly specified otherwise, components that are described as being coupled to each other, in communication with each other, responsive to each other, or the like need not be in continuous communication with each other and need not be directly coupled to each other. Likewise, when one component is described as receiving data from or sending data to another component, that data may be sent or received through one or more intermediate components, unless expressly specified otherwise. In addition, some components of the data processing system may be implemented as adapter cards with interfaces (e.g., a connector) for communicating with a bus. Alternatively, devices or components may be implemented as embedded controllers, using components such as programmable or non-programmable logic devices or arrays, ASICs, embedded computers, smart cards, and the like. For purposes of this disclosure, the term “bus” includes pathways that may be shared by more than two devices, as well as point-to-point pathways. Similarly, terms such as “line,” “pin,” etc. should be understood as referring to a wire, a set of wires, or any other suitable conductor or set of conductors. For instance, a bus may include one or more serial links, a serial link may include one or more lanes, a lane may be composed of one or more differential signaling pairs, and the changing characteristics of the electricity that those conductors are carrying may be referred to as signals on a line. Also, for purpose of this disclosure, the term “processor” denotes a hardware component that is capable of executing software. For instance, a processor may be implemented as a central processing unit (CPU), a processing core, or as any other suitable type of processing element. A CPU may include one or more processing cores, and a device may include one or more CPUs.
Also, although one or more example processes have been described with regard to particular operations performed in a particular sequence, numerous modifications could be applied to those processes to derive numerous alternative embodiments of the present invention. For example, alternative embodiments may include processes that use fewer than all of the disclosed operations, process that use additional operations, and processes in which the individual operations disclosed herein are combined, subdivided, rearranged, or otherwise altered. Embodiments of technology for establishing trust during a TLS handshake include the following examples:
Example A1 is a data processing system with technology for protecting extra-enclave communications. The data processing system comprises RAM and a processor in communication with the RAM. The processor, when powered on, is capable of (a) allocating a portion of the RAM to a server application that is to execute at a low privilege level, (b) creating an enclave that comprises the portion of the RAM allocated to the server application, and (c) protecting the RAM in the enclave from access by software that executes at a high privilege level. The data processing system further comprises a machine-accessible medium responsive to the processor, and instructions in the machine-accessible medium. When executed by the processor, the instructions enable the server application to (a) obtain a platform attestation report for the enclave from the processor, wherein the platform attestation report includes attestation data from the processor attesting to integrity of the enclave; (b) generate a public key certificate for the server application, wherein the public key certificate comprises the attestation data; and (c) utilize the public key certificate for the server application to establish a TLS communication channel between the server application in the enclave and a client application outside of the enclave.
Example A2 is a data processing system according to Example A1, wherein the instructions, when executed, further enable the server application to (a) after obtaining the platform attestation report for the enclave from the processor, use the platform attestation report to obtain a signed attestation verification report (SAVR) from a third-party attestation server (TPAS); and (b) include the SAVR in the public key certificate. Also, the operation of utilizing the public key certificate for the server application to establish the TLS communication channel comprises utilizing the SAVR from the TPAS to establish the TLS communication channel.
Example A3 is a data processing system according to Example A1, wherein the instructions, when executed, further enable the server application to generate, in the enclave, a private key and a corresponding public key for the server application. Also, the platform attestation report comprises a hash value derived from the public key of the server application, and the public key certificate comprises the hash value. Example A3 may also include the features of Example A2.
Example A4 is a data processing system according to Example A1, wherein the operation of generating the public key certificate for the server application comprises (a) formatting the public key certificate with an X.509 format and (b) including the attestation data in the public key certificate as an X.509 extension. Example A4 may also include the features of any one or more of Examples A2 and A3.
Example A5 is a data processing system according to Example A1, wherein the instructions in the machine-accessible medium, when executed by the processor, implement the server application and a server launch module. Also, the operations of (a) allocating the portion of the RAM to the server application and (b) creating the enclave that comprises the portion of the RAM allocated to the server application are performed by the server launch module. Example A5 may also include the features of any one or more of Examples A2 through A4.
Example A6 is a data processing system according to Example A1, wherein the machine-accessible medium further comprises a developer's enclave certificate for the enclave, wherein the developer's enclave certificate comprises a predetermined developer's measurement of the enclave and a digital signature of the developer, based on the predetermined developer's measurement of the enclave. Also, the processor, when powered on, is capable of using the developer's enclave certificate to evaluate trustworthiness of the server application before allowing the server application to execute in the enclave. Example A6 may also include the features of any one or more of Examples A2 through A5.
Example A7 is a data processing system according to Example A1, wherein the operation of utilizing the public key certificate for the server application to establish the TLS communication channel comprises (a) at the server application, receiving a client-hello message from the client application and (b) automatically sending the public key certificate for the server application to the client application, in response to receiving the client-hello message. Example A7 may also include the features of any one or more of Examples A2 through A6.
Example B1 is at least one non-transitory machine-accessible medium comprising computer instructions for protecting extra-enclave communications. The computer instructions, in response to being executed on a data processing system, enable the data processing system to (a) allocate a portion of RAM in the data processing system to a server application that is to execute at a low privilege level; (b) create an enclave that comprises the portion of the RAM allocated to the server application, wherein the enclave protects the RAM in the enclave from access by software that executes at a high privilege level; (c) obtain, at the server application, a platform attestation report for the enclave from the processor, wherein the platform attestation report includes attestation data from the processor attesting to integrity of the enclave; (d) generate, at the server application, a public key certificate for the server application, wherein the public key certificate comprises the attestation data; and (e) utilize the public key certificate for the server application to establish a TLS communication channel between the server application in the enclave and a client application outside of the enclave.
Example B2 is at least one non-transitory machine-accessible medium according to Example B1, wherein the instructions, when executed, further enable the server application to (a) after obtaining the platform attestation report for the enclave from the processor, use the platform attestation report to obtain a signed attestation verification report (SAVR) from a third-party attestation server (TPAS); and (b) include the SAVR in the public key certificate. Also, the operation of utilizing the public key certificate for the server application to establish the TLS communication channel comprises utilizing the SAVR from the TPAS to establish the TLS communication channel.
Example B3 is at least one non-transitory machine-accessible medium according to Example B1, wherein the instructions, when executed, further enable the server application to generate, in the enclave, a private key and a corresponding public key for the server application. Also, the platform attestation report comprises a hash value derived from the public key of the server application, and the public key certificate comprises the hash value. Example B3 may also include the features of Example B2.
Example B4 is at least one non-transitory machine-accessible medium according to Example B1, wherein the operation of generating the public key certificate for the server application comprises formatting the public key certificate with an X.509 format, and including the attestation data in the public key certificate as an X.509 extension. Example B4 may also include the features of any one or more of Examples B2 through B3.
Example B5 is at least one non-transitory machine-accessible medium according to Example B1, wherein the instructions in the machine-accessible medium, when executed by the processor, implement the server application and a server launch module. Also, the operations of (a) allocating the portion of the RAM to the server application and (b) creating the enclave that comprises the portion of the RAM allocated to the server application are performed by the server launch module. Example B5 may also include the features of any one or more of Examples B2 through B4.
Example B6 is at least one non-transitory machine-accessible medium according to Example B1, wherein the machine-accessible medium further comprises a developer's enclave certificate for the enclave, wherein the developer's enclave certificate comprises a predetermined developer's measurement of the enclave and a digital signature of the developer, based on the predetermined developer's measurement of the enclave. Also, the instructions, when executed by the processor, enable the data processing system to use the developer's enclave certificate to evaluate trustworthiness of the server application before allowing the server application to execute in the enclave. Example B6 may also include the features of any one or more of Examples B2 through B5.
Example B7 is at least one non-transitory machine-accessible medium according to Example B1, wherein the operation of utilizing the public key certificate for the server application to establish the TLS communication channel comprises (a) at the server application, receiving a client-hello message from the client application, and (b) automatically sending the public key certificate for the server application to the client application, in response to receiving the client-hello message. Example B7 may also include the features of any one or more of Examples B2 through B6.
Example C1 is a method for protecting extra-enclave communications. The method comprises (a) in a data processing system with a processor in communication with RAM, allocating a portion of the RAM to a server application that is to execute at a low privilege level; (b) creating an enclave that comprises the portion of the RAM allocated to the server application, wherein the enclave protects the RAM in the enclave from access by software that executes at a high privilege level; (c) at the server application, obtaining a platform attestation report for the enclave from the processor, wherein the platform attestation report includes attestation data from the processor attesting to integrity of the enclave; (d) at the server application, generating a public key certificate for the server application, wherein the public key certificate comprises the attestation data; and (e) utilizing the public key certificate for the server application to establish a TLS communication channel between the server application in the enclave and a client application outside of the enclave.
Example C2 is a method according to Example C1, and further comprising (a) after obtaining the platform attestation report for the enclave from the processor, using the platform attestation report to obtain a signed attestation verification report (SAVR) from a third-party attestation server (TPAS); and (b) including the SAVR in the public key certificate. Also, the operation of utilizing the public key certificate for the server application to establish the TLS communication channel comprises utilizing the SAVR from the TPAS to establish the TLS communication channel.
Example C3 is a method according to Example C1, and further comprising generating, in the enclave, a private key and a corresponding public key for the server application. Also, the platform attestation report comprises a hash value derived from the public key of the server application, and the public key certificate comprises the hash value. Example C3 may also include the features of Example C2.
Example C4 is a method according to Example C1, wherein the operation of generating the public key certificate for the server application comprises formatting the public key certificate with an X.509 format, and including the attestation data in the public key certificate as an X.509 extension. Example C4 may also include the features of any one or more of Examples C2 through C3.
Example C5 is a method according to Example C 1, wherein the operations of (a) allocating the portion of the RAM to the server application and (b) creating the enclave that comprises the portion of the RAM allocated to the server application are performed by a server launch module. Also, the operation of utilizing the public key certificate for the server application to establish the TLS communication channel is performed by the server application. Example C5 may also include the features of any one or more of Examples C2 through C4.
Example C6 is a method according to Example C1, and further comprising using a developer's enclave certificate to evaluate trustworthiness of the server application before allowing the server application to execute in the enclave, wherein the developer's enclave certificate comprises a predetermined developer's measurement of the enclave and a digital signature of the developer, based on the predetermined developer's measurement of the enclave. Example C6 may also include the features of any one or more of Examples C2 through C5.
In view of the wide variety of useful permutations that may be readily derived from the example embodiments described herein, this detailed description is intended to be illustrative only, and should not be taken as limiting the scope of coverage.
This application claims priority to U.S. Provisional Patent Application No. 62/587,654, filed on Nov. 17, 2017, entitled “Methods And Apparatus To Protect Extra-Enclave Communications,” with inventors Michael Steiner, Thomas Knauth, Li Lei, Bin Xing, Mona Vij, and Somnath Chakrabarti, the disclosure of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62587654 | Nov 2017 | US |
