ABSTRACT
Abstract
Methods, systems, and devices are described herein for delivering protected data to a nested trusted execution environment (TrEE), including a trustlet running on top of secure kernel, associated with a potentially untrusted requestor. In one aspect, a targeting protocol head, or other intermediary between a requestor and a key management system or other store of protected data, may receive a request for protected data from a potentially untrusted requestor, and an attestation statement of the secure kernel. The targeting protocol head may encrypt a transfer encryption key with a second encryption key derived from the attestation statement. The targeting protocol head may retrieve the protected data, and encrypt the protected data with the transfer encryption key and an authentication tag, which binds the requestor with the trustlet ID. The targeting protocol head may provide the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
Description
TECHNICAL FIELD
This disclosure relates generally to trusted and/or isolated execution environments in computing devices, and more specifically to secure delivery of one or more secrets or keys into a trusted execution environment.
BACKGROUND
A key management system (KMS) is a store of secrets. A secret typically has a public ID, a guarded value and a policy controlling who can obtain the value. In some cases, the secret may also have an expiration date and other metadata, and so on. In a typical use case, a requestor authenticates to a KMS, establishes a secure channel, requests the secret value by providing the secret ID, and expects the KMS to return to it the plaintext secret value. The value is protected from unauthorized eavesdropping and tampering by the secure channel between the requestor and the KMS.
A Trusted Execution Environment (TrEE), as used herein, can include any one of: a virtual secure mode (VSM) trustlet, an SGX application, an ARM TrustZone application or some other similar vehicle. There are some unique properties that TrEEs generally have in common. A TrEE will generally have a full crypto stack (in other words, one can assume a wide variety of cryptographic primitives across the entire spectrum, from secure random number generation to a full menu of hashing, encryption and signing libraries using secret keys). A TrEE will also generally have or be associated with few or limited I/O facilities, typically limited to a request driven architecture where requests are initiated by the untrusted âoutside worldâ. For example, a VSM trustlet may use unauthenticated Remote Procedure Calls (RPCs). TrEEs may also have access to key material or data that is unavailable outside of TrEE. This allows a TrEE, among other things, to store data using untrusted I/O and then read it back, assuring tamper-resistance and confidentiality of state. A TrEE will also generally have or be associated with attestable code, configuration and key material. In particular, attestable key material allows the TrEE to receive messages encrypted to it from 3rd parties and sign messages to 3rd parties as coming from the TrEE.
As with other applications, the use of a KMS with a TrEE may present security limitations. Accordingly, improvements can be made to improve security utilizing keys sourced from a KMS with or in TrEEs.
SUMMARY
Illustrative examples of the disclosure include, without limitation, methods, systems, and various devices. In one aspect, a method for delivering protected data to a nested trusted execution environment (TrEE), including a trustlet running on top of secure kernel, associated with a potentially untrusted requestor may be performed at least in part by a targeting protocol head, or other intermediary between a requestor and a key management system or other store of protected data. The targeting protocol head may receive a request for protected data from a potentially untrusted requestor, and an attestation statement of the secure kernel. The targeting protocol head may encrypt a transfer encryption key with a second encryption key derived from the attestation statement. The targeting protocol head may retrieve the protected data, and encrypt the protected data with the transfer encryption key and an authentication tag, which binds the requestor with the trustlet ID. The targeting protocol head may provide the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
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.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which:
FIGS. 1A, 1B, and 1C depict three examples of a system and process for exchanging keys between a requestor and a key management system.
FIG. 2 depicts an example diagram of a control program monitor implementing an isolated region or trusted execution environment (TrEE).
FIG. 3 depicts an example process for delivering protected data to a trusted TrEE utilizing an intermediary targeting protocol head.
FIGS. 4A and 4B depict another example process for delivering protected data to a TrEE utilizing an intermediary targeting protocol head.
FIGS. 5A and 5B depict an example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head.
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 used to deliver a transport key and/or protected data securely to a TrEE.
FIG. 8 depicts another example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head based around an encryption key of the outer TrEE.
FIG. 9 depicts another example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head based around an encryption key of the inner TrEE.
FIG. 10 depicts an example general purpose computing environment in which the techniques described herein may be embodied.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
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 into 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 a key requestor and a key management system or entity that possesses protected data. The intermediary may be referred to herein as a targeting protocol head. The key requestor may be associated with the secure execution environment or TrEE, which may include one or more of a VSM trustlet, an SGX application, an ARM TrustZone application, or some other similar vehicle. The TrEE may be isolated from the requestor. The requestor may request one or more secrets to deliver to the TrEE or a specific trustlet executing within the TrEE from the targeting protocol head. The targeting protocol head may, responsive to the request, communicate with a key management system or other entity that holds secrets to obtain one or more secrets for delivery to the TrEE. The targeting protocol head may specifically target the protected data at the TrEE so that the protected data is not accessible by the requestor or an attacker.
In some aspects, the implementation of a targeting protocol head may negate the need for a secure channel between the requestor and the key management system. The targeting protocol head, using the TrEE targeting techniques described herein, may also make it possible to send one or more secrets or data to a TrEE or a nested TrEE (e.g., a trustlet running on top of a secure kernel), in such a way that the secrets/data are not accessible by the requestor. In some cases, the requestor may be untrusted or potentially untrusted, such that an owner of the protected data may wish to keep the protected data inaccessible by the requestor, for any of a variety of reasons. In some cases, it may be difficult or cumbersome to establish that the requestor is trustworthy, or to ensure that the requestor remains trustworthy. Many of these concerns may be negated by assuming the requestor is not trusted, and isolating the TrEE from the requestor. This isolation may greatly improve security against different types of attacks and may provide other benefits and advantages, as will be described in greater detail below.
FIG. 1A illustrates an example system and process 100 a for exchanging keys between a requestor and a key management system. As illustrated, 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 some desired secret(s) 115 , associated with a server or server side 105 . The requestor 120 may request one or more secrets or pieces of protected data from the key management system 115 , for example, to access certain protected data, execute one or more protected processes, and the like. The requestor 120 and key management system (KMS) 115 may utilize a public key-private key security system, or other key protocol, as are known in the art, to exchange the desired secrets/data.
The requestor 120 may first authenticate with the KMS 115 and establish a secure communication channel, at operation 125 , via any of known techniques in the art. Operation 125 may include utilizing a public key system or the like. Next, utilizing the secure channel established via operation 125 , the requestor 120 may send a request for one or more secrets/protected data, at operation 130 , to the KMS 115 . Upon verifying the request, the KMS 115 may transmit the secret or requested data back to the requestor 120 , at operation 135 , over the secure communication channel. As is standard in the art, the secret/requested data may be transmitted at 135 over the secure channel, without any additional protection above the secure channel. As a result, the secret/data that is transmitted at operation 135 may be exposed to the requesting device 120 .
FIG. 1B illustrates an example system and process 100 b , for more securely exchanging one or more secrets or protected data between a requestor 120 and a KMS 115 , on behalf of a trusted execution environment (TrEE) 140 , enclave, or other term used to indicate an isolated execution environment associated with the requestor 120 . The TrEE 140 may be isolated from the requestor 120 , such that code and/or data contained in the TrEE 140 may not be accessible (e.g., readable and/or writeable to) by the requestor 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 an isolated region 215 , such as may be secure from un-authorized access. In some cases, data 220 inside the isolated region 215 cannot be directly read or written by any entity other than the logic 210 associated with the isolated region 215 . The isolated logic 210 decides what types of access it will allow to what types or portions of data 220 . In one example, logic 210 may allow incrementing and reading a value associated with data 220 , but not otherwise modifying data 220 . In another example, logic 210 may allow cryptographic operations using a key without ever granting access to the value of the key itself. In the example illustrated, the logic or code 210 may be in a general or accessible region of the CPM 205 ; however, it should be appreciated, that in some instances, the logic 210 may also be located within the same or a different isolated region as <figure-callout id="220" label="state information" filenames="US10897459-20210119-D00004.png" state="{{state}}"
TECHNICAL FIELD
This disclosure relates generally to trusted and/or isolated execution environments in computing devices, and more specifically to secure delivery of one or more secrets or keys into a trusted execution environment.
BACKGROUND
A key management system (KMS) is a store of secrets. A secret typically has a public ID, a guarded value and a policy controlling who can obtain the value. In some cases, the secret may also have an expiration date and other metadata, and so on. In a typical use case, a requestor authenticates to a KMS, establishes a secure channel, requests the secret value by providing the secret ID, and expects the KMS to return to it the plaintext secret value. The value is protected from unauthorized eavesdropping and tampering by the secure channel between the requestor and the KMS.
A Trusted Execution Environment (TrEE), as used herein, can include any one of: a virtual secure mode (VSM) trustlet, an SGX application, an ARM TrustZone application or some other similar vehicle. There are some unique properties that TrEEs generally have in common. A TrEE will generally have a full crypto stack (in other words, one can assume a wide variety of cryptographic primitives across the entire spectrum, from secure random number generation to a full menu of hashing, encryption and signing libraries using secret keys). A TrEE will also generally have or be associated with few or limited I/O facilities, typically limited to a request driven architecture where requests are initiated by the untrusted âoutside worldâ. For example, a VSM trustlet may use unauthenticated Remote Procedure Calls (RPCs). TrEEs may also have access to key material or data that is unavailable outside of TrEE. This allows a TrEE, among other things, to store data using untrusted I/O and then read it back, assuring tamper-resistance and confidentiality of state. A TrEE will also generally have or be associated with attestable code, configuration and key material. In particular, attestable key material allows the TrEE to receive messages encrypted to it from 3rd parties and sign messages to 3rd parties as coming from the TrEE.
As with other applications, the use of a KMS with a TrEE may present security limitations. Accordingly, improvements can be made to improve security utilizing keys sourced from a KMS with or in TrEEs.
SUMMARY
Illustrative examples of the disclosure include, without limitation, methods, systems, and various devices. In one aspect, a method for delivering protected data to a nested trusted execution environment (TrEE), including a trustlet running on top of secure kernel, associated with a potentially untrusted requestor may be performed at least in part by a targeting protocol head, or other intermediary between a requestor and a key management system or other store of protected data. The targeting protocol head may receive a request for protected data from a potentially untrusted requestor, and an attestation statement of the secure kernel. The targeting protocol head may encrypt a transfer encryption key with a second encryption key derived from the attestation statement. The targeting protocol head may retrieve the protected data, and encrypt the protected data with the transfer encryption key and an authentication tag, which binds the requestor with the trustlet ID. The targeting protocol head may provide the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
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.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which:
FIGS. 1A, 1B, and 1C depict three examples of a system and process for exchanging keys between a requestor and a key management system.
FIG. 2 depicts an example diagram of a control program monitor implementing an isolated region or trusted execution environment (TrEE).
FIG. 3 depicts an example process for delivering protected data to a trusted TrEE utilizing an intermediary targeting protocol head.
FIGS. 4A and 4B depict another example process for delivering protected data to a TrEE utilizing an intermediary targeting protocol head.
FIGS. 5A and 5B depict an example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head.
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 used to deliver a transport key and/or protected data securely to a TrEE.
FIG. 8 depicts another example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head based around an encryption key of the outer TrEE.
FIG. 9 depicts another example process for delivering protected data to a nested TrEE utilizing an intermediary targeting protocol head based around an encryption key of the inner TrEE.
FIG. 10 depicts an example general purpose computing environment in which the techniques described herein may be embodied.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
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 into 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 a key requestor and a key management system or entity that possesses protected data. The intermediary may be referred to herein as a targeting protocol head. The key requestor may be associated with the secure execution environment or TrEE, which may include one or more of a VSM trustlet, an SGX application, an ARM TrustZone application, or some other similar vehicle. The TrEE may be isolated from the requestor. The requestor may request one or more secrets to deliver to the TrEE or a specific trustlet executing within the TrEE from the targeting protocol head. The targeting protocol head may, responsive to the request, communicate with a key management system or other entity that holds secrets to obtain one or more secrets for delivery to the TrEE. The targeting protocol head may specifically target the protected data at the TrEE so that the protected data is not accessible by the requestor or an attacker.
In some aspects, the implementation of a targeting protocol head may negate the need for a secure channel between the requestor and the key management system. The targeting protocol head, using the TrEE targeting techniques described herein, may also make it possible to send one or more secrets or data to a TrEE or a nested TrEE (e.g., a trustlet running on top of a secure kernel), in such a way that the secrets/data are not accessible by the requestor. In some cases, the requestor may be untrusted or potentially untrusted, such that an owner of the protected data may wish to keep the protected data inaccessible by the requestor, for any of a variety of reasons. In some cases, it may be difficult or cumbersome to establish that the requestor is trustworthy, or to ensure that the requestor remains trustworthy. Many of these concerns may be negated by assuming the requestor is not trusted, and isolating the TrEE from the requestor. This isolation may greatly improve security against different types of attacks and may provide other benefits and advantages, as will be described in greater detail below.
FIG. 1A illustrates an example system and process 100 a for exchanging keys between a requestor and a key management system. As illustrated, 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 some desired secret(s) 115 , associated with a server or server side 105 . The requestor 120 may request one or more secrets or pieces of protected data from the key management system 115 , for example, to access certain protected data, execute one or more protected processes, and the like. The requestor 120 and key management system (KMS) 115 may utilize a public key-private key security system, or other key protocol, as are known in the art, to exchange the desired secrets/data.
The requestor 120 may first authenticate with the KMS 115 and establish a secure communication channel, at operation 125 , via any of known techniques in the art. Operation 125 may include utilizing a public key system or the like. Next, utilizing the secure channel established via operation 125 , the requestor 120 may send a request for one or more secrets/protected data, at operation 130 , to the KMS 115 . Upon verifying the request, the KMS 115 may transmit the secret or requested data back to the requestor 120 , at operation 135 , over the secure communication channel. As is standard in the art, the secret/requested data may be transmitted at 135 over the secure channel, without any additional protection above the secure channel. As a result, the secret/data that is transmitted at operation 135 may be exposed to the requesting device 120 .
FIG. 1B illustrates an example system and process 100 b , for more securely exchanging one or more secrets or protected data between a requestor 120 and a KMS 115 , on behalf of a trusted execution environment (TrEE) 140 , enclave, or other term used to indicate an isolated execution environment associated with the requestor 120 . The TrEE 140 may be isolated from the requestor 120 , such that code and/or data contained in the TrEE 140 may not be accessible (e.g., readable and/or writeable to) by the requestor 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 an isolated region 215 , such as may be secure from un-authorized access. In some cases, data 220 inside the isolated region 215 cannot be directly read or written by any entity other than the logic 210 associated with the isolated region 215 . The isolated logic 210 decides what types of access it will allow to what types or portions of data 220 . In one example, logic 210 may allow incrementing and reading a value associated with data 220 , but not otherwise modifying data 220 . In another example, logic 210 may allow cryptographic operations using a key without ever granting access to the value of the key itself. In the example illustrated, the logic or code 210 may be in a general or accessible region of the CPM 205 ; however, it should be appreciated, that in some instances, the logic 210 may also be located within the same or a different isolated region as state information 220 .
Returning to system 100 b , a targeting protocol head (TPH) 150 may be implemented on the server side 105 to serve as an intermediary between the requestor 120 / TrEE 140 , and the KMS 115 . Protocol head may refer to a software implementation of a protocol handler, typically fronting a system that does not natively speak a specific protocol. Targeting may refer to cryptographic targeting of the execution environment. Taken together, the term may indicate software and/or hardware that implements a protocol for retrieving secrets that targets the responses at a TrEE. In some aspects, the targeting protocol head 150 may be implemented as a virtual or cloud resource, for example, which may be running on different hardware, software, and/or separate from the KMS 115 . In some aspects, an entity such as a datacenter, may host and/or provide the targeting protocol head 150 as a service, for example. The targeting protocol head 150 may perform two primary functions: 1) communicate with the KMS 115 /obtain secret or protected data from an external entity, and 2) target responses to the TrEE 140 of the requestor 120 . As a result of the use of targeting protocol head 150 , the requestor 120 need not authenticate to the KMS 115 directly. The KMS 115 yields its secrets to the targeting protocol head 150 , and not to the requestor 120 . The function of the targeting protocol head 150 is to target responses to the TrEE 140 of the requestor 120 , thus ensuring that the requestor 120 cannot obtain the plaintext of the secret/protected data. The targeting protocol head 150 may instead authenticate to the KMS 115 on the requestor's 120 behalf, but may do so with or without using the requestor's 120 identity. In some cases, the targeting protocol head 150 may need to be convinced that the secret it is going to return to the TrEE 140 of requestor 120 is going to be in âsafe hands.â In this instance, the requestor 120 may provide attestable information to the targeting protocol head 150 about the state of the TrEE 140 , which may include attestable key material associated with the TrEE 140 , to which responses can be encrypted.
In some cases, multiple different processes, such as provided by one or more trustlets, may operate concurrently within a secure kernel, where each trustlet and the secure kernel are each considered a TrEE 140 (e.g. this is an example of a nested TrEE). In this scenario each different trustlet may be associated with a session ID, trustlet type, and/or other ID, which may be used to identify the individual trustlet within the secure kernel (e.g., both represented as TrEE 140 ). The response from the targeting protocol head 150 may be narrowly targeted at the particular trustlet within the TrEE 140 identified in the request, as will be described in greater detail below.
In the case of TrEE 140 targeting, there is no inherent need for a secure channel between the requestor 120 and the targeting protocol head 150 , since the requestor 120 itself is not trusted with the response. However, it should be appreciated that a secure channel between the requestor 120 and the targeting protocol head 150 may be added via authentication operation 160 , for example, to protect access to the request itself (which secret the requestor wants), which could lead to undesirable information disclosure. After or in place of authentication at operation 160 , the requestor 120 , on behalf of the TrEE 140 , may send a request for one or more secrets or secret or protected data to the targeting protocol head 150 , for example, to deliver to the TrEE 140 , at operation 155 . In some aspects, the request may be associated with or identify the TrEE 140 . The targeting protocol head 150 may determine if the TrEE 140 is trustworthy. In one aspect, authentication of the requestor 120 may rely on a type of clean room provisioning. In another aspect, authentication may rely upon attestation.
Clean room provisioning may be used when the requestor 120 device is, for example, brand new and reasonably assumed to be free from malicious software. An example process for delivering protected data to a TrEE associated with a requestor using clean room provisioning will be described in greater detail below in reference to FIG. 3 . An example process for delivering protected data to a TrEE associated with a requestor using attestation (e.g., an attestation service) will be described in greater detail below in reference to FIG. 4 .
In either case, once the TPH 150 has authenticated the requestor 120 , and/or established trustworthiness of the TrEE 140 , the TPH 150 may authenticate and establish a secure communication channel at operation 165 with the KMS 115 . In some aspects the KMS 115 may include or be associated with any entity that holds one or more secrets or protected data, such as licenses, permissions, passwords, and so on. Upon establishing a secure communication channel with KMS 115 , the TPH 150 may send a request for protected data at operation 170 . The KMS 115 may return the requested secret at operation 175 . The TPH 150 may target the secret(s) or protected data at the TrEE 140 and send the one or more secrets at operation 180 .
In some aspects, delivering the protected data to the TrEE 140 at operation 180 may utilize at least one of the following data structures: an encryption identity key, which may be built around the TrEE identity or attestation process or attestation log, or in the nested TrEE example (e.g., a trustlet running on top of a secure kernel), a signing identity key, which may also be built around the attestation process, as will be described in greater detail below.
FIG. 1C illustrates another example system and process 100 c , for securely exchanging one or more secrets or protected data between a requestor 120 and a KMS 115 , on behalf of a trusted execution environment (TrEE) 140 . System 100 c may be a specific example of system 100 b described above. In system 100 c , the targeting protocol head 150 may be a Host Guardian Service (HGS) 150 a . In system 100 c , the HGS 150 a may receive a key protector 190 , for example, from a cloud host 185 or other entity that may instantiate or otherwise control the TrEE 140 . In system 100 c , the requestor 120 may be associated with a virtual machine, for example, provided by cloud host 185 . The KP 190 may incorporate one or more aspects of the key protector described in related U.S. patent application Ser. No. 14/481,399 titled âSecure Transport of Encrypted Virtual Machines with Continuous Owner Access,â filed Sep. 9, 2014, the contents of which are herein incorporated by reference in its entirety. The KP 190 may contain one or more secrets usable by the TrEE 140 , such as a transport key. The KP 190 may in essence wrap the transport key so that it is accessible only by a set of guardians, which are authorized to access the transport key. The KP 190 may be encrypted such that in order to read the contents of the KP 190 , and retrieve the transport key, the HGS 150 a may request a decryption key from KMS 115 , at operation 170 a , after authenticating and establishing a secure commination channel with KMS 115 at operation 165 . The KMS 115 , in response, may send the decryption key to the HGS at operation 175 a . The HGS 150 a may then use the decryption key to decrypt the KP 190 , and retrieve the one or more secrets (e.g., transport key), to send to the TrEE 140 . The HGS 150 a may then send the secrets or transport key to the TrEE at operation 180 , via one or more addressing techniques that will be described in greater detail below. In some aspects, the TrEE 140 may be addressed based on data from the KP 190 .
It should be appreciated that in some cases, the HGS 150 a and the KMS 115 may be one entity, such that no communication channel needs to be established between them and no authentication is needed.
In system 100 c , no authentication between the requestor 120 and the HGS 150 a is needed. As long as the cloud or fabric host 180 is healthy, it does not matter which fabric host is communicating with HGS 150 a , so long as it is one of the servers in the fabric (this may 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 trustworthy (e.g., free from malicious software). As used herein, dashed lines of a box or operation in any figure indicate that the operation is optional, such that it may be excluded. Process 300 may utilize an encryption key associated with the TrEE, such as the public key of a public key private key pair (e.g., an asymmetric key pair) generated by the TrEE or a secure kernel of the requestor that initiates the TrEE. In other cases, the encryption key may be symmetric. As used herein, a secure kernel may refer to any portion of a computing device that is associated with higher level of security, as is known in the art.
In this scenario, a TrEE 140 may be launched or initiated at operation 302 , and one or more private keys (e.g., private encryption keys) and corresponding public keys may be generated inside the TrEE 140 , at operation 304 . The corresponding public key may then be registered with the TPH 150 and associated with the requestor's and/or requesting device's identity, at operation 306 . In some cases, the public key of the TrEE 140 needs to be registered only once, such that after the public key is registered, process 300 may begin at operation 308 . Subsequently, the requestor 120 may authenticate at operation 308 with the TPH 150 , via any known authentication technique. The TPH 150 can then look up the public key to use in delivering the response to the TrEE 140 , for example, based on the registered public key of the TrEE 140 , which may be associated with an identity of the requestor 120 . This process may be referred to as âclean roomâ provisioning because it can only be done securely when the requestor 120 is in a known-good or trustworthy state. In this example, there is no need for a certificate based authentication where the requestor 120 sends a TrEE Health Certificate (THC) to the TPH 150 , because the requestor 120 is trustworthy. In the absence of ubiquitous attestation services, this is a viable option to validate that the correct TrEE 140 is being targeted by the TPH 150 .
Next, the TPH 150 may obtain protected data for delivery to the TrEE 140 , for example from a KMS 115 , as described above, at operation 312 . Using the TrEE public key accessed via operation 310 , the TPH 150 may then construct a message to send to the TrEE 140 , including the obtained protected data, at operation 314 . The TPH 150 may send the message to the requestor 120 at operation 316 .
Upon receiving the message, the requestor 120 may forward it to the TrEE 140 , at operation 318 . Because the requestor 120 does not have access to the TrEE's private key, the requestor 120 cannot decrypt the message to access the protected data. The TrEE 140 may use its private key to decrypt the message and access the protected data, at operation 320 .
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 the TrEE, such as the public key of a public key private key pair generated by the TrEE or a secure kernel of the requestor that initiates the TrEE, such as in the case of a nested TrEE, which may be referred to herein as a trustlet. Process 400 may additionally or alternatively utilize a signing key of the secure kernel, which may be considered the outer TrEE, with the trustlet nested or running on top of the secure kernel, associated with the TrEE, which may be used to certify the public key of the key pair generated by the TrEE, as will be described in greater detail below.
According to process 400 , after initialization of a TrEE at operation 402 , the requestor 120 may request an attestation report or statement from an attestation service, at operation 406 . FIG. 4B illustrates an example process for obtaining an attestation statement or report from an attestations service 424 . In the example of FIG. 4B , the requestor 120 may create an attestation log (TCG log) at boot containing a public key (IDK_E) of the TrEE 140 (trustlet) or a signing key (IDK_S) of the TrEE (secure kernel), at operation 426 . The requestor 120 may then present the TCG log to an attestation service 424 , at operation 428 . In some cases, the TPH 150 may direct, or the requestor 120 may choose, an attestation service that is trusted by the TPH 150 . The attestation service 424 may inspect the TCG log and issue a TrEE Health Certificate (THC) based on the encryption key (IDK_E) and/or signing key (IDK_S) of the TrEE 140 (secure kernel), at operation 430 . The attestation service 242 may then send the THC (also referred to herein as an attestation statement) back to the requestor 120 at operation 432 .
Upon 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 requestor 120 (to create binding between requestor's identity established during authentication and the certificate), and the key that the responder (TPH 150 ) should use in formulating the response (e.g., an encryption key or signing key).
In some aspects, a tamper-proof identity, such as a trusted platform module's (TPM) encryption key (EK) is associated with the requestor 120 . Attestation of the requestor 120 may be performed using the TPM EK, as known in the art.
In some aspects, either out of band, or through an issuance policy (IP) object identifier (OID), which may be part of the THC, the TrEE via the requestor 120 may communicate to the TPH 150 whether the key is an encryption key or a signing key. The choice between which key is used may affect the choice of mechanism used to structure the response, as described above. Critically, proof of possession of the private key backing the certificate is not required by the TPH 150 , simply because if the wrong certificate is given, the requestor 120 won't be able to make sense of the response anyways, since it does not have access to the corresponding private key.
FIGS. 5A and 5B illustrate an example process 500 for delivering protected data to a nested TrEE of an untrusted requestor. In some aspects, two or more TrEE's may be nested, such that one TrEE is contained within another TrEE. As referred to herein, a trustlet is the nested TrEE, which is contained in an outer TrEE. In one example, the outer TrEE may include a secure kernel of a trusted portion of an operating system, such as a specific partition of memory associated with a virtual trust level, as will be described in greater detail below in reference to FIG. 6 . Process 500 may be utilized when for example, only the encryption key of the outer TrEE, which in some cases may be the secure kernel of the machine instantiating the trustlet, is available.
Process 500 may begin at operation 502 , in which the requestor 120 launches the trustlet with a âsession identifierâ that is decided by the requestor 120 , which may include any type of identifier, such as related to or identifying what content or data the trustlet will operate on, relating to a user of the trustlet, etc. (e.g. âstreaming content application trustlet for playing âspecific titleââ). In one example, the session ID may be a 32-byte value. The value may be preserved, read-only for the duration of the trustlet's lifetime and available to the secure kernel when receiving a targeted message to the trustlet. The value could be missing (not specified at process launch), in which case the session ID can be assumed to be zero.
Next, at operation 504 , the requestor 120 may authenticate to the TPH 150 (optional as described above, but only in very limited circumstances, such as where there really is no difference between requestors). One example where binding between the TrEE (e.g., the TrEE's key) and the requestor's identity is desired, for instance, is when the playing of a content item, such as movie, is restricted by license or subscriber validation (e.g., a NetFlix user wants to get a license to play a movie but NetFlix wants to make sure that it is that subscriber that is receiving the movie license (inside their TrEE)).
The requestor 120 may obtain an attestation statement, such as according to <figure-callout id="406" label="process" filenames="US10897459-20210119-D00000.png,US10897459-
CLAIMS
Claims ( 20 )
What is claimed is:
1. A computing system, comprising:
a processor; and
a memory coupled to the processor, storing instructions that when executed by the processor, cause the computing system to perform the following operations:
receiving a request for protected data from a potentially untrusted requestor associated with a nested TrEE and an attestation statement of a secure kernel, wherein the nested TrEE comprises a trustlet running on top of the secure kernel, wherein the trustlet is associated with a trustlet ID that is based at least in part on at least one of the following: information on which the trustlet is to operate, a user of the trustlet, or a service type associated with at least one of the request or a configuration of the system;
encrypting a transfer encryption key with a second encryption key that is included in the attestation statement;
retrieving the protected data;
encrypting the protected data with the transfer encryption key and an authentication tag, wherein the authentication tag binds the requestor with the trustlet ID; and
providing the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
2. The computing system of claim 1 , wherein the trustlet ID comprises a trustlet type and a session ID.
3. The computing system of claim 2 , wherein the second encryption key comprises a secure kernel encryption key.
4. The computing system of claim 3 , wherein a private secure kernel encryption key corresponding to the secure kernel encryption key is required to decrypt the encrypted protected data.
5. The computing system of claim 1 , wherein the instructions comprise additional instructions that when executed by the processor, cause the computing system to perform the following operations:
comparing the trustlet ID to a list of authorized trustlet IDs; and
encrypting the protected data with the transfer encryption key and an authentication tag only if the trustlet ID is associated with the list of authorized trustlet IDs.
6. The computing system of claim 1 , wherein the protected data comprises a wrapping key.
7. A method for delivering protected data to a nested trusted execution environment (TrEE) comprising a trustlet running on top of secure kernel, wherein both the trustlet and the secure kernel are associated with a potentially untrusted requestor, the method comprising:
receiving, by at least one processor of a processor-based system, a request for protected data from the potentially untrusted requestor associated with the nested TrEE and an attestation statement of the secure kernel, wherein the trustlet is associated with a trustlet ID that includes at least one of (a) a service type that is based on at least one of the request or a configuration of the system or (b) an identifier related to at least one of information on which the trustlet is to operate or a user of the trustlet;
encrypting a transfer encryption key with a second encryption key that is included in the attestation statement;
retrieving, by at least one processor of the processor-based system, the protected data;
encrypting the protected data with the transfer encryption key and an authentication tag, wherein the authentication tag binds the requestor with the trustlet ID; and
providing the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
8. The method of claim 7 , wherein the trustlet ID comprises a trustlet type and a session ID.
9. The method of claim 8 , wherein providing the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor comprises:
causing the potentially untrusted requestor to send the encrypted transfer encryption key and the encrypted protected data to the secure kernel, which enables the secure kernel to decrypt the transfer key with a private second encryption key corresponding to the second encryption key and to decrypt the protected data with the decrypted transfer key.
10. The method of claim 9 , wherein providing the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor comprises:
causing the secure kernel to send the encrypted transfer encryption key and the encrypted protected data to the trustlet, which causes the trustlet to forward the encrypted transfer encryption key and the encrypted protected data to the secure kernel.
11. The method of claim 9 , wherein providing the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor comprises:
enabling the secure kernel to confirm that the encrypted protected data is for the trustlet based on the trustlet type and the session ID and to send the decrypted protected data to the trustlet based on the trustlet type and the session ID.
12. The method of claim 7 , wherein the protected data comprises a wrapping key.
13. The method of claim 7 , further comprising:
comparing, by at least one processor of the processor-based system, the trustlet ID to a list of authorized trustlet IDs; and
encrypting, by at least one processor of the processor-based system, the protected data with the transfer encryption key and an authentication tag only if the trustlet ID is associated with the list of authorized trustlet IDs.
14. The method of claim 7 , wherein the authentication tag binds the requestor with at least one of a trustlet type or a session ID included in the trustlet ID.
15. A computer readable storage medium comprising instructions for delivering protected data to a nested trusted execution environment (TrEE) comprising a trustlet running on top of secure kernel, the medium comprising instructions that, when executed on a computer system, cause the computer system to at least:
receive a request for protected data from a potentially untrusted requestor associated with the nested TrEE and an attestation statement of the secure kernel, wherein the trustlet is associated with a trustlet ID;
determine a service type of trustlet to target based on the request or based on a configuration of the system, wherein the trustlet that runs on top of the secure kernel is of the type;
encrypt a transfer encryption key with a second encryption key that is included in the attestation statement;
retrieve the protected data;
encrypt the protected data with the transfer encryption key and an authentication tag, wherein the authentication tag binds the requestor with the trustlet ID; and
provide the encrypted transfer encryption key, the encrypted protected data, and encrypted authentication tag to the requestor.
16. The computer readable storage medium of claim 15 , wherein the trustlet ID comprises a trustlet type and a session ID.
17. The computer readable storage medium of claim 16 , wherein the second encryption key comprises a secure kernel encryption key.
18. The computer readable storage medium of claim 17 , wherein a private secure kernel encryption key corresponding to the secure kernel encryption key is required to decrypt the encrypted protected data.
19. The computer readable storage medium of claim 15 , wherein the protected data comprises a wrapping key.
20. The computer readable storage medium of claim 15 , wherein the instructions further comprise instructions that when executed on the computing system, cause the computing system to at least:
compare the trustlet ID to a list of authorized trustlet IDs; and
encrypt the protected data with the transfer encryption key and an authentication tag only if the trustlet ID is associated with the list of authorized trustlet IDs.
US15/417,060
2017-01-26
2017-01-26
Addressing a trusted execution environment using encryption key
Active
2037-03-31
US10897459B2
( en )
Priority Applications (19)
Application Number
Priority Date
Filing Date
Title
US15/417,060
US10897459B2
( en )
2017-01-26
2017-01-26
Addressing a trusted execution environment using encryption key
SG11201905456UA
SG11201905456UA
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
PCT/US2017/067460
WO2018140169A1
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
EP17829838.6A
EP3574434B1
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
MX2019008694A
MX2019008694A
( en )
2017-01-26
2017-12-20
ADDRESSING A RELIABLE EXECUTION ENVIRONMENT USING THE ENCRYPTION KEY.
CA3048894A
CA3048894C
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
JP2019540658A
JP2020506612A
( en )
2017-01-26
2017-12-20
Addressing to a trusted execution environment using an encryption key
RU2019126625A
RU2756048C2
( en )
2017-01-26
2017-12-20
Addressing trusted execution environment using encryption key
AU2017396530A
AU2017396530B2
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
CN201780084684.XA
CN110249332B
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using cryptographic keys
KR1020197021865A
KR102443857B1
( en )
2017-01-26
2017-12-20
Addressing technique of trusted execution environment using encryption key
BR112019013398-4A
BR112019013398B1
( en )
2017-01-26
2017-12-20
COMPUTING SYSTEM, METHOD FOR PROVIDING PROTECTED DATA TO AN EMBEDDED TRUSTED EXECUTION ENVIRONMENT, AND COMPUTER-READABLE STORAGE MEDIUM
MYPI2019003997A
MY203672A
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
NZ754543A
NZ754543A
( en )
2017-01-26
2017-12-20
Addressing a trusted execution environment using encryption key
ZA2019/03701A
ZA201903701B
( en )
2017-01-26
2019-06-10
Addressing a trusted execution environment using encryption key
PH12019550116A
PH12019550116A1
( en )
2017-01-26
2019-06-28
Addressing a trusted execution environment using encryption key
IL268006A
IL268006B
( en )
2017-01-26
2019-07-11
Addressing a trusted execution environment using encryption key
CL2019002027A
CL2019002027A1
( en )
2017-01-26
2019-07-19
Addressing a trusted execution environment using encryption key.
CONC2019/0007876A
CO2019007876A2
( en )
2017-01-26
2019-07-22
Addressing a reliable runtime environment using encryption key
Applications Claiming Priority (1)
Application Number
Priority Date
Filing Date
Title
US15/417,060
US10897459B2
( en )
2017-01-26
2017-01-26
Addressing a trusted execution environment using encryption key
Publications (2)
Publication Number
Publication Date
US20180212940A1
US20180212940A1 ( en )
2018-07-26
US10897459B2
true
US10897459B2 ( en )
2021-01-19
Family
ID=60991590
Family Applications (1)
Application Number
Title
Priority Date
Filing Date
US15/417,060
Active
2037-03-31
US10897459B2
( en )
2017-01-26
2017-01-26
Addressing a trusted execution environment using encryption key
Country Status (18)
Country
Link
US
( 1 )
US10897459B2
( en )
EP
( 1 )
EP3574434B1
( en )
JP
( 1 )
JP2020506612A
( en )
KR
( 1 )
KR102443857B1
( en )
CN
( 1 )
CN110249332B
( en )
AU
( 1 )
AU2017396530B2
( en )
CA
( 1 )
CA3048894C
( en )
CL
( 1 )
CL2019002027A1
( en )
CO
( 1 )
CO2019007876A2
( en )
IL
( 1 )
IL268006B
( en )
MX
( 1 )
MX2019008694A
( en )
MY
( 1 )
MY203672A
( en )
NZ
( 1 )
NZ754543A
( en )
PH
( 1 )
PH12019550116A1
( en )
RU
( 1 )
RU2756048C2
( en )
SG
( 1 )
SG11201905456UA
( en )
WO
( 1 )
WO2018140169A1
( en )
ZA
( 1 )
ZA201903701B
( en )
Cited By (1)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20220261486A1
( en )
*
2020-01-28
2022-08-18
Intel Corporation
Cryptographic separation of memory on device with use in dma protection
Families Citing this family (22)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
KR101724089B1
( en )
*
2013-04-18
2017-04-06
주ìíì¬ íì´ì¤ì½
File security method and apparatus therefor
US10972265B2
( en )
*
2017-01-26
2021-04-06
Microsoft Technology Licensing, Llc
Addressing a trusted execution environment
US10897360B2
( en )
2017-01-26
2021-01-19
Microsoft Technology Licensing, Llc
Addressing a trusted execution environment using clean room provisioning
US10771439B2
( en )
*
2017-06-28
2020-09-08
Microsoft Technology Licensing, Llc
Shielded networks for virtual machines
US10521360B1
( en )
2017-10-18
2019-12-31
Google Llc
Combined integrity protection, encryption and authentication
US10509914B1
( en )
*
2017-10-27
2019-12-17
Vmware, Inc.
Data policy implementation in a tag-based policy architecture
US11095652B2
( en )
*
2018-02-20
2021-08-17
International Business Machines Corporation
Implementing a separation of duties for container security
US11475147B2
( en )
2018-02-20
2022-10-18
International Business Machines Corporation
Implementing policy-based container-level encryption
US11443072B2
( en )
2018-06-29
2022-09-13
Microsoft Technology Licensing, Llc
Peripheral device with resource isolation
US11126757B2
( en )
*
2018-10-19
2021-09-21
Microsoft Technology Licensing, Llc
Peripheral device
CN110392889B
( en )
*
2019-03-26
2020-09-01
é¿éå·´å·´éå¢æ§è¡æéå ¬å¸
Field Programmable Gate Array-Based Trusted Execution Environment for Blockchain Networks
US11469890B2
( en )
*
2020-02-06
2022-10-11
Google Llc
Derived keys for connectionless network protocols
US11630683B2
( en )
2020-02-26
2023-04-18
Red Hat, Inc.
Low latency launch for trusted execution environments
US11888972B2
( en )
2020-02-26
2024-01-30
Red Hat, Inc.
Split security for trusted execution environments
US11620411B2
( en )
2020-03-24
2023-04-04
Red Hat, Inc.
Elastic launch for trusted execution environments
CN112597458B
( en )
*
2020-12-22
2023-12-01
åäº¬å «åéä¿¡æ¯ç§ææéå ¬å¸
Methods, devices and related products for identity authentication based on trusted authentication
CN113722726B
( en )
*
2021-02-09
2024-04-05
京ä¸ç§ææ§è¡è¡ä»½æéå ¬å¸
Encryption and decryption method and system based on software and hardware cooperation
KR102580570B1
( en )
*
2021-10-15
2023-09-21
ë¤ì´ë²í´ë¼ì°ë 주ìíì¬
Method for decrypting virtual server in cloud server and cloud server using the same
CN114036527B
( en )
*
2021-11-04
2023-01-31
äºæµ·é¾æ§è¡è¡ä»½æéå ¬å¸
Code injection method, code running end, code injection end and related equipment
CN114553590B
( en )
*
2022-03-17
2023-08-22
æé³è§çæéå ¬å¸
Data transmission method and related equipment
US20240195635A1
( en )
*
2022-12-12
2024-06-13
Intel Corporation
Roots of trust in intellectual property (ip) blocks in a system on a chip (soc)
EP4690663A2
( en )
*
2023-05-02
2026-02-11
LiveRamp, Inc.
Privacy-safe clean room collaboration
Citations (60)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20090198997A1
( en )
2006-11-20
2009-08-06
Tet Hin Yeap
System and method for secure electronic communication services
US20110154031A1
( en )
2009-12-21
2011-06-23
International Business Machines Corporation
Secure Kerberized Access of Encrypted File System
US20110246624A1
( en )
*
2008-10-10
2011-10-06
Telefonaktiebolaget Lm Ericsson (Publ)
Service Node, Control Method Thereof, User Node, and Control Method Thereof
US20120239936A1
( en )
2009-12-18
2012-09-20
Nokia Corporation
Credential transfer
US20120331550A1
( en )
*
2011-06-24
2012-12-27
Microsoft Corporation
Trusted language runtime on a mobile platform
US20130109352A1
( en )
*
2011-10-27
2013-05-02
T-Mobile USA, Inc
Mobile Device-Type Locking
US20130210389A1
( en )
*
2011-10-27
2013-08-15
T-Mobile Usa, Inc.
Remote Unlocking of Telecommunication Device Functionality
US20130281058A1
( en )
*
2012-04-20
2013-10-24
T-Mobile Usa, Inc.
Secure Environment for Subscriber Device
US20140006773A1
( en )
2012-06-29
2014-01-02
France Telecom
Secured cloud data storage, distribution and restoration among multiple devices of a user
US20140095876A1
( en )
*
2012-09-28
2014-04-03
Ned Smith
Introduction of discrete roots of trust
US20140108805A1
( en )
2012-10-12
2014-04-17
Ned M. Smith
Technologies labeling diverse content
US20140108786A1
( en )
2011-03-11
2014-04-17
Emsycon Gmbh
Tamper-protected hardware and method for using same
US20140281531A1
( en )
2013-03-14
2014-09-18
Vinay Phegade
Trusted data processing in the public cloud
US20150026790A1
( en )
2012-02-28
2015-01-22
Giesecke & Devrient Gmbh
Method for Computer Access Control by Means of Mobile End Device
WO2015026336A1
( en )
2013-08-21
2015-02-26
Intel Corporation
Processing data privately in the cloud
US20150134942A1
( en )
*
2013-11-14
2015-05-14
Microsoft Corporation
Hardware rooted attestation
EP2887607A1
( en )
2013-12-23
2015-06-24
Orange
Migration of assets of a trusted execution environment
WO2015094326A1
( en )
2013-12-20
2015-06-25
Intel Corporation
Secure import and export of keying material
US9141769B1
( en )
2013-02-08
2015-09-22
Amazon Technologies, Inc.
Secure transfer and use of secret material in a shared environment
US20150278531A1
( en )
2014-03-31
2015-10-01
Intel Corporation
Methods and apparatus to securely share data
US20150282228A1
( en )
2014-03-26
2015-10-01
Andreas Schmidt
Systems, methods, and devices for distributed setup for a device-to-device session
US20150281186A1
( en )
2013-12-24
2015-10-01
Ned M. Smith
Content protection for data as a service (daas)
US20150319160A1
( en )
*
2014-05-05
2015-11-05
Microsoft Corporation
Secure Management of Operations on Protected Virtual Machines
US20150348026A1
( en )
*
2014-05-14
2015-12-03
Mastercard International Incorporated
Security for mobile applications
US20150381575A1
( en )
2014-06-27
2015-12-31
Intel Corporation
Face Based Secure Messaging
US20160140343A1
( en )
*
2014-11-14
2016-05-19
Microsoft Technology Licensing, Llc
Secure Creation of Encrypted Virtual Machines from Encrypted Templates
US20160182228A1
( en )
2014-12-23
2016-06-23
Intel Corporation
Diffie-hellman key agreement using an m-of-n threshold scheme
US20160254918A1
( en )
2015-02-27
2016-09-01
Samsung Electronics Co., Ltd
Trust-zone-based end-to-end security
US20160269374A1
( en )
2015-03-10
2016-09-15
Intel Corporation
Internet of things group formation using a key-based join protocol
US20160337329A1
( en )
2015-05-11
2016-11-17
Kapil Sood
Technologies for secure bootstrapping of virtual network functions
US20170005790A1
( en )
2015-06-30
2017-01-05
Activevideo Networks, Inc.
Remotely Managed Trusted Execution Environment For Digital-Rights Management In A Distributed Network With Thin Clients
US9578664B1
( en )
*
2013-02-07
2017-02-21
Sprint Communications Company L.P.
Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US20170213218A1
( en )
2016-01-26
2017-07-27
Worldpay Limited
Tamper-proofing and identity validation in a secure electronic transaction processing system
US9781016B1
( en )
*
2015-11-02
2017-10-03
Sprint Communications Company L.P.
Dynamic addition of network function services
US20170289197A1
( en )
2016-03-31
2017-10-05
Qualcomm Incorporated
Transport layer security token binding and trusted signing
US20170302459A1
( en )
*
2016-04-19
2017-10-19
Microsoft Technology Licensing, Llc
Key-Attestation-Contingent Certificate Issuance
US20170317996A1
( en )
*
2016-05-02
2017-11-02
Intel Corporation
Technologies for secure mediated reality content publishing
US20170317990A1
( en )
2016-05-02
2017-11-02
Samsung Electronics Co., Ltd.
Apparatus and method for managing virtual subscriber indentity module
US20180025343A1
( en )
*
2015-01-09
2018-01-25
Ingenico Group
Method for processing a transaction from a communication terminal
US20180101677A1
( en )
2016-10-06
2018-04-12
Samsung Electronics Co., Ltd
Trusted execution environment secure element communication
US20180152454A1
( en )
2016-11-28
2018-05-31
Samsung Electronics Co., Ltd.
Method and apparatus for managing program of electronic device
US20180212769A1
( en )
2017-01-26
2018-07-26
Microsoft Technology Licensing, Llc
Addressing a trusted execution environment
US20180212932A1
( en )
2017-01-26
2018-07-26
Microsoft Technology Licensing, Llc
Addressing a trusted execution environment using signing key
US20180212778A1
( en )
2017-01-26
2018-07-26
Microsoft Technology Licensing, Llc
Addressing a trusted execution environment using clean room provisioning
US10127409B1
( en )
*
2016-12-16
2018-11-13
Square, Inc.
Tamper detection system
US20180367317A1
( en )
*
2015-12-16
2018-12-20
Nagravision S.A.
Hardware integrity check
US10169574B2
( en )
*
2014-12-16
2019-01-01
Intel Corporation
Using trusted execution environments for security of code and data
US20190005229A1
( en )
2015-12-11
2019-01-03
Gemalto Sa
Mobile device having trusted execution environment
US20190026452A1
( en )
*
2015-12-29
2019-01-24
Huawei Technologies Co., Ltd.
Method for Associating Application Program with Biometric Feature, Apparatus, and Mobile Terminal
US20190087586A1
( en )
*
2009-12-22
2019-03-21
Intel Corporation
Method and apparatus to provide secure application execution
US20190158291A1
( en )
*
2013-03-15
2019-05-23
Ologn Technologies Ag
Systems, Methods and Apparatuses for Device Attestation Based on Speed of Computation
US20190172047A1
( en )
*
2016-08-09
2019-06-06
Huawei Technologies Co.,Ltd.
System on chip and processing device
US10404466B2
( en )
*
2014-03-06
2019-09-03
Microsoft Technology Licensing, Llc
Secure hardware for cross-device trusted applications
US10412191B1
( en )
*
2016-03-30
2019-09-10
Amazon Technologies, Inc.
Hardware validation
US20190311362A1
( en )
*
2011-09-02
2019-10-10
Payoak, Inc.
Secure elements broker (seb) for application communication channel selector optimization
US10484172B2
( en )
*
2015-06-05
2019-11-19
Apple Inc.
Secure circuit for encryption key generation
US10530777B2
( en )
2017-01-24
2020-01-07
Microsoft Technology Licensing, Llc
Data unsealing with a sealing enclave
US10601978B2
( en )
*
2014-06-04
2020-03-24
T-Mobile Usa, Inc.
Telecommunication device utilization based on heartbeat communication
US10700865B1
( en )
*
2016-10-21
2020-06-30
Sequitur Labs Inc.
System and method for granting secure access to computing services hidden in trusted computing environments to an unsecure requestor
US10740747B2
( en )
*
2015-06-02
2020-08-11
Orange
NFC-enabled devices for performing secure contactless transactions and using HCE
Family Cites Families (7)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US7437771B2
( en )
*
2004-04-19
2008-10-14
Woodcock Washburn Llp
Rendering protected digital content within a network of computing devices or the like
US7697691B2
( en )
*
2004-07-14
2010-04-13
Intel Corporation
Method of delivering Direct Proof private keys to devices using an on-line service
US8059820B2
( en )
*
2007-10-11
2011-11-15
Microsoft Corporation
Multi-factor content protection
US8321956B2
( en )
*
2009-06-17
2012-11-27
Microsoft Corporation
Remote access control of storage devices
US9413538B2
( en )
*
2011-12-12
2016-08-09
Microsoft Technology Licensing, Llc
Cryptographic certification of secure hosted execution environments
KR101801567B1
( en )
*
2013-12-19
2017-11-27
ì¸í ì½í¬ë ì´ì
Policy-based trusted inspection of rights managed content
US9621547B2
( en )
*
2014-12-22
2017-04-11
Mcafee, Inc.
Trust establishment between a trusted execution environment and peripheral devices
2017
2017-01-26
US
US15/417,060
patent/US10897459B2/en
active
Active
2017-12-20
CN
CN201780084684.XA
patent/CN110249332B/en
active
Active
2017-12-20
MX
MX2019008694A
patent/MX2019008694A/en
unknown
2017-12-20
KR
KR1020197021865A
patent/KR102443857B1/en
active
Active
2017-12-20
AU
AU2017396530A
patent/AU2017396530B2/en
active
Active
<li itemprop="applic