HK40011857B

HK40011857B - Addressing a trusted execution environment using signing key

Info

Publication number: HK40011857B
Application number: HK62020001448.3A
Authority: HK
Inventors: M·F·诺瓦克
Original assignee: 微软技术许可有限责任公司
Priority date: 2017-01-26
Filing date: 2017-12-20
Publication date: 2023-11-10

Description

Addressing trusted execution environments using signing keys

Technical Field

The present disclosure relates generally to trusted and/or isolated execution environments in computing devices, and more particularly to secure delivery of one or more secrets or keys into a trusted execution environment.

Background

The Key Management System (KMS) is a store of secrets. The secret typically has a public ID, a protection value, and a policy for controlling who can obtain the value. In some cases, the secret may also have an expiration date and other metadata, etc. In a typical use case, the requester authenticates to the KMS, establishes a secure channel, requests a secret value by providing a secret ID, and expects the KMS to return a clear secret value thereto. The value is protected from unauthorized eavesdropping and tampering by a secure channel between the requester and the KMS.

Trusted execution environment (TrEE), as used herein, may include any of the following: virtual Security Mode (VSM) trusted applications (trust), SGX applications, ARM trust zone applications, or some other similar carrier (vehicle). TrEE generally has some unique attributes. TrEE typically has a complete encryption stack (in other words, a complete menu of hash, encryption, and signature libraries using keys from secure random number generation can be assumed for various encryption primitives in the entire spectrum). TrEE also typically has or is associated with few or limited I/O facilities, often limited to request driven architectures in which requests are initiated by an untrusted "outside world". For example, a VSM trusted application may use an unauthenticated Remote Procedure Call (RPC). The TrEE may also access key material or data that is not available outside the TrEE. This allows TrEE to use untrusted I/O to store data, which is then read back, thereby ensuring tamper resistance and state confidentiality. TrEE also typically has or is associated with provable code, configuration and keying material. In particular, the provable keying material allows the TrEE to receive messages encrypted to it from a third party and to sign messages from the TrEE to the third party.

As with other applications, there may be security restrictions with KMS having TrEE. Thus, the security can be improved with keys from KMSs with or in TrEE.

Disclosure of Invention

Illustrative examples of the present disclosure include, but are not limited to, methods, systems, and various devices. In one aspect, a method for delivering protected data to a nested trusted execution environment (TrEE) associated with an untrusted requestor may be performed at least in part by a targeting protocol header or other intermediary between the requestor and a key management system or other repository of protected data. The nested TrEE may include trusted applications running on top of a secure kernel. The targeting protocol header may receive a request for protected data, a attestation statement of the secure kernel, and a key authentication statement from a potentially untrusted requestor. The key authentication assertion may bind the trusted application public encryption key and the trusted application ID. The targeting protocol header may retrieve the protected data and encrypt the protected data with the trusted application public encryption key. The targeting protocol header may then send the encrypted protected data to the requester.

Other features of the systems and methods are described below. The features, functions, and advantages can be achieved independently in various examples or may be combined in yet other examples, further details of which can be seen with reference to the following description and drawings.

Drawings

Embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which:

fig. 1A, 1B, and 1C depict three examples of systems and processes for exchanging keys between a requester and a key management system.

FIG. 2 depicts an exemplary diagram of a control program monitor implementing an isolation region or trusted execution environment (TrEE).

Fig. 3 depicts an example process for delivering protected data to a trusted TrEE using an intermediate targeting protocol header.

Fig. 4A and 4B depict another example process for delivering protected data to TrEE using an intermediate targeting protocol header.

Fig. 5A and 5B depict an example process for delivering protected data to a nested TrEE using an intermediate targeting protocol header.

FIG. 6 illustrates an example system in which one or more of the described processes may be implemented.

Fig. 7 depicts an example of a data structure for securely delivering transfer keys and/or protected data to TrEE.

Fig. 8 depicts another example process for delivering protected data to a nested TrEE using an intermediate targeting protocol header based on an external TrEE's encryption key.

Fig. 9 depicts another example process for delivering protected data to a nested TrEE using an intermediate targeting protocol header based on an internal TrEE's encryption key.

FIG. 10 depicts an example general purpose computing environment in which the techniques described herein may be implemented.

Detailed Description

Systems and techniques are described herein for securely delivering at least one key (e.g., a signing key or an encryption key) or protected data/secret to a trusted execution environment (TrEE) of a computing device, such as one or more physical or virtual computing devices. In one aspect, an intermediary may be implemented between the key requester and the key management system or entity that owns the protected data. The intermediary may be referred to herein as a targeting protocol header. The key requester may be associated with a secure execution environment or TrEE, which may include one or more of a VSM trusted application, an SGX application, an ARM trust zone application, or some other similar carrier. TrEE may be isolated from requesters. The requestor may request that one or more secrets be delivered from the targeting protocol header to the TrEE or a particular trusted application executing within the TrEE. In response to the request, the targeting protocol header may communicate with a key management system or other entity that holds secrets to obtain one or more secrets for delivery to TrEE. The targeting protocol header may specifically target the protected data at TrEE such that the protected data is not accessible to the requestor or attacker.

In some aspects, implementation of the targeting protocol header may negate the need for a secure channel between the requester and the key management system. Targeting protocol headers using the TrEE targeting techniques described herein may also enable one or more secrets or data to be sent to a TrEE or nested TrEE (e.g., a trusted application running on top of a secure kernel) so that the secrets/data cannot be accessed by the requestor. In some cases, the requestor may be untrusted or may be untrusted, such that the owner of the protected data may wish to keep the protected data from being accessed by the requestor for various reasons. In some cases, it may be difficult or cumbersome to determine that the requestor is trustworthy or to ensure that the requestor is still trustworthy. Assuming that the requestor is not trusted and that the TrEE is isolated from the requestor, many of these problems can be negated. Such isolation may greatly improve security against different types of attacks and may provide other benefits and advantages, as will be described in more detail below.

FIG. 1A illustrates an example system and process 100a for exchanging keys between a requestor and a key management system. As shown, a requestor or requesting device 120 associated with a client device or client side 110 may communicate with a key management system or holder of desired secret(s) 115 associated with a server or server side 105. The requestor 120 may request one or more secrets or protected data from the key management system 115, e.g., to access certain protected data, perform one or more protected processes, etc. The requestor 120 and the Key Management System (KMS) 115 may utilize a public key private key security system or other key protocols known in the art to exchange desired secrets/data.

At operation 125, the supplicant 120 may first authenticate to the KMS 115 and establish a secure communication channel via any known technique in the art. Operation 125 may include utilizing a public key system or the like. Next, at operation 130, using the secure channel established via operation 125, requestor 120 may send a request for one or more secrets/protected data to KMS 115. After verifying the request, KMS 115 may transmit the secret or request data back to requester 120 over a secure communication channel at operation 135. As standard in the art, the secret/request data may be transmitted over the secure channel at 135 without any additional protection over the secure channel. As a result, the secret/data transmitted at operation 135 may be exposed to the requesting device 120.

FIG. 1B illustrates an example system and process 100B for exchanging one or more secrets or protected data between a requestor 120 and a KSM 115 on behalf of a trusted execution environment (TrEE) 140, an enclave, or other item for indicating an isolated execution environment associated with the requestor 120. TrEE 140 may be isolated from requester 120 such that code and/or data contained in TrEE 140 may not be accessed (e.g., readable and/or writable) by requester 120.

FIG. 2 illustrates an example 200 of a trusted execution environment, in which a computing device 205 may include logic 210 (e.g., code) and state information 220, such as data. The state information 220 may be stored or located in the isolation region 215, such as may be secured for unauthorized access. In some cases, the data 220 within the isolation region 215 cannot be directly read or written by any entity other than the logic 210 associated with the isolation region 215. The quarantine logic 210 decides what type of access it will allow to what type or portion of data 220. In one example, logic 210 may allow the value associated with data 220 to be incremented and read, but may not otherwise modify data 220. In another example, logic 210 may allow encryption operations using the key without allowing access to the value of the key itself. In the example shown, the logic or code 210 may be in a general or accessible region of the CPM 205; however, it should be understood that in some cases, logic 210 may also be located within the same or different isolation region as state information 220.

Returning to system 100b, a Targeting Protocol Header (TPH) 150 may be implemented at server side 105 to act as an intermediary between requester 120/TrEE 140 and KMS 115. A protocol header may refer to a software implementation of a protocol handler, generally oriented to systems that do not themselves specify a particular protocol. Targeting may refer to encryption targeting of an execution environment. In summary, the term may indicate software and/or hardware implementing a protocol for retrieving secrets targeting responses at TrEE. In some aspects, targeting protocol header 150 may be implemented as a virtual or cloud resource, e.g., it may run on different hardware, software, and/or separate from KMS 115. In some aspects, an entity, such as a data center, may host and/or provide targeting protocol header 150 as a service. Targeting protocol header 150 may perform two main functions: 1) Communicate with KMS 115/obtain secret or protected data from external entities, and 2) target a response to TrEE 140 of requester 120. As a result of the use of targeting protocol header 150, requester 120 need not authenticate directly to KMS 115. KMS115 generates its secret to targeting protocol header 150 instead of to requester 120. The function of targeting protocol header 150 is to target the response to TrEE 140 of requester 120, thereby ensuring that requester 120 cannot obtain the plaintext of the secret/protected data. Instead, targeting protocol header 150 may instead authenticate itself to KMS115 on behalf of requester 120, but may proceed with or without the identity of requester 120. In some cases, targeting protocol header 150 may need to be sure that the secret of TrEE 140 that it will return to requester 120 will be in a "secure hand". In this case, the requestor 120 may provide provable information about the state of the TrEE 140 to the targeting protocol header 150, which may include provable key material associated with the TrEE 140, the response of which may be encrypted.

In some cases, multiple different processes, such as provided by one or more trusted applications, may operate concurrently within a secure kernel, where each trusted application and secure kernel are considered to be a TrEE140 (e.g., this is an example of a nested TrEE). In this case, each different trusted application may be associated with a session ID, a trusted application type, and/or other ID, which may be used to identify the respective trusted application within the secure kernel (e.g., both represented as TrEE 140). The response from targeting protocol header 150 may be narrowly targeted to a particular trusted application within TrEE140 identified in the request, as will be described in more detail below.

In the case of TrEE140 targeting, there is no inherent need for a secure channel between the requester 120 and the targeting protocol header 150, as the requester 120 itself is not trusted by the response. However, it should be appreciated that a secure channel between the requester 120 and the targeting protocol header 150 may be added via the authentication operation 160, for example, to protect access to the request itself (the secret intended by the requester), which may result in poor information disclosure. After authentication at operation 160 or in lieu of authentication at operation 160, at operation 155, on behalf of TrEE140, requestor 120 may send a request for one or more secrets or secret or protected data to targeting protocol header 150, e.g., to deliver to the TrEE. In some aspects, the request may be associated with TrEE140 or identify TrEE 140. Targeting protocol header 150 may determine whether TrEE140 is trustworthy. In one aspect, authentication of the requester 120 may rely on one type of clean room supply (clean room provisioning). In another aspect, authentication may rely on attestation.

Clean room provisioning may be used when the requestor 120 device is, for example, entirely new and reasonably assumed to be free of malware. An example process for delivering protected data to TrEE associated with a requester using a clean room supply will be described in more detail below with reference to fig. 3. An example process for delivering protected data to TrEE associated with a requester using attestation (e.g., attestation service) will be described in more detail below with reference to fig. 4.

In either case, once the TPH 150 has authenticated the requestor 120, and/or established the trust of the TrEE 140, the TPH 150 may authenticate to the KMS 115 and establish a secure communication channel with the KMS 115 at operation 165. In some aspects, KMS 115 may include or be associated with any entity that holds one or more secrets or protected data (such as permissions, passwords, etc.). Upon establishing a secure communication channel with KMS 115, TPH 150 may send a request for protected data at operation 170. KMS 115 may return the requested secret at operation 175. At operation 180, the TPH 150 may target the secret(s) or protected data at the TrEE 140 and send one or more secrets.

In some aspects, delivering protected data to TrEE 140 at operation 180 may utilize at least one of the following data structures: an encrypted identity key, which may be built around TrEE identity or attestation process or attestation log; or in a nested TrEE example (e.g., a trusted application running on top of a secure kernel), a signed identity key, which may also be built around the attestation process, as will be described in more detail below.

Fig. 1C illustrates another example system and process 100C for securely exchanging one or more secrets or protected data between a requestor 120 and KMS 115 on behalf of a trusted execution environment (TrEE) 140. System 100c may be a specific example of system 100b as described above. In the system 100c, the targeting protocol header 150 may be a host monitoring service (HGS) 150a. In the system 100c, the HGS 150a may receive the key protector 190, for example, from the cloud host 185 or other entity that may instantiate or otherwise control the TrEE 140. In system 100c, requestor 120 may be associated with a virtual machine provided by cloud host 185, for example. KP 190 may include one or more aspects of the key protector described in related U.S. patent application #14/481,399 entitled "Secure Transport of Encrypted Virtual Machines with Continuous Owner Access" filed on 9.2014. KP 190 may contain one or more secrets available to TrEE 140, such as a transfer key. KP 190 may essentially wrap the transfer key so that only a group of guardians (guard's) are able to access it, which guardians are authorized to access the transfer key. The KP 190 may be encrypted such that, in order to read the content of the KP 190 and retrieve the transfer key, after authenticating with the KMS 115 and establishing a secure communication channel with the KMS 115 at operation 165, the HGS 150a may request a decryption key from the KMS 115 at operation 170 a. In response, KMS 115 may send the decryption key to the HGS at operation 175 a. The HGS 150a may then decrypt the KP 190 using the decryption key, and retrieve one or more secrets (e.g., transfer key) to send to the TrEE 140. The HGS 150a may then send the secret or transfer key to the TrEE at operation 180 via one or more addressing techniques, which will be described in more detail below. In some aspects, trEE 140 may be addressed based on data from KP 190.

It should be appreciated that in some cases, HGS 150a and KMS 115 may be one entity, such that no communication channel needs to be established between them, and no authentication is required.

In the system 100c, authentication between the supplicant 120 and the HGS 150a is not required. As long as the cloud or fabric host 180 is healthy, it is not important which fabric host communicates with the HGS 150a as long as it is one of the servers in the fabric (this can be verified via attestation).

Fig. 3 illustrates an example process 300 for delivering protected data to a TrEE of a requestor, where the requestor is assumed to be trusted (e.g., free of malware). As used herein, dashed lines in the blocks or operations in any figure indicate that the operation is optional, so that it may be excluded. Process 300 may utilize an encryption key associated with TrEE, such as a public key of a public-private key pair (e.g., an asymmetric key pair) generated by the TrEE or a security kernel of a requester that initiates the TrEE. In other cases, the encryption key may be symmetric. As used herein, a security kernel may refer to any portion of a computing device associated with a higher level of security, as is known in the art.

In this case, trEE 140 may be initiated or launched at operation 302, and one or more private keys (e.g., private encryption keys) and corresponding public keys may be generated inside TrEE 140 at operation 304. The corresponding public key may then be registered with the TPH 150 and associated with the identity of the requestor and/or requesting device at operation 306. In some cases, the public key of TrEE 140 need only be registered once, so that process 300 may begin at operation 308 after the public key registration. The requestor 120 may then authenticate to the TPH 150 at operation 308 via any known authentication technique. The TPH 150 may then look up a public key for delivering the response to the TrEE 140, e.g., a registered public key based on the TrEE 140, which may be associated with the identity of the requestor 120. This process may be referred to as a "clean room" supply because it can only be safely completed when requester 120 is in a known good or trusted state. In this example, certificate-based authentication, in which the requester 120 sends a TrEE Health Certificate (THC) to the TPH 150, is not required, as the requester 120 is trustworthy. In the absence of a ubiquitous attestation service, this is a viable option to verify that the TPH 150 is targeting the correct TrEE 140.

Next, at operation 312, the TPH 150 may obtain protected data for delivery to the TrEE140, e.g., from the KMS 115, as described above. Using the TrEE public key accessed via operation 310, then at operation 314, the TPH 150 may construct a message for transmission to the TrEE140, including the acquired protected data. The TPH 150 may send the message to the requestor 120 at operation 316.

Upon receipt of the message, the requestor 120 may forward it to the TrEE140 at operation 318. Because the requester 120 cannot access the TrEE's private key, the requester 120 cannot decrypt the message to access the protected data. At operation 320, trEE140 may decrypt the message and access the protected data using its private key.

Fig. 4A illustrates an example process 400 for delivering protected data to a TrEE of an untrusted requestor. Process 400 may utilize an encryption key associated with a TrEE, such as the public key of a public-key private key pair generated by the TrEE or the security kernel of the requestor that originated the TrEE, such as in the case of a nested TrEE (which may be referred to herein as a trusted application). Process 400 may additionally or alternatively utilize a signing key of a secure kernel, which may be considered an external TrEE associated with a TrEE, where trusted applications are nested or run on top of the secure kernel, the TrEE may be used to verify a public key of a key pair generated by the TrEE, as described in more detail below.

Following initialization of TrEE at operation 402, according to process 400, requestor 120 may request a certification report or claim from a certification service at operation 406. FIG. 4B illustrates an example process for obtaining a certification statement or report from a certification service 424. In the example of fig. 4B, at operation 426, the requestor 120 may create a attestation log (TCG log) containing the public key (idk_e) (trusted application) of TrEE 140 (secure kernel) or the signing key (idk_s) of TrEE at boot time. The requestor 120 may then present the TCG log to the attestation service 424 at operation 428. In some cases, the TPH 150 may indicate or the requestor 120 may select a attestation service that the TPH 150 trusts. At operation 430, the attestation service 424 may examine the TCG log and issue a TrEE Health Certificate (THC) based on the encryption key (idk_e) and/or the signing key (idk_s) of the TrEE 140 (security kernel). The attestation service 242 may then send back THC (also referred to herein as attestation statement) to the requestor 120 at operation 432.

After obtaining the attestation statement at operation 406, the requestor 120 may send the attestation statement and a request for protected data to the TPH 150 on behalf of the TrEE 140 at operation 408. The THC or attestation statement may contain the subject name of the supplicant 120 (to create a binding between the supplicant identity and the credentials established during authentication), and a key (e.g., an encryption key or a signing key) that the responder (TPH 150) uses to make a response.

In some aspects, a tamper-resistant identity, such as an Encryption Key (EK) of a Trusted Platform Module (TPM), is associated with the requestor 120. The attestation of requestor 120 may be performed using a TPM EK, as is known in the art.

In some aspects, tree may communicate whether the key is an encryption key or a signing key to TPH150 via requester 120, whether out-of-band or through an Issue Policy (IP) Object Identifier (OID) that may be part of THC. As described above, the choice between which key to use may affect the choice of the mechanism used to construct the response. Importantly, the TPH150 does not require proof of possession of the private key supporting the certificate, simply because if an incorrect certificate is given, the requestor 120 will not understand the response because it cannot access the corresponding private key.

Fig. 5A and 5B illustrate an example process 500 for delivering protected data to a nested TrEE of untrusted requesters. In some aspects, two or more TrEE may be nested such that one TrEE is contained in another TrEE. As described herein, a trusted application is a nested TrEE, which is contained in an external TrEE. In one example, the external TrEE may include a secure kernel of a trusted portion of the operating system, such as a particular memory partition associated with a virtual trust level, as described in more detail below with reference to fig. 6. Process 500 may be used when, for example, only the encryption key of the external TrEE (which may be the secure kernel of the machine that instantiates the trusted application in some cases) is available.

Process 500 may begin at operation 502, where requestor 120 launches a trusted application with a "session identifier" decided by requestor 120, which may include any type of identifier, such as one that relates to or identifies the content or data that the trusted application is to operate with, the user of the trusted application, etc. (e.g., "streaming content application trusted application '" for playing' a particular title "). In one example, the session ID may be a 32 byte value. The value may be reserved, read-only for the lifetime of the trusted application, and available to the security kernel when receiving the target message to the trusted application. This value may be lost (not specified at process start-up), in which case the session ID may be assumed to be zero.

Next, at operation 504, the requester 120 may authenticate to the TPH 150 (optional as described above, but only in very limited cases, such as where there is indeed no difference between requesters). For example, one example of a binding between a desired TrEE (e.g., a key of a TrEE) and the identity of a requester is that playback of a content item such as a movie is limited by a license or subscriber authentication (e.g., netFlix users want to acquire a license to play a movie, but NetFlix wants to ensure that it is the user (within their TrEE) that is receiving a license to a movie).

At operation 506, the requestor 120 may obtain a attestation statement from an attestation service trusted by the TPH 150, such as in accordance with process 406 described above with reference to fig. 4B. Next, the requestor 120 may present a certification statement to the TPH 150 at operation 508. It should be appreciated that in the clean room supply example described above as may be applicable here, no certification is necessary.

Upon receipt of the attestation statement, the TPH 150 may verify the attestation statement (or, in the case of the clean room provisioning example above, look up the requester's key based on its identity) at operation 510. At this point in process 500, the requestor 120 knows which key to use to address the external TrEE. In some aspects, an indication that the key obtained from the attestation statement or request is an encryption key of an external TrEE or security kernel (rather than an internal trusted party) may be included in the request or attestation statement or otherwise communicated out-of-band to the TPH 150, set to a default procedure, or the like. Next, at operation 511, the TPH 150 may obtain the protected data indicated in the request, e.g., from the KMS 115 or from any other entity holding the protected data, such as one or more services holding a license, password, license, and/or other information.

From operation 512, the TPH 150 may determine which trusted application type to target, e.g., on a request basis or on the TPH 150 itself (e.g., each TPH 150 may be specifically designed for a particular purpose or application, such as NetFlix). In an example utilizing KP, such as described above with reference to 1C, a trusted application type may be encoded in KP. In some other examples, the trusted application type may be set by default or hard-coded, such as in implementations utilizing the HGS150 a. In the HGS example, HGS150a may always target a Virtual Mode Security Process (VMSP) trusted application, whose type may be hard-coded (since KP may not contain this information).

Upon determining the trusted application type to be targeted, the TPH 150 may construct a message including the protected data to be sent to TrEE at operation 514. A more detailed example of operation 514 is depicted in fig. 5B.

In some aspects, operation 514 may further comprise operation 536 wherein the TPH 150 generates two random symmetric keys: a transfer key TX and a wrapping (wrapping) key TW. Next, at operation 538, the TPH 150 may encrypt TX using a public key in the THC that is part of the attestation statement (e.g., assuming that the THC is based on an encryption key, rather than a signing key). In some aspects, operation 538 may include encrypting the TX with the IDK of the host using RSA encryption and OAEP padding. In some aspects, the TPH 150 may verify the session ID of the trusted application at operation 540, for example, to verify whether the trusted application is authorized or has the correct permissions to access the protected data (e.g., to pay for online services or content items). In some cases, the session ID may include a trusted application type; however, in other cases, the trusted application type may be encoded in KP or even hard-coded. Then, at operations 542 and 544, the TPH 150 may encrypt the TW using the TX, and may connect the trusted application type and session ID of the trusted application and use as an "authentication tag". Note that the use of authentication tags is a artifact of the AES-GCM protocol; other encryption protocols may use different schemes with the same effect. The idea behind authentication tags is to bind the TW together with trusted application types and session IDs so that they cannot be decoupled in transmission by an attacker. There are a variety of other ways in which this encryption may be accomplished; AES-GCM is described herein as providing this functionality itself and is therefore advantageous.

The TPH 150 may then send the encrypted authentication encryption of TX and TW to the supplicant 120 at operation 546. As shown in fig. 5A, after receiving a message 516 that may be generated via the operations of fig. 5B and/or that may include protected data encrypted in a similar manner as TW, the requestor 120 may forward the message to a trusted application at operation 518. Since the trusted application cannot decrypt the message (which is attempting to reach TW), the trusted application may transmit the message to the secure kernel at operation 520. Alternatively, the requestor 120 may bypass the trusted application to send a response to the secure kernel, and the secure kernel alerts the trusted application with new information when decrypting the TW.

Next, at operation 522, the secure kernel may decrypt TX using its private encryption key, then decrypt TW using TX, and use the authentication tag to ensure that the correct trusted application type request with the correct session ID decrypts the message. If the authentication tag is authenticated, the security kernel may return the TW to the trusted application at operation 524. The trusted application may then use the received TW to decrypt any other content that the TW is encrypting, such as protected data, which may be of any size.

In some aspects, the security kernel may implement one or more processes, such as processes defined by one or more APIs, for receiving, decrypting, and transmitting targeted messages to the correct trusted application. The API may receive an encrypted message targeting a particular trusted application and decrypt TX using the private portion of the IDK (secure kernel identity encryption key). The API may use the trusted application type and the connection that invokes the session ID of the trusted application as a token to construct its own authentication tag (the provided authentication tag cannot be used for obvious security reasons). The trusted application type and session ID may then be obtained. If the authentication is successful, the API may decrypt the TW using the TX. If the decryption is successful, the API may return the TW to the trusted application.

In one example, the received message may include the following information: version number (e.g., 0); a transport key encryption protocol ID (e.g., RSA 2048); transmit key encryption pad ID (e.g., OAEP); wrapping a key encryption protocol ID (e.g., AES-GCM); transmitting the length of the key ciphertext; length of wrapping key authentication ticket (ignore); packaging the length of the key ciphertext; and transmitting the key ciphertext, the wrapping key authentication tag (ignore), and the wrapping key ciphertext. It should be understood that this is but one of many ways in which messages may be constructed.

In some aspects, one or more of the above-described systems or processes 100, 300, 400, or 500 may be implemented in a resource or virtual machine that implements a Virtual Security Mode (VSM). VSM and related concepts in the context of virtual machines are described in U.S. patent application #14/186,415 entitled "Virtual Secure Mode for Virtual Machines" filed on date 21, 2, 2014. FIG. 6 illustrates a system or host operating system 600 that includes a VSM computing environment that is divided into different virtual trust levels VTL0610 and VTL1 615. System 600 may be a more specific implementation of one or more aspects of systems 100a, 100b, or 100c, such as cloud host 180, which includes a computing environment operating in a VSM. VTL0610 may include user mode 620 and normal kernel mode 630, and VTL1 615 may include user mode 625 and secure kernel mode 635. The different VTLs may be provided by a hypervisor, e.g., a hypervisor running on top of physical computing components or virtual computing resources (e.g., one or more virtual machines), that interacts and defines VTL0610 and VTL1 615 via restrictions on memory access by certain processes, etc. In the illustrated example, VTL1 615 may be more secure than VTL0610, such that higher access is required to read and/or write data or code associated with VTL 1. VTL0610 may correspond to requestor 120 and VTL1 615 may correspond to TrEE 140. The system 600 is described below as utilizing KP 700. However, it should be understood that this is given by way of example only; the system 600 may utilize the attestation/authentication scheme described above without using KP to achieve a similar effect.

As described with reference to system 600, client application (app) 650/VTL0 610 of host 600 may correspond to requestor 120, while VTL1615, and more particularly secure kernel 635 of VTL1615, may correspond to TrEE 140. In some aspects, the trusted application 640 may correspond to the nested trusted application described with reference to process 500. In some aspects, the system 600 may implement the process 500 described above. In other cases, the system 600 may implement the processes 800 and/or 900 described below with reference to fig. 8 and 9, with the primary difference between the processes 500 and 800 being the use of KP to initialize trusted applications and the use of a particular implementation of the HGS 150a in place of the more general TPH 150.

As shown, one or more TrEE or trusted applications 640 may reside in a user mode 625 of the VTL 1615. In some aspects, one or more trusted applications 640 may be accessed or associated with a Virtual Machine Security Process (VMSP) 645. Client operations, applications, programs, etc. 650 (clients) may operate in user mode 620 of VTL0 610. The server 655 residing in the user mode 625 of the VTL1615 may communicate with the client 650 via the RPC 660. As shown. The client 650 may request that the trusted application 640 be initiated to perform one or more security operations via one or more RPCs 660, e.g., utilizing VMSP 645. In other aspects, the server 655 may initiate the trusted application 640 without receiving an explicit request from the client 650. In either case, the server 655 may initiate the trusted application(s) 640, wherein the particular trusted application type identifies parameters of the trusted application, and the session ID identifies a particular instance of the trusted application 640. In some aspects, the trusted application type may be initialized via a data structure that includes KP 405, such as described above with reference to system 100C of fig. 1C. An example data structure including KPs such as KP 700 is shown in fig. 7.

The data structure 700 may include a Key Protector (KP) 705, where KP 705 is a cryptographic wrapper of an encryption key (here, a transmission key TK), as described in U.S. patent application #14/481,399 filed on 9.9.2014, entitled "Secure Transport of Encrypted Virtual Machines with Continuous Owner Access". KP 705 ensures that only authorized entities are provided access to TK 710 and/or other protected data. TK 710, which is the key to be delivered to TrEE 140, may be wrapped with KP 705, or in some cases with a key or TW. TK 710 may be considered a high value secret. In some cases, TK 710 may be decrypted at KMS 115.

The data structure 700 may also include Virtual Machine Data (VMD) 730, and the VMD 730 may include data for initializing trusted applications. VMD 730 may be encrypted using an appropriate encryption technique, such as BitLocker available from microsoft corporation of Redmond dash. Full Volume Encryption Key (FVEK) 725 (which may be used to decrypt VMD 730 and may be used by a virtual trusted platform module (V _TPM ) Protection) shapeThe state (725) is encrypted and stored as part of the metadata with KP 705. In some aspects, the FVEK 725 may be encrypted by a Volume Master Key (VMK) 720. V (V) _TPM State 725 is itself encrypted using the key wrapped by KP 705. In some aspects, V _TPM State 725 may be encrypted by TK 710 (high value secret) and "seal" the data to the PCR value (e.g., PCR 7) so that if the PCR value is in the expected state, the TPM will allow access (e.g., decryption) to the keying material. In this case, the TPM protector is a data structure that is fed into the TPM to unseal certain secrets if one or more PCRs are in an expected state. In other cases, a non-TPM protector may also be used.

Volume Master Key (VMK) 720 may be defined by V _TPM State 725 decapsulates. V (V) _TPM State 725 may be encrypted by TK 710 within KP 705. In some cases, VMK 720 may be Bitlocker Volume Master Key and may be marked as a low value secret.

Each field or block of KP 700 may also be described in terms of its encrypted content, such as an encryption (key, data) shorthand:

KP is associated with a VM, whereas a trusted application actually never sees it.

KP goes to KMS, which decrypts it and returns TK to trusted application (via

By the targeting mechanism described above). TK decrypts the vTPM, which unseals the VMK to

FVEK is produced.

In one example, KP 405, V _TPM State 415, VMK 420, and VMD 430 may be data stored on disk. V (V) _TPM State 415 may be at creation of V _TPM Time initialized, and can be guaranteed to be unique. For runtime uniqueness, e.g. runtime uniqueness of generated secrets or protected data, V _TPM Depending on the security of the RNG to which the security kernel provides. At trusted applicationV with TK 710 using decryption _TPM After decryption of state 415, the remaining operations to access VMD 730 may be the same or similar to the operations performed between the physical machine and the physical TPM. These operations may include V _TPM Performing a measurement of VSM using V _TPM The measurement is taken to unseal the VMK (resulting in the FVEK 725 being provided to the operating system loader) and the operating system uses the FVEK 725 to decrypt the VMD 730.

To launch a trusted application, client 650 may request and/or receive data structure 700. The client 650 may send the KP 705 or the entire data structure 700 to the TPH 150 (or to the HGS 150a in some implementations), and the TPH 150 may communicate with the KMS 115 to decrypt the TK 710. The TPH may then utilize the idk_pub 665 to target TK 710 at a security kernel 635 associated with the trusted application 640, for example, via process 800 described below. The security kernel 635 may obtain idk_pub and idk_pri at issue time. The security kernel 635 may decrypt and return TK 710 to server 655 using its private key 675 (e.g., idk_pri). The server 655 may then deliver the TK 710 to the trusted application 640. In some cases, the security kernel 635 may return the TK 710 directly to the trusted application 640. In some aspects, the protected data may be transmitted with the TK 710 to the trusted application 640 and encrypted by the TK 710. In this way, trusted application 640 may use TK 710 to decrypt protected data.

Fig. 8 illustrates an example process 800 for targeting a transfer key and/or protected data encrypted by the transfer key to a TrEE or a particular trusted application using an identity key of the TrEE or the trusted application. More specifically, process 800 illustrates a manner in which a trusted application is targeted via its secure kernel's encryption key.

The cloud architecture host or host OS (e.g., host OS 600) performs a series of steps to receive the transfer key. The cloud architecture host may first obtain a TrEE Health Certificate (THC) at operation 602, e.g., built around an encrypted identity key (idk_e) of a security kernel associated with the TrEE or trusted application, such as according to the process described above with reference to fig. 4B. In one aspect, operation 602 may include creating, by the host at boot time, a attestation log (TCG log) containing a public version of idk_e, a private portion of which resides in a VSM Security Kernel (SK) associated with the trusted application. The attestation log may be presented to an Attestation Service (AS). The AS may examine the attestation log and issue THC to the host that is built around idk_e (e.g., the public part of the asymmetric key). In some aspects, similar to idk_e, a "signature identity key" (idk_s) may also be created and idk_s may have a separate THC built around it, as will be described in more detail below with reference to fig. 9. The idk_e or idk_s may be used to construct a solution to the key delivery problem, as described below.

When a new masked VM needs to be loaded, the host retrieves the KP of the VM at operation 804 and initiates a dialogue with the TPH (e.g., TPH 150) with the goal of injecting TK encrypted by KP into the VMSP trusted application.

To exchange KPs of TK, at operation 806, the host may present KPs and "trusted application identities" along with THCs to a TPH, such as TPH 150. At operation 808, the cloud infrastructure host may also launch a trusted application or TrEE having a "session ID" derived from KP (KPSID). In some aspects, the received KP will form the basis of the session ID value by creating a SHA-2 hash thereon or utilizing other one-way functions. The TPH may examine the THC at operation 822 and communicate with a KMS or other entity in possession, such as KMS 115, or other entity having access to the protected data and/or decryption keys of the KP to decrypt the KP to access the TK at operation 824. At operation 826, the TPH may use the special encryption structure to calculate the KPSID to target the trusted application, e.g., as described above with reference to process 500.

The requester or client 650 can receive the response from the TPH and forward it to the trusted application with the given KPSID. At operation 810, the trusted application or server may require the VSM security kernel to decrypt the response and return it to the TK. The security kernel examines the response, verifies at operation 812 whether it targets the trusted application type and the session ID of the trusted application, and if there is a match, returns only the key at operation 818. Thus, if the TPH response ends in the wrong hand, it is not cryptographically possible to understand. Upon receipt of the key, the host may decrypt the key and provide it to the TrEE at operation 820, at which point process 800 may end.

Fig. 9 illustrates another example process 900 for targeting a transfer key and/or protected data encrypted by the transfer key to a trusted application using a signing key of a secure kernel. More specifically, process 900 illustrates a manner in which a trusted application is targeted by its encryption key authenticated by the secure kernel's signing key.

Process 800 illustrates how responses are indirectly targeted at trusted applications through an identity encryption key shared between all trusted applications. However, if TrEE has a provable identity signing key, another method may be used. Here, each trusted application may generate its own encryption key pair and use idk_s to cause the secure kernel to verify the public key portion of the pair. Note that such verification must also cryptographically bind the key to the trusted application type and the session ID of the trusted application:

key_authentication=σidk_s (trusted application_encryption_key_pub, trusted application_type, session_id)

Where σidk_s represents concatenation of its inputs () followed by the use of a signature given that is not on these inputs.

In this case, the requestor presents the key of the trusted application and THC and key attestation to the TPH, and the TPH responds by encrypting the transfer key to the encryption key of the trusted application, unlike process 800 at operations 822 and 824.

In some aspects, a "security version number" (SVN) may also be used or indicated in key authentication to prevent other types of attacks to ensure TrEE is not an older and potentially vulnerable version. In some cases, when the secure kernel is certified but the internal trusted application is not certified (e.g., after the certification has been completed, the trusted application is loaded on demand), the SVN including the trusted application may instruct the TPH 150 to refuse to target older vulnerable trusted applications even though THC is not problematic.

One difference between the two methods of processes 800 and 900 is who enforces the binding between the trusted application or TrEE ID, session ID, and transfer key: in process 800, it is a secure kernel and in process 900, it is a TPH 150. Another major difference is how the response is structured in an encrypted manner. In the previous case it was the security kernel that in turn decided which trusted application was allowed to see it, in which case the response was directly targeted to the trusted application, where the key of the trusted application was authenticated by the key of the security kernel.

In some aspects, the techniques described above may be implemented to provide complete credential isolation for a container. The basic problem is the same, so the container can request credentials from its host. The host may then request credentials from some KMS on behalf of the container. If the requested credential is returned to the host unencrypted (e.g., the credential arrives on demand and is not part of the container image), then a "delayed credential binding" may result. This binding is valuable but not equal to credential isolation, so if the host is compromised, the credential is disclosed.

In one embodiment, the disclosed embodiments may be implemented as a computing system comprising:

a processor; and

a memory communicatively coupled to the processor, the memory storing instructions that, when executed by the processor, cause the computing system to:

receiving a request for protected data, a attestation statement of a secure kernel, and a key authentication statement from a requestor associated with a nested TrEE, wherein the nested TrEE comprises a trusted application running on top of the secure kernel, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

retrieving the protected data;

encrypting the protected data with the trusted application public encryption key; and

sending the encrypted protected data to the requester.

In one embodiment, the key authentication assertion is generated by the secure kernel using a signing key.

In one embodiment, the signing key proves the trusted application public encryption key of a public key private key pair generated by the trusted application.

In one embodiment, the trusted application ID includes a trusted application type or the trusted application type and a session ID.

In one embodiment, the key authentication statement is generated by the secure kernel using a signing key and binds the trusted application public key, the trusted application type, and the session ID.

In one embodiment, the instructions, when executed by the processor, cause the computing system to perform operations comprising:

comparing the trusted application ID to a list of authorized trusted application IDs; and

the protected data is encrypted with the trusted application public encryption key only when the trusted application ID is associated with the list of authorized trusted application IDs.

In one embodiment, a method for delivering protected data to a nested trusted execution environment (TrEE) comprising a trusted application running on top of an external TrEE, wherein both the trusted application and the external TrEE are associated with an untrusted requestor, the method comprising:

receiving, by a targeting protocol header, a request for protected data from a requestor associated with the nested TrEE, a attestation statement of the external TrEE, and a key authentication statement, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

Retrieving the protected data by the targeting protocol header;

sending the encrypted protected data to the requester.

In one embodiment, the key authentication assertion is generated by the external TrEE using a signing key.

In one embodiment, the key authentication statement is generated by the external TrEE using a signing key and binds the trusted application public key, the trusted application type and the session ID.

In one embodiment, the method further comprises:

comparing, by the targeting protocol header, the trusted application ID to a list of authorized trusted application IDs; and

the protected data is encrypted by the targeting protocol header with the trusted application public encryption key only when the trusted application ID is associated with the list of authorized trusted application IDs.

In one embodiment, the method further comprises:

sending, by the requestor, the encrypted protected data to the trusted application; and

decrypting, by the trusted application, the encrypted protected data using a trusted application private encryption key corresponding to the trusted application public encryption key.

In one embodiment, the protected data includes a wrapping key.

In one embodiment, a computer-readable storage medium may be implemented to include instructions for delivering protected data to a nested trusted execution environment (TrEE) that includes a trusted application running on top of a secure kernel, the medium including instructions that when executed on a computer system cause the computer system to at least:

receiving a request for protected data, a attestation statement of the secure kernel, and a key authentication statement from a requestor associated with the nested TrEE, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

retrieving the protected data;

encrypting the protected data using the trusted application public encryption key; and

Sending the encrypted protected data to the requester.

In one embodiment, the key authentication statement is generated by the secure kernel using a signing key.

In one embodiment, the signing key proves a trusted application public encryption key of a public-key private key pair generated by the trusted application.

18. The computer-readable storage medium of claim 15, wherein the trusted application ID comprises a trusted application type or the trusted application type and a session ID.

In one embodiment, the instructions further comprise instructions that, when executed on the computing system, cause the computing system to at least:

As described below, the techniques described above may be implemented on one or more computing devices or environments. Fig. 10 depicts an exemplary general purpose computing environment in which some of the techniques described herein may be implemented, e.g., which may contain one or more of requestor 120, trEE 140, TPH 150, host OS 600, AS 424, KMS 115. The computing system environment 1002 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the subject matter of the disclosure. Neither should the computing environment 1002 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example operating environment 1002. In some embodiments, the various depicted computing elements may include circuitry configured to instantiate certain aspects of the present disclosure. For example, the term circuitry used in this disclosure may include dedicated hardware components configured to perform the function(s) through firmware or switches. In other example embodiments, the term circuitry may include a general purpose processing unit, memory, or the like, configured by software instructions embodying logic operable to perform the function(s). In an example embodiment where the circuitry includes a combination of hardware and software, an implementer may write source code comprising logic and the source code can be compiled into machine readable code that can be processed by a general purpose processing unit. Since it will be appreciated by those skilled in the art that the prior art has evolved to the point where there is little difference between hardware, software, or a combination of hardware/software, selecting hardware and software to achieve a particular function is a design choice left to the practitioner. More specifically, those skilled in the art will appreciate that a software process can be converted into an equivalent hardware structure, and that the hardware structure itself can be converted into an equivalent software process. Thus, the choice of hardware implementation and software implementation is one of design choice and left to the implementer.

The computer 1002 (which may include any of a mobile device or smart phone, a tablet, a laptop, a collection of desktop or networked devices, cloud computing resources, etc.) typically includes a variety of computer-readable media. Computer readable media can be any available media that can be accessed by computer 1002 and includes both volatile and nonvolatile media, removable and non-removable media. The system memory 1022 includes computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM) 1023 and Random Access Memory (RAM) 1060. A basic input/output system 1024 (BIOS), containing the basic routines that help to transfer information between elements within computer 1002, such as during start-up, is typically stored in ROM 1023. The RAM 1060 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by the processing unit 1059. By way of example, and not limitation, FIG. 10 illustrates operating system 1025, application programs 1026, other program modules 1027 including TrEE targeting application 1065, and program data 1028.

The computer 1002 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only, FIG. 10 illustrates a hard disk drive 1038 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 1039 that reads from or writes to a removable, nonvolatile magnetic disk 1054, and an optical disk drive 1004 that reads from or writes to a removable, nonvolatile optical disk 1053 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the example operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 1038 is typically connected to the system bus 1021 through a non-removable memory interface such as interface 1034, and magnetic disk drive 1039 and optical disk drive 1004 are typically connected to the system bus 1021 by a removable memory interface, such as interface 1035 or 1036.

The drives and their associated computer storage media discussed above and illustrated in fig. 10, provide storage of computer readable instructions, data structures, program modules and other data for the computer 1002. In FIG. 10, for example, hard disk drive 1038 is illustrated as storing operating system 1058, application programs 1057, other program modules 1056, and program data 1055. Note that these components can either be the same as or different from operating system 1025, application programs 1026, other program modules 1027, and program data 1028. Operating system 1058, application programs 1057, other program modules 1056, and program data 1055 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 1002 through input devices such as a keyboard 1051 and pointing device 1052, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, retinal scanner, or the like. These and other input devices are often connected to the processing unit 1059 through a user input interface 1036 that is coupled to the system bus 1021, but may be connected by other interface and bus structures, such as a parallel port, game port or a Universal Serial Bus (USB). A monitor 1042 or other type of display device is also connected to the system bus 1021 via an interface, such as a video interface 1032. In addition to the display, computers may also include other peripheral output devices such as speakers 1044 and printer 1043, which may be connected through an output peripheral interface 1033.

The computer 1002 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 1046. The remote computer 1046 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 1002, although only a memory storage device 1047 has been illustrated in FIG. 10. The logical connections depicted in FIG. 10 include a Local Area Network (LAN) 1045 and a Wide Area Network (WAN) 1049, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, the Internet and cloud computing resources.

When used in a LAN networking environment, the computer 1002 is connected to the LAN 1045 through a network interface or adapter 1037. When used in a WAN networking environment, the computer 1002 typically includes a modem 1005 or other means for establishing communications over the WAN 1049, such as the Internet. The modem 1005, which may be internal or external, may be connected to the system bus 1021 via the user input interface 1036, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 1002, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, fig. 10 illustrates remote application programs 1048 as residing on memory device 1047. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

In some aspects, other programs 1027 may include a TrEE targeting component or application 1065, the TrEE targeting component or application 1065 including functionality as described above. In some cases, trEE targeting application 1065 may perform some or all of the operations of processes 300, 400, 500, 800, and/or 900.

Each of the processes, methods, and algorithms described in the preceding sections may be implemented in code modules executed by one or more computers or computer processors and automated, in whole or in part, by such code modules. These code modules may be stored on any type of non-transitory computer readable medium or computer storage device, such as a hard disk drive, solid state memory, optical disk, and the like. The processes and algorithms may be partially or wholly implemented in dedicated circuitry. The results of the disclosed processes and process steps may be stored permanently or otherwise in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage. The various features and processes described above may be used independently of each other or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. In addition, certain methods or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be performed in other suitable orders. For example, the described blocks or states may be performed in an order different than the specifically disclosed order, or multiple blocks or states may be combined in a single block or state. Example blocks or states may be performed in serial, parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged as compared to the disclosed example embodiments.

It should also be appreciated that various items are shown as being stored in or on memory while in use, and that these items or portions thereof may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments, some or all of the software modules and/or systems may execute in memory on another device and communicate with the illustrated computing system via inter-computer communication. Moreover, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including but not limited to one or more Application Specific Integrated Circuits (ASICs), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field Programmable Gate Arrays (FPGAs), complex Programmable Logic Devices (CPLDs), and the like. Some or all of the modules, systems, and data structures may also be stored on a computer-readable medium (e.g., as software instructions or structured data) to be read by an appropriate drive or via an appropriate connection, such as a hard disk, memory, network, or portable media item. For the purposes of this specification and claims, the phrase "computer-readable storage medium" and variations thereof, does not include waves, signals, and/or other transitory and/or intangible communication media. The systems, modules, and data structures may also be transmitted as a generated data signal (e.g., as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission media, including both wireless-based and wire/cable-based media, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). In other embodiments, such a computer program product may take other forms as well. Accordingly, the present disclosure may be practiced with other computer system configurations.

Conditional language such as "can," "right," "can," "such as," etc., as used herein is generally intended to convey that certain embodiments include while other embodiments do not include certain features, elements and/or steps unless explicitly stated otherwise or otherwise understood in the context of the use. Thus, such conditional language is not generally intended to imply that one or more embodiments require features, elements and/or steps in any way nor that one or more embodiments must include logic for deciding (whether or not author input or prompting) whether these features, elements and/or steps are included in or are to be performed in any particular embodiment. The terms "comprising," "including," "having," and the like are synonymous and are used inclusively in an open-ended fashion, and do not exclude other elements, features, acts, operations, etc. Furthermore, the term "or" is used in its inclusive sense (rather than in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list.

While certain example embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention disclosed herein. Thus, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, module or block is required or essential. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of certain inventions disclosed herein.

Claims

1. A computing system, comprising:

a processor; and

a memory communicatively coupled to the processor, the memory storing instructions that, when executed by the processor, cause the computing system to implement a targeting protocol header that acts as an intermediary between a requestor and a system storing secrets, the targeting protocol header configured to:

Receiving a request for protected data, a attestation statement of a secure kernel, and a key authentication statement from the requestor associated with a nested trusted execution environment TrEE, wherein the nested TrEE comprises a trusted application running on top of the secure kernel, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

retrieving the protected data from the system storing the secret in response to the request;

sending the encrypted protected data to the requester.

2. The computing system of claim 1, wherein the key authentication statement is generated by the secure kernel using a signing key.

3. The computing system of claim 2, wherein the signing key attests to the trusted application public encryption key of a public-key private key pair generated by the trusted application.

4. The computing system of claim 1, wherein the trusted application ID comprises a trusted application type or the trusted application type and a session ID.

5. The computing system of claim 4, wherein the key authentication statement is generated by the secure kernel using a signing key and binds the trusted application public key, the trusted application type, and the session ID.

6. The computing system of claim 1, wherein the instructions, when executed by the processor, cause the computing system to perform operations comprising:

7. A method for delivering protected data to a nested trusted execution environment TrEE, the nested trusted execution environment comprising a trusted application running on top of an external TrEE, wherein both the trusted application and the external TrEE are associated with an untrusted requestor, the method comprising:

receiving, by a targeting protocol header acting as an intermediary between a requestor and a system storing secrets, a request for protected data from the requestor associated with the nested TrEE, a certification statement for the external TrEE, and a key authentication statement, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

retrieving, by the targeting protocol header, the protected data from the system storing the secret in response to receiving the request;

sending the encrypted protected data to the requester.

8. The method of claim 7, wherein the key authentication assertion is generated by the external TrEE using a signing key.

9. The method of claim 8, wherein the signing key proves the trusted application public encryption key of a public-key private key pair generated by the trusted application.

10. The method of claim 7, wherein the trusted application ID comprises a trusted application type or the trusted application type and a session ID.

11. The method of claim 10, wherein the key authentication statement is generated by the external TrEE using a signing key and binds the trusted application public key, the trusted application type, and the session ID.

12. The method of claim 7, further comprising:

13. The method of claim 7, further comprising:

14. The method of claim 7, wherein the protected data comprises a wrapping key.

15. A computer-readable storage device comprising instructions for supporting a processor-based system to perform operations to deliver protected data to a nested trusted execution environment TrEE, the nested trusted execution environment comprising a trusted application running on top of a secure kernel, the operations comprising:

receiving, by a targeting protocol header acting as an intermediary between a requestor and a system storing secrets, a request for protected data from the requestor associated with the nested TrEE, a attestation statement of the secure kernel, and a key authentication statement, wherein the key authentication statement binds a trusted application public encryption key and a trusted application ID;

retrieving, by the targeting protocol header, the protected data from the system storing the secret in response to receipt of the request;

sending the encrypted protected data to the requester.

16. The computer-readable storage device of claim 15, wherein the key authentication statement is generated by the secure kernel using a signing key.

17. The computer-readable storage device of claim 16, wherein the signing key attests to the trusted application public encryption key of a public key private key pair generated by the trusted application.

18. The computer-readable storage device of claim 15, wherein the trusted application ID comprises a trusted application type or the trusted application type and a session ID.

19. The computer-readable storage device of claim 18, wherein the key authentication statement is generated by the secure kernel using a signing key and binds the trusted application public key, the trusted application type, and the session ID.

20. The computer-readable storage device of claim 15, wherein the operations further comprise:

the protected number is only paired with the trusted application public encryption key when the trusted application ID is associated with the list of authorized trusted application IDs.