Method and apparatus for two-step multi-security-domain cloud key attestation

Abstract

An apparatus and method configured for two-step cross-security-domain cloud-based privacy-aware key attestation where a root security domain, factory-provisioned with a root-of-trust device key, generates a random key signing key upon device initialization. An application, executing in a rich execution environment, generates an application key pair within a secondary security domain. The secondary security domain obtains a local key attestation from the root security domain, where the local key attestation is signed with the key signing key and returns the local key attestation to the application. When key attestation from a cloud attestation service is desired, the root security domain validates the local key attestation, generates a corresponding device key attestation signed with the device key, and sends the device key attestation to a cloud attestation service. The cloud attestation service verifies the device key attestation and returns a corresponding cloud key attestation signed with a certified cloud attestation key.

Description

METHOD AND APPARATUS FOR TWO-STEP MULTI-SECURITY-DOMAIN CLOUD KEY ATTESTATIONTECHNICAL FIELD

[0001] The aspects of the disclosed embodiments relate generally to computer security and more particularly to remote attestation techniques.BACKGROUND

[0002] Much of today’s computer security is based on cryptography. Encryption ensures confidentiality, signatures ensure data integrity, and certificates ensure authenticity. However, cryptography is reliable only when the keys are properly protected.

[0003] Remote attestation is a technique used in computer security that allows a remote entity to verify the hardware and software configuration of a computing apparatus. Key attestation is a process that provides assurances that cryptographic keys are being properly protected on the remote device, such as by generating and managing the keys in a hardware backed security domain.

[0004] Conventional key attestation techniques provide attestation services only within a single security domain, thereby requiring that attestation for a key can only be obtained from the security domain in which the key is being managed. This makes sense from a security perspective, but severely limits the use cases supported in an open ecosystem where a device can have many security domains. Only the device / chip vendors are able to provide a root of trust by provisioning Device Keys during manufacturing. Security domains created or managed by third parties do not have access to the root of trust required to fully support key attestation.

[0005] Conventional key attestation techniques often suffer from sub-optimal performance due to the high-performance required to support a certificate authority (CA) and the high complexity and risks posed during manufacturing and attestation.

[0006] Thus, there is a need for improved key attestation techniques that efficiently support cross-domain cloud based key attestation. Accordingly, it would be desirable to provide methods and apparatus that addresses at least some of the problems described above.SUMMARY

[0007] The aspects of the disclosed embodiments are directed to a computing apparatus and method configured to provide two-step cross-security-domain cloud-based privacy-aware key attestation, where the provided key attestation allows the root-of-trust device keys, provisioned into the root security domain during manufacturing, to be used to attest keys generated in secondary security domains on the same computing apparatus in an efficient and scalable fashion. Beneficially, the root security domain needs no prior knowledge of the secondary security domains to perform the disclosed cross-security domain key attestation processes.

[0008] According to a first aspect, the above and further aspects and advantages are obtained by a computing apparatus configured to provide a root security domain, provisioned with a device key, and a secondary security domain. The computing apparatus is configured to: generate a key signing key; perform a local attestation; and perform a cloud attestation. The local attestation includes: generating, within the secondary security domain, an application key pair, wherein the application key pair includes an application public key and an application private key; sending, from the secondary security domain to the root security domain, a local key attestation request, wherein the local key attestation request includes the application public key, a challenge, and an application identifier; generating, within the root security domain, a local key attestation, wherein the local key attestation is signed with the key signing key and includes the application public key, the challenge, a secondary security domain identifier, and the application identifier. The cloud attestation includes: receiving, within the root security domain, a cloud key attestation request, wherein the cloud key attestation request includes the local key attestation; validating, within the root security domain, the local key attestation based at least in part on the key signing key; and generating, within the root security domain, a device key attestation, where the device key attestation is signed with the device key and includes the application public key, the challenge, the secondary security domain identifier, the application identifier, and a timestamp; sending the device key attestation, from the root security domain to a cloud key attestation service, and receiving within the root security domain, a cloud key attestation, wherein the cloud key attestation is signed with a cloud attestation key and includes the application public key, the challenge, the secondary security domain identifier, the application identifier, and the timestamp. The apparatus provides two-step cross-security-domain cloud-based privacy-aware key attestation, where the provided key attestation allows the root-of-trust device keys, provisioned into the root security domain during manufacturing, to be used to attest keys generated in secondary security domains on the same computing apparatus in an efficient and scalable fashion

[0009] In a possible implementation form the computing apparatus further comprises a rich execution environment configured to execute an application, and the local attestation further includes: receiving the challenge within the application; and sending the challenge from the application to the secondary security domain. Retrieving the challenge from the cloud service helps the cloud service ensure freshness of the cloud key attestation.

[0010] In a possible implementation form, the challenge is reproducibly computed within the application. Reproducibly computing the challenge within the application reduces network bandwidth usage and avoids network delays associated with contacting the cloud service.

[0011] In a possible implementation form, the key signing key is generated during initialization of the computing apparatus. Generation of the key signing key during initialization provides a new key signing key on each device boot.

[0012] In a possible implementation form, the key signing key is re-generated based on a security policy, and the local key attestation further includes an identifier of the key signing key used to sign the local key attestation. Rotation of the key signing key reduces the risks of key leakage or misuse.

[0013] In a possible implementation form, the local key attestation request is sent over a secure communication channel, and the secure communication channel is one of a physical communication channel, and a logical communication channel. Use of a secure communication channel between the secondary security domain and the root security domain reduces chances of the request being attacked.

[0014] In a possible implementation form, the secure communication channel is established during one or more of an initialization of the second security domain, and an availability of the second security domain. Early establishment of the secure communication channel helps protect against attacks.

[0015] In a possible implementation form, the key signing key is one of a symmetric key and an asymmetric key. Flexibility as to the type of key used for the key signing key broadens the range of apparatus to which the disclosed key attestation processes may be applied.

[0016] In a possible implementation form, the cloud attestation further includes a hash of the application public key. A hash of the public key has the advantage of being smaller than the public key an is of fixed size.

[0017] In a possible implementation form, the root security domain is provisioned with a device certificate chain, and where the device certificate chain includes one or more certificates configured to verify the device key. Provisioning of the device certificate chain allows the certificate chain to be included in the cloud key attestation request, thereby reducing work required by the cloud attestation service.

[0018] In a possible implementation form, the device key attestation further comprises the device certificate chain. Incorporating the device certificate chain into the device key attestation can improve trust of the certificate chain.

[0019] In a possible implementation form, the root security domain is configured to receive a cloud certificate chain, and the cloud certificate chain includes one of more certificates configured to verify the cloud attestation key. Receiving the cloud certificate chain allows verification of the cloud key attestation.

[0020] In a possible implementation form, the cloud certificate chain is received together with the cloud key attestation or downloaded separately. Receiving the cloud certificate chain together with the cloud key attestation simplifies verification of the cloud key attestation.

[0021] According to a second aspect, the above and further aspects and advantages are obtained by a method for cross-security-domain key attestation in a computing apparatus, where the computing apparatus comprises a root security domain provisioned with a device key, and a secondary security domain. The method includes: generating a key signing key; performing a local attestation; and performing a cloud attestation. The local attestation includes: generating, within the secondary security domain, an application key pair, where the application key pair includes an application public key and an application private key; sending, from the secondary security domain to the root security domain, a local key attestation request, where the local key attestation request includes the application public key, a  challenge, and an application identifier; generating, within the root security domain, a local key attestation, where the local key attestation is signed with the key signing key and includes the application public key, the challenge, a secondary security domain identifier, and the application identifier. The cloud attestation includes: receiving, within the root security domain, a cloud key attestation request where the cloud key attestation request includes the local key attestation; validating, within the root security domain, the local key attestation based at least in part on the key signing key; generating, within the root security domain, a device key attestation, wherein the device key attestation is signed with the device key and includes the application public key, the challenge, the application identifier, the secondary security domain identifier, and a timestamp; sending, from the root security domain to a cloud key attestation service, the device key attestation, and receiving, within the root security domain, a cloud key attestation, where the cloud key attestation is signed with a cloud attestation key and includes the application public key, the challenge, the secondary security domain identifier, the application identifier, and the timestamp; and receiving, within the application, the cloud key attestation.

[0022] In a possible implementation form, the computing apparatus further includes an application configured to execute within a rich execution environment, and the local attestation further includes: receiving the challenge within the application; and sending the challenge from the application to the secondary security domain. Retrieving the challenge from the cloud service helps the cloud service ensure freshness of the cloud key attestation.

[0023] In a possible implementation form, the challenge is reproducibly computed within the application. Reproducibly computing the challenge within the application reduces network bandwidth usage and avoid network delays associated with contacting the cloud service.

[0024] In a possible implementation form, the key signing key is generated during initialization of the computing apparatus. Generation of the key signing key during initialization provides a new key on each device boot.

[0025] In a possible implementation form, the key signing key is re-generated based on a security policy, and the local key attestation further includes an identifier of the key signing key used to sign the local key attestation. Rotation of the key signing key reduces the risks of key leakage or misuse.

[0026] In a possible implementation form, the key signing key is one of a symmetric key and an asymmetric key. Flexibility as to the key signing key type broadens the range of apparatus to which the disclosed key attestation processes may be applied.

[0027] In a possible implementation form, the cloud attestation further includes a hash of the application public key. A hash of the public key has the advantage of being smaller than the public key an is of fixed size.

[0028] According to a third aspect, the above and further aspects and advantages are obtained by a method for validating a cloud key attestation, the method includes: receiving a cloud key attestation, where the cloud key attestation is signed with a cloud attestation key and includes an application public key, a challenge, a secondary security domain identifier, an application identifier, a timestamp, and a cloud key certificate chain; verifying the cloud key attestation based at least in part on the cloud key certificate chain; accepting the application public key; and sending an application public key accepted indication.

[0029] These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which like references indicate like elements and:

[0031] Figure 1 illustrates a diagram of an exemplary computing apparatus and associated security ecosystem incorporating aspects of the disclosed embodiments.

[0032] Figure 2 illustrates a sequence diagram illustrating an exemplary provisioning process incorporating aspects of the disclosed embodiments.

[0033] Figure 3 illustrates a sequence diagram illustrating an exemplary two-step cross-security-domain key attestation method incorporating aspects of the disclosed embodiments.

[0034] Figure 4 illustrates a sequence diagram illustrating an exemplary key attestation verification method incorporating aspects of the disclosed embodiments.

[0035] DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

[0036] Figure 1 illustrates a diagram of an exemplary computing apparatus 102 and associated security ecosystem 100 configured to provide a two-step cross-security-domain cloud-based privacy-aware key attestation process incorporating aspects of the disclosed embodiments. The exemplary computing apparatus 102, also referred to herein as a device or consumer device, overcomes limitations of prior art apparatus by providing a two-step cross-security-domain key attestation process where the root security domain 104 is used to attest keys generated in a secondary security domain 106. This novel cross-security-domain key attestation scheme provides a scalable and efficient key attestation process without requiring the root security domain 104 to have prior knowledge of the secondary security domain 106 that was used to generate the application keys 122.

[0037] Referring to Figure 1, in one embodiment, the computing apparatus 102 is configured to provide a root security domain 104 provisioned with a device key 120 and a secondary security domain 106. In one embodiment, the computing apparatus 102 is configured to generate a key signing key; perform a local attestation; and perform a cloud attestation. The local attestation includes generating, within the secondary security domain 106, an application key pair 122. The application key pair 122 has an application public key 138 and an application private key 140.

[0038] The local attestation further includes sending, from the secondary security domain 106 to the root security domain 104, a local key attestation request 158. The local key attestation request includes the application public key 138, a challenge, and an application identifier.

[0039] The local attestation further includes generating, within the root security domain 104, a local key attestation. The local key attestation is signed with the key signing key 118 and includes the application public key 138, the challenge, a secondary security domain identifier, and the application identifier.

[0040] In one embodiment, the cloud attestation includes receiving, within the root security domain 104, a cloud key attestation request 154. The cloud key attestation request 154 includes the local key attestation.

[0041] The cloud attestation also includes validating, within the root security domain 104, the local key attestation based at least in part on the key signing key 118 and generate, within the root security domain 104, a device key attestation. The device key attestation is signed with the device key 120 and includes the application public key 138, the challenge, the secondary security domain identifier, the application identifier, and a timestamp.

[0042] The cloud attestation also includes sending 160 the device key attestation, from the root security domain 104 to a cloud key attestation service 114, and receive 162, within the root security domain 104, a cloud key attestation. The cloud key attestation is signed with a cloud attestation key 124 and includes the application public key 138, the challenge, the secondary security domain identifier, the application identifier, and the timestamp.

[0043] The computing apparatus 102 may be any suitable type of computing apparatus or consumer device such as a mobile phone, phablet, tablet, laptop, set-top box, IoT device, or other appropriate computing apparatus configured to generate cryptographic keys in multiple security domains and requiring key attestation for the generated cryptographic keys. The computing apparatus 102 includes  a processor 132 and a memory 134 configured to host and execute a software application 108 such as applications developed by third party service providers. Multiple security domains 104, 106 are included in the computing apparatus 102 where each security domain may provide specific security services to applications or other security domains hosted on the computing apparatus 102. Each security domain 104, 106 is protected by a combination of hardware, firmware, and / or software technologies that may be available on the computing apparatus 102.

[0044] As used herein the term security domain refers to a logical collection of hardware, firmware, and / or software that together provide security services from a single service provider or vendor. For example, in embodiments incorporating iOS based mobile devices, the Security Enclave Processor (SEP) together with the firmware and / or software that runs on a security co-processor within the mobile device, can be considered as a security domain that provides fundamental security services for the most security-critical tasks on the mobile device. The SEP based security domain, may be configured to manage factory provisioned keys and system keys, as well as some keys required by applications via well-defined interfaces. In these mobile devices, the SEP can be considered the root security domain.

[0045] In embodiments incorporating based devices, factory-provisioned keys are typically managed by the Keymaster Trusted Application (TA) hosted in the trusted execution environment (TEE) . The Keymaster, which manages system-wide secrets and provides interfaces for application developers to create their own keys can be considered the root security domain.

[0046] In certain embodiments, an independent security chip is integrated to offer improved protection of keys being stored in the security chip. These integrated security chips can be considered as a secondary security domain that manages application keys, and in certain embodiments may be referred to with terms such as a strongbox keymaster.

[0047] Any suitably secure collection of hardware, firmware, and / or software configured to provide a suitably secure computing environment may be adapted for use as either of the root security domain 104 or secondary security domain 106 in the exemplary computing apparatus 102.

[0048] A special security domain 104, referred to herein as the root security domain 104, may be included by the vendor of the computing apparatus 102 and configured to provide the most fundamental security services, such as encryption and attestation services. Examples of appropriate root security domains 104 include, but are not limited to, trusted applications (TA) provided by the device vendor and hosted in a trusted execution environment (TEE) , secure enclave processors (SEP) , and applets hosted in secure element (SE) chips.

[0049] During manufacturing of the computing apparatus 102, a device key 120 is provisioned 126 to the root security domain 104 by a factory provisioning server 110. The device key 120 is a root-of-trust asymmetric key pair which may be used to compute digital signatures within the root security domain 104. The public key portion of the device key 120 may be certified by a certificate authority (CA) 112 and the resulting set of certificates, also referred to as a certificate chain, may be provisioned to the root security domain 104 along with the device key 120.

[0050] As used herein the term certificate refers to a digital certificate, such as a X. 509 digital certificate, that employs a digital signature to bind a public key with associated information such as an identifier, a hostname, individual, or organization. The certificate is signed using a private key of the  entity issuing the certificate and presumably can be verified with its own certificate. A certificate chain is a set of one or more certificates that when taken together establish a chain of trust from a trusted root certificate authority to a top-level certificate such as an application specific certificate.

[0051] Provisioning of the device key 120 may be achieved using any appropriately secure key provisioning scheme. For example, in one embodiment the root security domain 104 may generate a random key within the root security domain 104 without any outside interaction, and generate a certificate signing request (CSR) for the internally generated device key. A factory provisioning server retrieves the CSR from the device, enrolls a certificate with a factory CA on behalf of the computing apparatus 102, and sends the resulting device certificate chain 142 back to the root security domain 104. Alternatively, the factory provisioning server may generate a device key and enroll certificates for the generated key prior to provisioning of a new computing apparatus. When a new device requires provisioning, the generated device key 120 and corresponding device certificate chain 142 are provisioned to the root security domain 104 via an apropriately secure channel.

[0052] A secondary security domain 106, which may be provided by the device vendor or a third party, hosts security services for applications 108 executing in a rich execution environment (REE) 136. These services may include secure services such as generating and / or importing keys and computing signatures using the generated and / or imported keys. Secondary security domains, such as the secondary security domain 106, may be installed, uninstalled, activated, and deactivated according to the needs of the end user, and / or security policies set by the device 102 vendor. It is generally not feasible to provision key material to a secondary security domain during manufacturing, unless the secondary security domain is provided by the device vendor and activated on the device by default. Secondary security domains may include, for example, trusted applications provided by a third-party service provider or partner of the vendor, software components without extra hardware protection, third party applets hosted in secure element (SE) chips, or other appropriate security domain implementations.

[0053] When a secondary security domain, such as the secondary security domain 106, is started, it may establish a secure communication channel 164 with the root security domain 104. The secure channel 164 may be any suitably secure communication channel such as a physical communication channel (i.e. dedicated hardware connection) , or logical communication channel (i.e. a channel secured via a channel key exchange) .

[0054] A cloud service 116, which may act as a verifier during the key attestation process, provides useful services, such as payment or other financial transactions, and may be operated by a third party. To make use of the cloud service 116, a corresponding application 108 and secondary security domain 106 may be installed on the computing apparatus 102. When a cloud service 116 exposes sensitive transactions, such as financial transactions, it will often require verification of key attestation information prior to performing transactions for the application 108.

[0055] An application 108, which acts an attester during key attestation, provides useful functions to end users by making use of the services provided by the cloud service 116 and the various security domains 104, 106 on the device 102. To secure transactions with the cloud service 116, the application 108 may generate an asymmetric application key pair 122, including an application public key 138 and an application private key 140, within the secondary security domain 106 and use these application keys 122 to sign transactions exchanged with the cloud service 116. In this scheme, the application 108 acts as an attester and requests key attestation services from the root security domain 104.

[0056] A cloud attestation server 114 is used to generate online key attestation information signed with a cloud attestation key that can be trusted by the cloud service 116. In certain embodiments, the cloud attestation server 114 may be operated by a vendor of the computing apparatus 102. The cloud attestation keys 124, used to sign the cloud attestation, are protected within the cloud attestation server 112 and certified by a trusted certificate authority 112, which may also be provided and operated by the device 102 vendor.

[0057] One or more certificate authorities 112, run by the device vendor, are used to issue certificates to device keys and cloud attestation keys. The one or more certificate authorities 112 are used to certify 128 device keys 120 and to certify 130 cloud attestation keys 124.

[0058] As used herein, the term “key attestation” refers to a cryptographically signed block of data, or attestation evidence, employed during a key attestation process. The key attestation binds a cryptographic key, also referred herein as a key, to verifiable information or attestation evidence pertaining to that key. Key attestation is used to prove the subject key, incorporated in the key attestation, is properly protected, such as by hardware backed security. Various forms of key attestation are used in the herein disclosed key attestation processes and, as will become apparent in the following discussion, are differentiated with names corresponding to their generation and use. For example, local key attestation is generated by the root security domain and signed with a key signing key, cloud key attestation is generated by a cloud service and signed with a cloud attestation key, and device key attestation is generated by the root security domain and is signed with a device key.

[0059] Initialization of the computing apparatus 102 occurs when the software environment, including any security domains, is restarted, such as after a power cycle, device boot, or re-boot. When the root security domain 104 initializes, it generates a key signing key 118 (KSK) , which may be either a symmetric key or an asymmetric key pair, and stores the KSK 118 in a secure memory region that can only be accessed by the root security domain 104. The KSK 118 may remain effective until the next initialization, or when desired, the KSK 118 may be rotated according to a suitable security policy associated with the computing apparatus 102. Rotation of the KSK 118 refers to re-generation of the KSK 118, i.e. generating a new KSK 118, and deprecating the old KSK 118. The root security domain 104 is started and initialized before any other security domains, such as the secondary security domain 106, are started.

[0060] Attestation of keys generated in a secondary security domain 106 is achieved in a two-step cross-security-domain process. An application, such as the application 108 executing in a REE 136, generates, within the secondary security domain 106, an application key pair 122, where the application key pair 122 includes an application public key 138 and an application private key 140. The application 108 sends a key generation request 152 to the secondary security domain 106 supplying a challenge, or challenge value, as one of the parameters. The secondary security domain 106 then generates a random application key pair 122 and securely stores the generated application key pair 122, such as within a memory that is not accessible from the REE 136.

[0061] In one embodiment, the challenge is obtained 156 from the third-party cloud service 116, which will check the challenge during verification. Alternatively, the challenge may be reproducibly computed locally by the application 108 using data and / or algorithms known to both the cloud service 116 and the application 108. The cloud service may then reproduce the challenge itself during verification. The purpose of including a challenge is primarily to ensure transactions between the application 108 (the  attester in this scenario) , and the cloud service 116 (the verifier in this scenario) are fresh, thereby preventing replay attacks.

[0062] When desired, including the challenge in the key generation request 152 may be used to indicate to the secondary security domain 106 that local attestation is required. Alternatively, the application 108 may explicitly request for attestation with the challenge after the application key pair 122 has been generated.

[0063] Upon generation of the application key pair, or receiving a local key attestation request, a local key attestation request 158 is sent from the secondary security domain 106 to the root security domain 104. The local key attestation request 158 includes the application public key 138, the challenge, and an application identifier. The application identifier uniquely identifies, to the cloud service 116, which application 108 requested the key attestation.

[0064] The root security domain 104, generates a local key attestation based on information received in the local key attestation request. The local key attestation includes the application public key 138, the challenge, and an application identifier received in the local key attestation request 158, along with an identifier corresponding to the secondary security domain 106. The secondary security domain identifier is added to the local key attestation by the root security domain and is determined by the root security domain based on the security domain 106 from which the local key attestation request 158 was received. The local key attestation is signed with the key signing key 118.

[0065] The local key attestation is returned to the application 108 via the secondary security domain 106 as a response to the key generation request 152. Alternatively, in embodiments where the local attestation begins with a local key attestation request, the local key attestation is returned in response to the local key attestation request.

[0066] In embodiments where the KSK 118 is rotated, such as based on a suitable security policy, the local key attestation further includes a random KSK identifier associated with the KSK 118 that was used to sign the local key attestation. The random KSK identifier allows the root security domain 104 to easily identify the KSK 118 upon which verification of the local key attestation signature should be based.

[0067] When an application, such as an application 108 executing within a rich execution environment 136, needs to access services provided by a cloud service 116, a cloud attestation process is performed to establish trust between the cloud service and the application keys 122. A cloud key attestation request 154 is sent by the application 108 and received within the root security domain 104. The cloud key attestation request includes the local key attestation prepared earlier during the local attestation process described above.

[0068] Upon receipt of the local key attestation, the root security domain validates the local key attestation based on the KSK 118. Signature validation of the local key attestation ensures integrity of the local key attestation information. Additional values included in the local key attestation may also be validated to ensure they include the expected values. For example, the application identifier may be checked against the application from which the local key attestation was received.

[0069] A device key attestation is generated within the root security domain 104 based on information extracted from the local key attestation. Information incorporated into the device key attestation includes the application public key 138, the challenge, the secondary security domain identifier,  and the application identifier. When desired, a timestamp may also be included in the device key attestation to help ensure freshness and prevent replay attacks. The device key attestation is signed with the factory provisioned device key 120, thereby allowing the device key attestation to be validated by cloud attestation service 114 based on the corresponding device certificate chain 142.

[0070] Cloud attestation proceeds by sending 160 the device key attestation from the root security domain 104 to the cloud attestation service 114 where it can be verified based on the device certificate chain 142. When desired, verification may be facilitated by sending the device certificate chain 142 to the cloud attestation service 114 together with, or incorporated into, the device key attestation. Alternatively, the device certificate chain may be downloaded separately to reduce network bandwidth and avoid duplicate data transmissions. Optionally, the device key attestation may be sent 160 via a secure communication channel, such as by using transport layer security (TLS) , or other logical communication channel.

[0071] Validation of the device key attestation is achieved by the cloud attestation service 114 based in part on the device certificate chain 142. The device certificate chain 142 is used to perform signature validation on the device key attestation, and when desired, may be checked to ensure none of the certificates in the device certificate chain 142 has been revoked or expired. In certain embodiments, the cloud attestation service 114 may perform additional verification checks against certain security policies. For example, the cloud attestation service 114 may require that the computing apparatus 102 identified by the device key attestation cannot send attestation requests too frequently, and / or require that an application identified by the application identifier included in the device key attestation cannot sent too many requests during a suitably short period of time.

[0072] The cloud attestation service 114 uses the timestamp included in the device key attestation, to ensure the request is fresh and not a replay. In one embodiment, the cloud attestation service 114 computes a nonce based on the application public key 138 and uses the computed nonce, in addition to the timestamp, to ensure freshness of the request. Freshness may be determined for example by using the timestamp to verify the request is recent enough, such as within the last five minutes, and that the nonce has not been seen recently, such as within the last five minutes. Use of the timestamp avoids the need to record all previously seen public keys or corresponding computed nonces.

[0073] Once validation of the device key attestation is complete, the cloud attestation service 114 generates a cloud key attestation that includes the application public key 138, the challenge, the secondary security domain identifier, the application identifier, and the timestamp. The cloud key attestation is signed with a certified cloud attestation key 124 hosted by the cloud attestation service 114. The cloud attestation service 114 returns 162 the signed cloud key attestation to the root security domain 104 of the computing apparatus 102 together with a cloud key certificate chain associated with the cloud attestation key 124. Optionally, network bandwidth may be reduced by omitting the cloud key certificate chain from the response 162, and instead providing the cloud key certificate chain via an alternate download path so that the cloud key certificate chain is downloaded only once per computing apparatus 102 per cloud authentication key 124.

[0074] The signed cloud key attestation, and optionally the cloud key certificate chain, are then returned to the application 108 by the root security domain 104.

[0075] When an application 108 requires services from a cloud service 116, key attestation 156 is performed to ensure the keys are properly protected in a hardware backed security domain. The application 108 forwards the cloud key attestation and optionally the associated cloud key certificate chain, to the cloud service for verification where the cloud service 116, which is acting as a verifier during key attestation 156, checks the signature of the cloud key attestation against the cloud key certificate chain, verifies that all certificates in the cloud key certificate chain have not expired or been revoked, and checks that critical values, such as the challenge, the application identifier, the security domain identifier, and the timestamp, are valid. When the cloud key attestation has been successfully verified, the cloud service 116 accepts the application public key 138 as valid for the requested transactions.

[0076] In certain embodiments, the cloud service 116 records the application public key 138 in a locally accessible database. Alternatively, the cloud service 116 may issue another set of certificates against the application public key 138 and allow the application 108 to use these newly issued certificates to authenticate further transactions.

[0077] It should be noted that because the cloud key attestation is signed by the cloud attestation key 124 and does not include any device identifiers, the herein disclosed two-step cross-security-domain key attestation scheme protects user privacy in a way similar to a privacy certificate authority. However, the cloud attestation server 114 is not a certificate authority, therefore it is much easier to dynamically scale the cloud attestation server 114 up and down to adapt to the actual needs of deployed devices. In practice, the cloud attestation key 124 may be protected by a cloud based key management service or a cloud based secure enclave. Optionally, the cloud attestation keys may be rotated frequently with short-lived certificates to reduce the risks of key leakage or misuse. Verification is most often a one-time process performed together with attestation; therefore, it is reasonable to assume that frequent rotation of the attestation keys will not adversely affect the applications and services they provide to end-users.

[0078] Figure 2 illustrates a sequence diagram illustrating an exemplary provisioning process 200 for a computing apparatus 202 and associated cloud services 204 incorporating aspects of the disclosed embodiments. The exemplary provisioning process is appropriate for use when provisioning a computing apparatus 202, such as the exemplary computing apparatus 102 described above and with respect to Figure 1. The exemplary provisioning process 200 may be beneficially employed when provisioning a computing apparatus or other appropriate consumer device with a root-of-trust device key, such as an asymmetric key pair.

[0079] The computing apparatus 202 may be any desired type of consumer device or other appropriate computing apparatus, such as the exemplary computing apparatus 102 described above, that includes a memory and a processor configured to execute software applications, such as the application 206, to provide useful services to an end user. Multiple security domains, such as the root security domain 210 and secondary security domain 208, are included in the computing apparatus 202 to provide security services to the application 206. As described above, each security domain 104, 106 is protected by a hardware backed security technology incorporated in the computing apparatus 202.

[0080] The root security domain 210 is included by the vendor of the computing apparatus 202 and is configured to provide the most fundamental security services, such as encryption and attestation services. Examples of appropriate root security domains 210 include, trusted applications (TA) provided by the device vendor and hosted in a trusted execution environment (TEE) , secure enclave processors (SEP) , and applets hosted in secure element (SE) chips.

[0081] A secondary security domain may be provided by the vendor or a third party and hosts security services for applications, such as the application 206, and include services such as generating and / or importing keys, computing signatures, and encrypting or decrypting data using the generated and / or imported keys. As discussed above, secondary security domains may be installed, uninstalled, activated, and deactivated according to the needs of the end user, and / or security policies set by the device or security domain vendor.

[0082] Similar to the computing apparatus 102 described above, the computing apparatus 202 is configured to execute an application 206 within a rich execution environment. The application 206 provides useful functions to end users and may rely on a cloud service 214, external to the computing apparatus 202, for certain operations or transactions.

[0083] Prior to performing sensitive transactions, such as financial transactions, the cloud service 214 should establish trust with the application 206 that is requesting those transactions. As will be discussed further below, establishment of this trust relationship is supported by a cloud attestation server 212 configured to provide cloud key attestation based on a pre-configured 218 cloud attestation key. Cloud key attestation assures the cloud service 214 that the application keys are protected within a hardware backed security domain.

[0084] During manufacture of the computing apparatus 202, a device key is securely provisioned 216 within the root security domain 210. The device key is a root-of-trust asymmetric key pair which may be used to compute digital signatures within the root security domain 210. The public key portion of the device key may be certified by a certificate authority and the resulting certificate chain may optionally be provisioned to the root security domain 210 along with the device key. As described in more detail above, the device key may be provisioned 216 using any appropriately secure method or process that securely provisions a device key, and when desired a corresponding device key certificate chain, within the root security domain 210.

[0085] Prior to cloud key attestation, a cloud attestation key is installed 218 in the cloud attestation service. The cloud attestation key is certified by a trusted certificate authority and when desired a corresponding cloud attestation key certificate chain may be generated to facilitate trust of the cloud attestation key.

[0086] Figure 3 illustrates a sequence diagram illustrating an exemplary two-step cross-security-domain key attestation method 300 adapted to provide key attestation for a computing apparatus 202 incorporating aspects of the disclosed embodiments. The exemplary key attestation method 300, overcomes limitations of prior art processes by providing cross-security-domain key attestation processes where the root security domain 210 is used to attest keys generated in a secondary security domain 208. This novel two-step cross-security-domain key attestation method 300 provides a scalable and efficient key attestation method without requiring the root security domain 210 to have prior knowledge of the secondary security domain 208.

[0087] When an application 206 accesses services from a cloud service 214, the cloud service 214 may require a cloud key attestation signed by a trusted cloud attestation service 212 to ensure keys used for the desired transactions are properly protected within a hardware backed security domain. In the exemplary computing apparatus 202, application keys are generated and protected within a secondary security domain 208. The secondary security domain 208 is not known to, or trusted by, any suitable  cloud attestation service, therefore a two-step cross security domain key attestation method 300 is used to generate a cloud key attestation that can be trusted by the cloud service 214.

[0088] Generation of cloud key attestation for keys generated and managed by the secondary security domain 208 begins with a local attestation step 302 configured to generate a local key attestation signed by the root security domain based on the key signing key generated 216 during device initialization. The local key attestation binds the application public key, that was generated by the secondary security domain 208, with an application identifier and any other desired information, such as a challenge, with the application public key. A cloud attestation step 304 then generates the cloud key attestation based on the local key attestation generated in the local attestation step 302.

[0089] In certain embodiments, freshness may be ensured by including a challenge in the key attestation. In one embodiment, the challenge is obtained by having the application 206 send a get challenge request 306 to the cloud service 214. In response to the get challenge request 306, the cloud service 214 generates a challenge and returns 308 the challenge to the application. Alternatively, the application 206 may reproducibly generate the challenge itself based on algorithms and / or data known to both the application 206 and the cloud service 214. The cloud service 214 will then reproducibly generate the same challenge when verifying the cloud key attestation.

[0090] When cloud key attestation is required, the application 206 sends 310 a request to the secondary security domain 208. In one embodiment, key attestation may be indicated by including a challenge in a generate keys request. Alternatively, the keys may be generated earlier, and the local attestation may be initiated by sending 310 a local key attestation request having the challenge as a parameter.

[0091] An application key pair is generated 312 within the secondary security domain 208 and stored in memory protected by hardware backed security. In certain embodiments, the application key pair is an asymmetric key pair including an application public key and an application private key.

[0092] A local key attestation request 314, including application public key, the challenge, and an application identifier is sent from the secondary security domain 208 to the root security domain 206. The root security domain 210 then generates 316 a local key attestation, where the local key attestation is signed by the key signing key and includes the application public key, the challenge, the application identifier, and a security domain identifier. The security domain identifier is added by the root security domain 210 and identifies the secondary security domain 208 from which the local key attestation request was received. The local key attestation is signed within the root security domain 210 with the key signing key, and is returned 320 to the application via 318 the secondary security domain.

[0093] The key signing key may be either a symmetric key or an asymmetric key pair, and is used by the root security domain 210 to sign local key attestation. The key signing key is generated during initialization of the computing apparatus 202 and is stored in a secure memory region accessible only by the root security domain 210. In certain embodiments the key signing key may remain effective until the next initialization. Alternatively, the key signing key may be rotated according to a suitable security policy associated with the computing apparatus 202.

[0094] When cloud key attestation is required by the cloud service 214, the application 206 sends 322 an attest key request to the root security domain 210 and provides the local key attestation as a  parameter. Validation 324 of the local key attestation is performed by the root security domain 210 based at least in part on the signature and the key signing key used when generating the local key attestation. When validation 324 of the local key attestation is successful, the root security domain 210 proceeds to generate 326 a device key attestation. The device key attestation is signed with the device key which was provisioned to the root security domain 210 during device 202 manufacture.

[0095] The root security domain 210 sends 328 the device key attestation to a cloud attestation service 212 for generation of cloud key attestation. When desired, the factory provisioned device key certificate chain may be sent, along with the device key attestation, to the cloud attestation service 214.

[0096] The cloud attestation service then validates 330 the device key attestation. In one embodiment, validation includes computation of a nonce based on the application public key. The nonce may for example be a hash of the application public key. A nonce based on a hash of the application public key has the advantage that the nonce is smaller than the public key and has a fixed length. The timestamp and computed nonce may be used by the cloud attestation service 214 to ensure the device key attestation is fresh and not a replay. Freshness may be determined, for example, by ensuring the timestamp is recent enough, such as within the last five minutes, and that the nonce has not been seen recently, such as not within the last five minutes. Use of the timestamp avoids the need to maintain a record of all previously seen public keys.

[0097] The cloud attestation service 214 performs signature verification on the device key attestation using the public portion of the device key as certified by the device key certificate chain. In addition to signature verification, the cloud attestation service 214 verifies that all certificates in the device key certificate chain have not expired or been revoked. Additional checks against security policies may also be performed by the cloud attestation service 214. For example, the cloud attestation service 214 may require that a device, identified by the device key, cannot sent attestation requests too frequently, or require that an application, as identified by the application identifier incorporated in the device key attestation, cannot send too many requests during a short period of time.

[0098] When validation 330 of the device key attestation is successful, the cloud attestation service generates 332 a cloud key attestation, where the cloud key attestation includes the application public key, the challenge, the secondary security domain identifier, the application identifier, and the timestamp. The cloud key attestation is signed by a certified cloud attestation key hosted by the cloud attestation service 214.

[0099] The cloud attestation service 214 returns 334 the signed cloud key attestation to the device 202 where it is received by the root security domain 210. Optionally, the cloud attestation service may return a cloud attestation key certificate chain together with the cloud key attestation. The cloud attestation key certificate chain includes one of more certificates that establish trust of the cloud attestation key. Alternatively, the cloud attestation service 214 may choose to omit the cloud attestation key certificate chain from the response and provide a separate download location for these certificates. Use of a separate download location allows the cloud attestation key certificate chain to be downloaded only once per cloud attestation service, thereby reducing network bandwidth usage.

[0100] Finaly, the cloud key attestation is returned 336 to the application 206. Optionally, the cloud attestation key certificate chain may be returned together with or incorporated into the cloud key attestation.

[0101] Figure 4 illustrates a sequence diagram illustrating an exemplary key attestation verification method 400 configured to verify a cross-security-domain cloud key attestation incorporating aspects of the disclosed embodiments. The exemplary method 400 is appropriate for use when verifying a cloud key attestation, such as the cloud key attestation generated by the exemplary method 300 described above and with reference to Figure 3.

[0102] When interacting with a cloud service 214, an application 206 needs to obtain a cloud key attestation to ensure the keys being used are properly protected within a hardware backed security domain. A suitable cloud key attestation may be obtained using any suitable method, such as the exemplary method 300 described above. The application 206 sends 402 the cloud key attestation, and when desired, the cloud attestation key certificate chain, to the cloud service 214 for verification. In certain embodiments it may be advantageous to provide the cloud attestation key certificate chain to the cloud service 214 through an alternate channel, such as via a separate download location, rather than including it when sending 402 the cloud key attestation.

[0103] The cloud service, which acts as a verifier in the exemplary method 400, validates 404 a signature of the cloud key attestation against the cloud attestation key certificate chain and verifies all certificates in the cloud attestation key certificate chain have not expired or been revoked. Critical values in the cloud key attestation, such as the challenge, application identifier, secondary security domain identifier, and the timestamp, are checked to ensure they are as expected. When all checks are successful, the cloud service 214 accepts 406 the application public key as a valid key for the application 206 to perform further transactions with the cloud service 214. The cloud service 214 may record the application public key in its database, or when desired, issue a new set of certificates against the application public key so the application 206 may use the new set of certificates to authenticate further transactions.

[0104] The cloud service 214 completes the exemplary key attestation verification method 400 by returning 408 to the applications 206, an indication that the application public key has been accepted by the cloud service 214.

[0105] Thus, while there have been shown, described, and pointed out, fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that various omissions, substitutions and changes in the form and details of devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Further, it is expressly intended that all combinations of those elements, which perform substantially the same function in substantially the same way to achieve the same results, are within the scope of the invention. Moreover, it should be recognized that structures and / or elements shown and / or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims

1.A computing apparatus (102) configured to provide a root security domain (104) provisioned with a device key (120) , and a secondary security domain (106) , the computing apparatus (102) configured to:generate a key signing key;perform a local attestation; andperform a cloud attestation;wherein the local attestation comprises:generating, within the secondary security domain (106) , an application key pair (122) , wherein the application key pair (122) comprises an application public key (138) and an application private key (140) ;sending, from the secondary security domain (106) to the root security domain (104) , a local key attestation request (158) , wherein the local key attestation request comprises the application public key (138) , a challenge, and an application identifier;generating, within the root security domain (104) , a local key attestation, wherein the local key attestation is signed with the key signing key (118) and comprises the application public key (138) , the challenge, a secondary security domain identifier, and the application identifier, andwherein the cloud attestation comprises:receiving, within the root security domain (104) , a cloud key attestation request (154) , wherein the cloud key attestation request (154) comprises the local key attestation;validating, within the root security domain (104) , the local key attestation based at least in part on the key signing key (118) ; andgenerating, within the root security domain (104) , a device key attestation, wherein the device key attestation is signed with the device key (120) and comprises the application public key (138) , the challenge, the secondary security domain identifier, the application identifier, and a timestamp;sending (160) the device key attestation, from the root security domain (104) to a cloud key attestation service (114) , andreceiving (162) , within the root security domain (104) , a cloud key attestation, wherein the cloud key attestation is signed with a cloud attestation key (124) and comprises the application public key (138) , the challenge, the secondary security domain identifier, the application identifier, and the timestamp.2.The computing apparatus (102) according to claim 1 wherein the computing apparatus (102) further comprises a rich execution environment (136) configured to execute an application (108) , and the local attestation further comprises:receiving the challenge within the application (108) ; andsending the challenge from the application (108) to the secondary security domain (106) .3.The computing apparatus (102) according to claim 2 wherein the challenge is reproducibly computed within the application (108) .4.The computing apparatus (102) according to any one of the previous claims wherein the key signing key (118) is generated during initialization of the computing apparatus (102) .5.The computing apparatus (102) according to any one of the previous claims wherein the key signing key (118) is re-generated based on a security policy, and the local key attestation further comprises an identifier of the key signing key (118) used to sign the local key attestation.6.The computing apparatus (102) according to any one of the previous claims wherein the local key attestation request is sent over a secure communication channel (164) , and wherein the secure communication channel is one of a physical communication channel, and a logical communication channel.7.The computing apparatus (102) according to any one of the previous claims wherein the secure communication channel (164) is established during one or more of an initialization of the second security domain (106) , and an availability of the second security domain (106) .8.A method (300) for cross-security-domain key attestation in a computing apparatus, wherein the computing apparatus comprises a root security domain provisioned with a device key, and a secondary security domain, the method (300) comprising:generating (338) a key signing key;performing a local attestation (302) ; andperforming a cloud attestation (304) ,wherein the local attestation (302) comprises:generating (312) , within the secondary security domain, an application key pair, wherein the application key pair comprises an application public key and an application private key;sending (314) , from the secondary security domain to the root security domain, a local key attestation request, wherein the local key attestation request comprises the application public key, a challenge, and an application identifier;generating (316) , within the root security domain, a local key attestation, wherein the local key attestation is signed with the key signing key and comprises the application public key, the challenge, a secondary security domain identifier, and the application identifier, andwherein the cloud attestation (304) comprises:receiving (322) , within the root security domain, a cloud key attestation request wherein the cloud key attestation request comprises the local key attestation;validating (324) , within the root security domain, the local key attestation based at least in part on the key signing key;generating (326) , within the root security domain, a device key attestation, wherein the device key attestation is signed with the device key and comprises the application public key, the challenge, the application identifier, the secondary security domain identifier, and a timestamp;sending (328) , from the root security domain to a cloud key attestation service (212) , the device key attestation, andreceiving (334) , within the root security domain, a cloud key attestation, wherein the cloud key attestation is signed with a cloud attestation key and comprises the application public key, the challenge, the secondary security domain identifier, the application identifier, and the timestamp; andreceiving (336) , within the application, the cloud key attestation.9.The method (300) according to claim 8, wherein the computing apparatus further comprises an application configured to execute within a rich execution environment, and the local attestation (302) further comprises:receiving (308) the challenge within the application; andsending (310) the challenge from the application to the secondary security domain.10.The method (300) according to claim 9, wherein the challenge is reproducibly computed within the application.11.The method (300) according to any one of claims 8 through 10, wherein the key signing key is generated (338) during initialization of the computing apparatus.12.The method (300) according to any one of claims 8 through 11 wherein the key signing key is re-generated based on a security policy, and the local key attestation further comprises an identifier of the key signing key used to sign the local key attestation.13.The method (300) according to any one of claims 8 through 12, wherein the key signing key is one of a symmetric key and an asymmetric key.14.The method (300) according to any one of claims 8 through 14, wherein the cloud attestation further comprises a hash of the application public key.15.A method (400) for validating a cloud key attestation, the method (400) comprising:receiving (402) a cloud key attestation, wherein the cloud key attestation is signed with a cloud attestation key and comprises an application public key, a challenge, a secondary security domain identifier, an application identifier, a timestamp, and a cloud key certificate chain;verifying (404) the cloud key attestation based at least in part on the cloud key certificate chain;accepting (406) the application public key; andsending (408) an application public key accepted indication.

Images