WO2022171263A1

WO2022171263A1 - Key attestation methods, computing devices having key attestation abilities, and their provisioning

Info

Publication number: WO2022171263A1
Application number: PCT/EP2021/052999
Authority: WO
Inventors: Qiming Li
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-02-09
Filing date: 2021-02-09
Publication date: 2022-08-18

Abstract

There is provided a computing device (102, 202, 304, 400) having a device-specific key attestation ability. The computing device includes a rich execution environment, REE, (104), a secure execution environment, SEE, (106), a persistent memory (108), a shared device key (110) and a corresponding digital certificate chain (112), a trusted application (114, 506) and a device-specific key material (116). The persistent memory includes a secure storage portion and stored in the secure storage portion of the persistent memory. The shared device key and the corresponding digital certificate chain are being common to a plurality of computing devices. The trusted application is operated in the SEE to generate keys and perform key management and cryptographic operations. The device-specific key material for use by the trusted application in providing application-specific attestation for a plurality of software applications performs secure transactions and that operate in the REE.

Description

KEY ATTESTATION METHODS, COMPUTING DEVICES HAVING KEY ATTESTATION ABILITIES, AND THEIR PROVISIONING

TECHNICAL FIELD

The disclosure relates to an application-specific key attestation method performed on a computing device, a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability, a computing device having a device- specific key-attestation ability, a computing device having an application-specific key- attestation ability, and a method of verifying a key attestation generated for a user of a secure application installed on a computing device.

BACKGROUND

A key attestation solution is a security mechanism provided by a device vendor to allow an application running on a computing device manufactured by the vendor to attest to a third party, typically a cloud service or a remote application, that an asymmetric key pair has been correctly generated on the device according to some specifications given by the service provider, and that the key pair is well-protected by a secure execution environment on the computing device.

Typically, a key attestation solution can be described in terms of three phases, namely, the provisioning phase, the attestation phase, and the verification phase, as briefly described below.

Provisioning Phase

Provisioning refers to a specific step during the manufacturing process of the computing devices, where key materials are either sent to or generated within, the secure execution environment of the computing devices. Key materials include cryptographic keys and other corresponding data such as digital certificates. Multiple keys, both symmetric and asymmetric, can be provisioned as needed, and if an asymmetric key pair is generated on the device, its public key part may be required to be exported from the device. Attestation Phase

Attestation takes place when an application needs to prove to a remote party that a key has been generated in the secure execution environment of the computing device according to some specifications. For example, after a user has logged in when using a payment application, the application may need to generate an asymmetric key pair used to sign future payment transactions. In this case, the application may request the computing device to generate a signing key pair in its secure execution environment and produce attestation claims, which can then be sent to a payment web service hosted by the payment service provider.

Verification Phase

The verification phase refers to the process a remote party performs to validate attestation claims generated from a computing device. Using the above payment application example, upon receiving the attestation claims, the service provider would then validate the attestation claims to make sure that these claims were indeed generated inside a secure execution environment of a legitimate computing device and that they correctly indicate that the key has been generated according to the specifications required by the service. After the attestation claims have been validated, the service provider would mark this signing key as a valid transaction signing key for the current login user, which can later be used to sign transaction data.

A secure execution environment is provided in user devices to perform among other things critical cryptographic tasks with cryptographic key materials. Such an execution environment is often protected by underlying hardware and an operating system. For example, a mobile payment application running on an Android device typically generates a key after user authentication is performed with a user name and a password. Key generation is managed by a trusted application (TA) in a Trusted Execution Environment based on a known technology. The generated key is later used to sign payment transaction data when payments are made. The generated key may also be managed by a secure element (SE) on the same circuit board of the Android device but external to a System on Chip (SoC) of the Android device. A payment service provider needs to ensure that a signing key is protected by a piece of hardware that meets specified requirements. An assurance that the signing key is protected in this way is referred to as a key attestation. Currently, such key attestation functions are provided by device vendors in the form of Application Programming Interfaces (APIs) or software libraries for developers so that it is usable by any third-party service provider that requires it. Currently, such a feature is found in Androidbased devices, where such an API is defined by Google and implemented by device vendors. A similar feature is also provided Microsoft® Windows Server products, where such attestation is provided by a TPM, which is an independent piece of tamper-proof hardware integrated into the main board.

Key Attestation was introduced as a new feature for Keymaster 2.0 API in Android 7.0. For a mobile device to be compliant, device vendors are required to provision device keys and device certificate chains issued by Google CA into the secure hardware of the device during manufacturing time. An application running on such a device can request a key pair to be generated by the secure Keymaster TA and an attestation of the key pair. When the Keymaster TA receives such an attestation request, it creates an X.509 (RFC 5280) attestation certificate from the public portion of the generated key pair, signs it using the provisioned device key, and outputs the entire certificate chain containing the signed attestation certificate and the provisioned device certificate chain. In this way, the service provider knows that the application key is generated in a secure environment where the device keys and certificates are provisioned, assuming that the device vendor is trusted and follows secure manufacturing processes.

In some known approaches, generation of a new signing key pair and attestation of the new signing key pair typically happens after user authentication has been completed using other credentials such as a username and a password. During user authentication, a cloud service may issue a challenge nonce (a number used once) to an application on a client device that instructs a secure application to generate a new key pair and attest the new key pair. The secure application generates an attestation certificate and the challenge nonce is included in the attestation certificate as an extension. The inclusion of the challenge nonce shows that the key attestation is new and not a repeated version of a previous attestation. After that, the attestation certificate chain from the device is uploaded to the cloud service and its validity is checked. The cloud service may respond with a new certificate, issued by a Certification Authority (CA), which will then be used to sign transactions later when required by the application on the client device.

In Android Key Attestation, the new key pair can reside in the Keymaster trusted application, or an isolated tamper-proof security co-processor called StrongBox, if requested by the application and available on the device. To protect the privacy of the user, Google mandates that a device key must be provisioned to at least 10,000 devices. Since otherwise, two colluding service providers can leam that the same user is accessing their service using the same device by simply checking the public key field of the device certificates they receive.

The first disadvantage of the Android key attestation scheme is that it does not satisfy the requirements of some service providers, where they require a unique attestation key for each device. A second disadvantage of the Android Key Attestation scheme is that it does not allow individual revocation. If a device is compromised and its device key leaked, revoking that device key would affect many other users that share the same device key with the compromised device.

As noted above some applications, a service provider may require a unique attestation key for each device (an approach known as Application Specific Key Attestation). For example, for the WeChat fingerprint payment feature to be usable on an Android device, the service provider (Tencent) requires that the device vendor provides a unique key pair on each Android device during manufacturing (in addition to the device key shared by at least 10,000 devices), and a public portion of the unique key pair is validated either through key attestation or by means of a trusted database. Clearly, the device key and certificate chain issued in the known Android approach are insufficient to meet this requirement. To protect user privacy, the unique key pair is only usable by the WeChat fingerprint payment service.

In another approach, known as TPM Key Attestation, a dedicated tamper-proof co processor is integrated into an endpoint device. A Trusted Platform Module (TPM) chip is provisioned during manufacturing with a unique Endorsement Key (EK), which is an asymmetric key pair. An endorsement certificate may or may not be present in the Trusted Platform Module (TPM) chip. In a known use case of the Trusted Platform Module (TPM) chip, an Attestation Identity Key (AIK) is created and signed by an Endorsement key (EK). The Endorsement Key (EK) is then used to sign a device boot state, such as a hash value of a boot software image, so that a remote party can be assured that the endpoint device is running authorized software. This process is referred to as TMP remote attestation, which is different from key attestation.

Microsoft provides a TPM key attestation feature in their server products, which is similar to Android key attestation. When requested, a TMP chip generates a new RSA key pair and signs a certificate request that contains the public portion of the key pair with the EK. The signed certificate request can then be sent to an enterprise CA, which would issue a new certificate to the entity for the public key if the certificate request is validated successfully based on one of the accepted trust models. Note that the outcome of Microsoft’s TMP key attestation is a certificate request instead of a normal X.509 certificate as in Android key attestation, since this feature is intended to be used only for certificate enrollment in enterprise applications. Android key attestation, on the other hand, does not require the cloud service to issue another certificate based on the attestation result. An implication of the difference is that, in enterprise applications, user privacy is not a strong concern during certificate enrollment, and the server would have to identify and authenticate the user regardless of the enrollment method. As a result, there is no mechanism for privacy protection in TMP key attestation since it is not necessary in the intended use cases. It is observed that the TMP key attestation is similar to the application specific key attestation in many ways. However, the hardware security modules and the endpoint devices are manufactured independently, and each endpoint device can only be deployed in one specific enterprise network at a time. In other words, it does not scale to multiple application or service providers. The TMP key attestation scheme is also not privacy preserving, since it is intended for certificate enrollment in enterprise applications where users have to be identified and authenticated during the process. Colluding service providers are also not a concern since there is only one service provider in these use cases.

In the known approach, the application-specific key attestation is in any data format chosen by the service provider, and the attestation result is only used by that specific service provider. The application-specific attestation is not scalable to multiple applications or service providers, since each new service that requires a unique device key would require a new key pair to be provisioned during manufacturing. The approach also introduces a very high load on the vendor’s Certification Authorities (CA), especially when we consider provisioning unique keys and certificates to not only mobile but also IoT devices.

Therefore, there arises a need to address the aforementioned technical drawbacks in existing systems or technologies in key attestation on computing devices.

SUMMARY

It is an object of the disclosure to provide an application-specific key attestation method performed on a computing device and a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability while avoiding one or more disadvantages of prior art approaches.

This object is achieved by the features of the independent claims. Further implementations are apparent from the dependent claims, the description, and the figures.

The disclosure provides an application-specific key attestation method performed on a computing device and a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability, a method of verifying a key attestation generated for a user of a secure application installed on the computing device, a computing device having the device-specific key-attestation ability and a computing device having application-specific key-attestation ability.

According to a first aspect, there is provided an application-specific key attestation method performed on a computing device, the computing device having: a rich execution environment, REE; a secure execution environment, SEE; a first software application to perform secure transactions and that operates in the rich execution environment; a trusted application to generate keys and perform key management and cryptographic operations that operates in the secure execution environment; a secure persistent storage that is only accessible by the trusted application in the secure execution environment; a shared device key and a corresponding digital certificate chain, the shared device key being common to a plurality of other computing devices, and a plurality of device specific supplementary attestation keys, SAK, generated from a secret seed, all stored in the secure persistent storage; the key attestation method comprising: the first software application providing an attestation challenge, C, to the trusted application and requesting the trusted application to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK; the trusted application generating attestation data, A, which includes at least: a public part of the transaction key pair, TK; a key description, KD, of a key, K, the key, K, being one of the device-specific supplementary attestation keys, SAK, the key description, KD, including parameters, other than the secret seed, to generate the key, K, and when the key, K, is an asymmetric key pair, the public portion, Kp, of the key, K; the trusted application signing the attestation challenge, C, with the device- specific supplementary attestation keys, SAK, to produce a signature, S, the signature, S and the key description, KD, being included in the attestation data A; the trusted application also signing the attestation with the shared device key; and the trusted application sending the signed attestation to the first software application, together with the corresponding digital certificate chain.

The advantage of the application-specific key attestation method is that the method can support a large number of user devices. The application-specific key attestation method supports multiple applications and services at the same time on each computing device without new keys. The application-specific key attestation method minimizes the load on the device vendor’s Certification Authority, CA, even in the event that a large number of devices are provisioned. The application-specific supplementary attestation keys, SAK, are unique to each computing device. The provision of unique supplementary attestation keys, SAK, enable different keys to be used for different applications, enabling an application/service provider to identify uniquely a specific device. The attestation approaches according to the disclosure are privacy preserving in that different application/service providers do not get to see the same attestation keys, and so unscrupulous service providers cannot link activities with different applications to a common device. Provisioned keys can be revoked for any individual device without affecting other devices. The attestation approach of the present disclosure is also scalable in that it supports multiple applications and services at the same time on each device without the need to provision new keys after manufacturing.

According to a second aspect, there is provided a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability, the computing device having: a rich execution environment, REE; a secure execution environment, SEE; and persistent memory that includes a secure storage portion; the method comprising: storing in the secure storage portion of the persistent memory a shared device key and a corresponding digital certificate chain, the shared device key and the corresponding digital certificate chain being common to each of a plurality of computing devices; storing in the secure storage portion of the persistent memory a trusted application to operate in the secure execution environment to generate keys and perform key management and cryptographic operations; and storing in the secure storage portion of the persistent memory device-specific key material for use by the trusted application in providing application-specific key- attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment.

The advantage of the application-specific key attestation method is that the method can support a large number of user devices. The application-specific key attestation method supports multiple applications and services at the same time on each computing device without new keys. The application-specific key attestation method minimizes the load on the device vendor’s Certification Authority, CA, even in the event that a large number of devices are provisioned. The application-specific supplementary attestation keys, SAK, are unique to each computing device. The provision of unique supplementary attestation keys, SAK, enables different keys to be used for different applications, enabling an application/service provider to identify uniquely a specific device. The attestation approaches according to the disclosure are privacy preserving in that different application/service providers do not get to see the same attestation keys, and so unscrupulous service providers cannot link activities with different applications to a common device. Provisioned keys can be revoked for any individual device without affecting other devices. The attestation approach of the present disclosure is also scalable in that it supports multiple applications and services at the same time on each device without the need to provision new keys after manufacturing.

According to a third aspect, there is provided a computing device having a device-specific key-attestation ability, the computing device having: a rich execution environment, REE; a secure execution environment, SEE; persistent memory that includes a secure storage portion; and stored in the secure storage portion of the persistent memory: a shared device key and a corresponding digital certificate chain, the shared device key and the corresponding digital certificate chain being common to each of a plurality of computing devices; a trusted application to operate in the secure execution environment, SEE, to generate keys and perform key management and cryptographic operations; and device-specific key material for use by the trusted application in providing application- specific attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE.

According to a fourth aspect, there is provided a computing device having application- specific key-attestation ability, the computing device having: a rich execution environment, REE,; a secure execution environment, SEE,; a first software application to perform secure transactions and that operates in the rich execution environment; a trusted application to generate keys and perform key management and cryptographic operations that operates in the secure execution environment, SEE,; a secure persistent storage that is only accessible by the trusted application in the secure execution environment; a shared device key and a corresponding digital certificate chain, the shared device key being common to a plurality of other computing devices, and a plurality of device-specific supplementary attestation keys, S AK, generated from a secret seed, all stored in the secure persistent storage; and being configured to perform a key attestation method in which: the first software application provides an attestation challenge, C, to the trusted application and requests the trusted application to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK; the trusted application generates attestation data, A, which includes at least: a public part of the transaction key pair, TK; a key description, KD, of a key, K, K being one of the device-specific supplementary attestation keys, SAK, the key description, KD, including parameters, other than the secret seed, to generate K, and when K is an asymmetric key pair, a public portion, Kp, of K; the trusted application signs the attestation challenge, C, with the device-specific supplementary attestation key, K, to produce a signature, S, the signature, S, and the key description, KD, being included in the attestation data A; the trusted application also signs the attestation with the shared device key; and the trusted application sends the signed attestation to the first software application, together with the corresponding digital certificate chain.

Advantages of the computing device having such an application-specific key attestation ability are that it supports multiple applications and services at the same time on each computing device without the subsequent addition of extra keys. The application-specific key attestation approach minimizes the load on the device vendor’s Certification Authority, CA, even in the event that a large number of devices are provisioned. The application-specific supplementary attestation keys, SAK, are unique to each computing device. The provision of unique supplementary attestation keys, SAK, enables different keys to be used for different applications, enabling an application/service provider to identify uniquely a specific device. The attestation approaches according to the disclosure are privacy preserving in that different applicati on/service providers do not get to see the same attestation keys, and so unscrupulous service providers cannot link activities with different applications to a common device. Provisioned keys can be revoked for any individual device without affecting other devices. The attestation approach of the present disclosure is also scalable in that it supports multiple applications and services at the same time on each device without the need to provision new keys after manufacturing.

According to a fifth aspect, there is provided a method of verifying a key attestation, A, generated for a user of a secure application installed on a computing device, the key attestation A being for an asymmetric application-specific transaction key pair for the secure application, the method being performed by an entity, and the method comprising: i) receiving at the entity a key attestation A that contains: a data part that includes a public key of the transaction key pair, an attestation challenge, C, a key, K, the key, K, being one of a plurality of device-specific supplementary attestation keys, SAK, from the computing device, a signature, S, computed from the challenge, C, the attestation challenge, C, being signed by key, K, a key description, KD, for key, K, the key description, KD, including parameters to generate K and, when K is an asymmetric key pair, a public portion, Kp, of K; a signature part that contains a digital signature, the digital signature having been computed in respect of the data part and a private portion of a shared device key; a device certificate chain part containing a shared device certificate or shared device certificate chain or part thereof ; and subsequently ii) checking if the signature part can be verified using the data part and a public key of the shared device key; iii) if the public key, Kp, of K is included in the key description, KD, checking if the signature, S, can be verified by the public key, Kp; iv) checking if the certificate chain part is a valid chain; and thereafter v) checking with an external validation service the validity of the key description, KD. The key attestation, A, allows application providers and service provider to uniquely identify a specific computing device in a group of computing devices as the key K is unique for each application installed in the computing device.

Technical problems in the prior art are resolved, where the technical problems include minimizing the load on vendor Certification Authority (CA), privacy preservation, individual device identification, individual revocation and supporting multiple applications and services.

Therefore, in contradistinction to the prior art, according to the method and the computing device, of performing a key attestation on the computing device, of the disclosure, provides a unique attestation key for each device and allows individual revocation. The method and the computing device according to the disclosure can improve preservation of user privacy when combining application providers or service providers for some specific tasks. In addition, the method and the computing device may be fully backward compatible with known approaches. Service providers who need one or more unique keys on each devices may need to make only minor modifications to their existing approaches to adapt to the approach of the present disclosure.

These and other aspects of the disclosure will be apparent from the implementations described below.

BRIEF DESCRIPTION OF DRAWINGS

Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of a computing device having a device-specific key attestation ability in accordance with an implementation of the disclosure;

FIG. 2 is a block diagram of a computing device having application-specific key attestation ability in accordance with an implementation of the disclosure;

FIG. 3 is a schematic diagram of a computing device with a key attestation ability in accordance with an implementation of the disclosure, and various ancillary elements that interact with the computing device;

FIG. 4 is an exemplary block diagram that illustrates a computing device having a device- specific key-attestation ability and an application-specific key attestation ability in accordance with an implementation of the disclosure;

FIG. 5 is an interaction diagram of a method of provisioning a computing device with a key attestation ability in accordance with an implementation of the disclosure; FIG. 6 is a flow diagram that illustrates an application-specific key attestation method performed on a computing device in accordance with an implementation of the disclosure.

FIG. 7 is a flow diagram that illustrates a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability in accordance with an implementation of the disclosure; and

FIG. 8 is a flow diagram that illustrates a method of verifying a key attestation, A, generated for a user of a secure application installed on a computing device in accordance with an implementation of the disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

Implementations of the disclosure provide an application-specific key attestation method performed on a computing device and a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability. Implementations of the disclosure provide a computing device having a device-specific key-attestation ability and an application-specific key-attestation ability. Moreover, the disclosure also provides a method of performing key attestation.

To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

Terms such as "a first", "a second", "a third", and "a fourth" (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood that the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms "include" and "have" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

An attestation scheme according to the disclosure can be considered to have three phases, namely, provisioning, attestation, and validation. The provisioning phase happens during device manufacture, where key materials are provisioned into one or more security environments (e.g. keystores) of the devices. The attestation phase occurs when an application sends a request to a secure environment (e.g. keystore) to generate a new key pair and to attest the new key pair. The verification phase refers to a verification of an attestation certificate, performed by an external party, to determine the validity of the attestation.

FIG. 1 is a block diagram of a computing device 102 having a device-specific key attestation ability in accordance with an implementation of the disclosure. The computing device 102 includes a rich execution environment, REE, 104, a secure execution environment, SEE, 106, a persistent memory 108, a shared device key 110 and a corresponding digital certificate chain 112, a trusted application 114, and device-specific key material 116. The persistent memory 108 includes a secure storage portion, in which are stored: the shared device key 110 and the corresponding digital certificate chain 112 which are common to each of a plurality of computing devices; the trusted application 114 to operate in the secure execution environment, SEE, 106 to generate keys and perform key management and cryptographic operations; and the device-specific key material 116 for use by the trusted application 114 in providing application-specific attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE, 104.

The application-specific supplementary attestation keys, SAK, are unique to each computing device. The provision of unique supplementary attestation keys, SAK, enables different keys to be used for different applications to prevent linking of the keys. Individual revocation is provided to the service providers.

The computing device 102, without limitation, may be selected from a smart phone, a tablet, a laptop computer, a desktop computer, a smart TV, or any consumer devices that allow multiple applications from different vendors. The computing device 102 includes keys and certificates. The shared device key 110 and the corresponding digital certificate chain 112 are provisioned to the plurality of computing devices (M) to prevent linking between the plurality of computing devices (M).

The computing device 102 may further comprise a plurality of software applications, that operate in the rich execution environment, REE, 104, to perform secure transactions. The device-specific key material 116 may include a device-specific random seed for the generation of a plurality of device-specific attestation keys.

The device-specific key material 116 may include a plurality of device-specific supplementary attestation keys, SAK, generated from a device-specific random seed.

The plurality of device-specific supplementary attestation keys, SAK, may include multiple asymmetric key pairs.

The computing device 102 may include a Bloom filter value in a device certificate, the Bloom filter value having been computed from public keys of the plurality of devices that share the shared device key 110.

FIG. 2 is a block diagram of a computing device 202 having application-specific key- attestation ability in accordance with an implementation of the disclosure. The computing device 202 includes a rich execution environment, REE, 104, a secure execution environment, SEE, 106, a first software application 208, a trusted application 114, a secure persistent storage 212, a shared device key 110 and a corresponding digital certificate chain 112, and a plurality of device-specific supplementary attestation keys, SAK, generated from a secret seed 115. The first software application 208 operates in the rich execution environment, REE, 104, and performs secure transactions. The trusted application 114 operates in the secure execution environment, SEE, 106, generates keys, and performs key management and cryptographic operations. The secure persistent storage 212 is only accessible by the trusted application 114 in the secure execution environment 106. The shared device key 110 is common to a plurality of other computing devices. The shared device key 110 and the corresponding digital certificate chain 112, the shared device key 110, and the plurality of device-specific supplementary attestation keys, SAK, are stored in the secure persistent storage 212. The computing device 202 is configured to perform a key attestation method in which the first software application 208 provides an attestation challenge, C, to the trusted application 114 and requests the trusted application 114 to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK. The trusted application 114 generates attestation data, A. The attestation data, A, includes at least the public part of the transaction key pair, TK, and a key description, KD, of a key, K. The key description, KD, of the key, being one of the device-specific supplementary attestation keys, SAK, the key description, KD, including parameters, other than the secret seed 115, to generate the key, K and when the key, K, is an asymmetric key pair, the public portion, Kp, of K. The trusted application 114 signs the attestation challenge, C, with the device-specific supplementary attestation keys, SAK, to produce a signature, S. The signature, S and the key description, KD, being included in the attestation data A. The trusted application 114 also signs the attestation with the shared device key 110. The trusted application 114 sends the signed attestation to the first software application 208, together with the corresponding digital certificate chain 112.

The application-specific supplementary attestation keys, SAK, are unique to each computing device. The provision of unique supplementary attestation keys, SAK, enables different keys to be used for different applications.

Provisioning:

The device-specific supplementary attestation keys, SAK, (say N = 200) may be provisioned to each computing device together with the shared device key 110 and the corresponding digital certificate chain 112. The shared device key 110 and the corresponding digital certificate chain 112 are provisioned among multiple (say, M = 10,000) devices to prevent linking, as in the current Android approach. Optionally, verification data, V, is computed for all M computing devices with the same shared device key 110 and the corresponding digital certificate chain 112 . The verification data, V, if used is included in digital certificates of the computing device 202 to allow verification. The verification data, V, may be in a form of an identifier, a URL, binary data, etc. In some cases, the verification data, V, may be implicit and no extra data need to be inserted. For example, the verification data, V, may be a subject name in the device certificate. Alternatively, a random seed is injected into the computing device 202 to enable the computing device 202 to generate all the needed device-specific supplementary attestation keys, SAK, from the random seed, even after manufacturing. This allows fast provisioning of a large number of SAK with constant time. The device-specific supplementary attestation keys, SAK, may be generated cryptographically in association with device certificates, for example in the format of ATTK via JSON or X.509. The device-specific supplementary attestation keys, SAK, may be valid for a lifetime until revoked by a vendor service.

The vendor service is an online service provided by a vendor of the computing device 202 to facilitate validation of attestations. There may be other services connected and utilized by the vendor service, such as a database server. The vendor may also choose to provide multiple vendor services that a cloud service provider may access. The cloud service is an external entity to the computing device 202 The cloud service hosts online services that can be accessed by an application. Optionally, other services such as certification authorities, CA, are connected and utilized by the cloud service. The application may also connect and access multiple cloud services at a same time.

The injection of random seed into the computing device 202 enables to support a large number of device-specific supplementary attestation keys, SAK, with a constant time. The random seed supports a plurality of service providers without the need to provide more secret seeds during manufacturing of the computing device 202.

Attestation:

As mentioned earlier, a key attestation happens typically after user authentication is completed in an application, and a long-term key is required to sign transaction data in the future for example when using specific cloud services. Before key attestation, the cloud service may optionally choose to issue a challenge value to the application to ensure that the attestation is fresh and not a replay.

When the application sends a request with a challenge value C for key attestation to a secure keystore (TA), the secure keystore (TA) generates a new key pair and a piece of attestation data A which includes at least the public portion of the generated key pair and the challenge C. This attestation A may be in the form of an X.509 certificate, as in the case of Android key attestation, or a certificate signing request, as in the case of Microsoft TPM key attestation, or any other formats that can be understood by the service provider.

Before digitally signing attestation A, the following additional steps are performed: i) Choose one of the supplementary attestation keys based on application identifier. Let this key be denoted as K. Let K_p be the publicly visible part of K. If K is an asymmetric key pair, then K_P is the public portion of the key pair. If K is a symmetric key, then K_P should be an identifier that allows K to be identified later in the verification phase. The choice of the key K for a specific application should be binding, in the sense that the secure keystore (TA) always uses the same K for all subsequent attestation requests from the same application. ii) Sign the attestation challenge with the chosen key K. Let S denote the resulting signature. iii) Both S and K_p are included in the attestation data A. The actual method of inclusion depends on the format of A. For example, if A is an X.509 certificate, then S and K_p can be included as certificate extensions. Alternatively, the original challenge C can be expanded to also include S and K_p, and in that case we do not rely on the extensibility of the attestation data format but instead require that service providers are able to validate the attestation accordingly. Finally, the secure keystore (TA) signs the attestation with the provisioned device key. The signed attestation is then returned to the application that requested it, together with provisioned device certificates.

The attestation data, A, optionally includes a data part that includes at least: (a) the public key of the transaction key pair, (b) the attestation challenge, C, (c) the signature, S computed from the challenge C and a key, K, from the device-specific supplementary attestation keys, SAK, (d) the key description, KD, for the key, K, that signs the challenge C. The data part may be in an envelope format that is suitable for signing. The attestation data, A, may include a signature part that includes a digital signature computed over the data part with the shared device key 110. The signature part is computed from the data part and a private portion of the shared device key 110. For example, the signature, S, represented as Signature, S, = Sign (Data Part, Shared Device Key), where the data part is used as a message and the shared device key 110 is used as a signing key The device certificate chain part includes the shared device certificate or a certificate chain. The full certificate chain may include complete information of the computing device 202. The application may select to send only a part of the chain, such as only a last certificate that contains the public key of the shared device key 110.

FIG. 3 is a schematic diagram of a computing device 304 with a key attestation ability, in accordance with an implementation of the disclosure, and various ancillary elements that interact with the computing device 304. The schematic diagram includes a manufacturing unit 302, the computing device 304, a cloud service 306, and a service provider 308. The manufacturing unit 302 provides a shared device key and corresponding device certificate to each of a plurality of computing devices (M, say 10,000 devices). The manufacturing unit 302 provides multiple (N, say 250) supplementary attestation keys, SAK, for each device in the plurality of computing devices, M. The supplementary attestation keys, SAK, are optionally generated and provided together with the shared device key. The device certificate may include specific verification data V calculated for all M devices with the same shared device key and certificate. The verification data V may be calculated from all N*M supplementary attestation keys. The verification data V is, if used, included in the device certificate to allow verification. The verification V can be in the form of an identifier, a URL, some binary data, and so on. In some cases, the verification V can be implicit and no extra data is required to be inserted. For example, the V can be simply the subject name in the device certificate.

The supplementary attestation keys, SAK, may be provided by injecting all generated keys into the computing device 304. Alternatively, and preferably, the supplementary attestation keys, SAK, are provided by injecting a device-specific random seed that allows the computing device 304 to generate all the supplementary attestation keys, SAK.

The computing device 304 includes an application 310 that requires a long-term key to sign transaction data when using specific cloud services. The long-term key is typically generated after user authentication is completed in the application. Before key attestation, the cloud service 306 may optionally choose to issue a challenge value (C) to the application to ensure that the attestation is fresh and not a replay. The application 310 is configured to send a request with the challenge value C (which may have been generated on the computing device 304 rather than having been supplied by the cloud service 306) for key attestation to a secure keystore (TA) which is an example of a trusted application 114 , the secure keystore (TA) generates a new transaction key pair, TK, and a piece of attestation data A which includes at least the public portion of the generated key pair and the challenge C.-Thus, the trusted application 114 generates a transaction key pair, TK, and an attestation for the transaction key pair, TK. The trusted application 114 also generates attestation data, A, which includes at least a public portion of the transaction key pair, TK, and a key description, KD, of a key, K. The key description, KD, of the key, K, being one of supplementary attestation keys, SAK. The key description, KD, including parameters, other than the secret seed 115, to generate the key, K, and when the key, K, is an asymmetric key pair, then Kp, is a public portion of the key, K. The supplementary attestation keys, SAK, are selected based on identifiers. For example, the key is represented as K, then the public portion of K is Kp. If K is an asymmetric key pair, then Kp is the public portion of the key pair. If K is a symmetric key, then Kp is an identifier that enables K to be identified for verification. The trusted application 114 signs the attestation challenge, C, with the device-specific supplementary attestation key, K, to produce a signature, S, the signature, S, and the key description, KD, being included in the attestation data A. The attestation data, A, is signed with the device key and provided to the service provider 308 along with device certificates. The attestation, A, optionally in the form of an X.509 certificate.

The device vendor optionally configures a publicly available validation service another service provider can use this service to validate that a particular supplementary attestation key K, identified by Kp, belongs to the group of devices from which a given verification V was computed. If a device is compromised, all the SAK provisioned to the compromised device should be marked as revoked and no longer belonging to the corresponding device group. The service provider 308 also verifies the signature, S, against the challenge, C, and Kp. Depending on the actual implementation, the validation service provided by the device vendor may or may not be required in this step.

Optionally, the service provider 308 further verifies that the supplementary attestation key, K, identified by Kp was indeed provisioned to the plurality of computing devices that share verification data, V, included in the device certificate. Depending on the actual implementation, the validation service provided by the device vendor may or may not be required in this step.

Optionally, the service provider 308 further verifies that the supplementary attestation key, K, identified by Kp has not been revoked by the device vendor, by consulting the validation service provided by the device vendor.

FIG. 4 is an exemplary block diagram that illustrates a computing device 400 having a device-specific key-attestation ability and an application-specific key attestation ability in accordance with an implementation of the disclosure. The computing device 400 is optionally interacts with a cloud service 402 and a vendor service 404 to perform device- specific key attestation and application-specific key attestation. A first technical implementation will first be described.

At the provisioning stage, the method of performing the device-specific key attestation and the application-specific key attestation, similar to Android Key Attestation, a shared device key and certificate are provisioned among multiple (say, M = 10,000) devices to prevent linking. For each of these M device, multiple (say, N = 200) Supplementary Attestation Keys (SAKs) are generated and provisioned together with the shared device key and certificate. The provisioning of the SAKs can be done by injecting all generated keys into the device, or alternatively, it can be done by injecting only a random seed, and allowing the devices to generate all the required SAKs from the seed, even after manufacturing. This allows fast provisioning of a large number of SAKs with constant time.

In this implementation, the device-specific supplementary attestation keys, SAK, are a set of asymmetric key pairs (such as ECC keys), generated from a random seed. The verification data V is implicit, since knowing the device certificate would be sufficient for a third party to verify the attestation by utilizing the validation service provided by the device vendor.

During the provisioning of the device-specific supplementary attestation keys, SAK, the seed is provisioned to the device, which then perform the generation process internally to obtain all the SAKs. The same key generation process is also performed outside of the device to obtain all the public portion of the key pairs. These public keys are recorded in a database system maintained by the device vendor, and are associated with the specific device, and the device group that the device belongs to. The device group is identified by the shared device certificate provisioned to the device

At the attestation stage, typically after user authentication is completed in an application, and a long term key is required to sign transaction data in the future when using specific cloud services, the method of performing the device-specific key attestation and the application-specific key attestation optionally includes the application sending a request with a challenge value C for key attestation to the secure keystore (TA), the secure keystore (TA) generates a new key pair and a piece of attestation data A which includes at least the public portion of the generated key pair and the challenge C. The challenge value C may have been provided, before key attestation, by the cloud service 402 may optionally choosing to issue a challenge value (C) to the application to ensure that the attestation is fresh and not a replay. The attestation A may be in the form of an X.509 certificate, as in the case of Android key attestation, or a certificate signing request, as in the case of Microsoft TPM key attestation, or any other formats that can be understood by the service provider. Before digitally signing attestation A, the following additional steps are performed:

Choose one of the supplementary attestation keys SAKs based on application identifier. Let this key be denoted as K. Let K_p be the publicly visible part of K. If K is an asymmetric key pair, then K_p is the public portion of the key pair. If K is a symmetric key, then K_p should be an identifier that allows K to be identified later in the verification phase. The choice of the key K for a specific application should be binding, in the sense that the secure keystore (TA) always uses the same K for all subsequent attestation requests from the same application.

Sign the attestation challenge (which in this first implementation may be a challenge nonce supplied by the application) with the chosen key K (for example, using the standard ECDSA digital signature algorithm). Let S denote the resulting signature.

Both S and K_p are included in the attestation data A. The actual method of inclusion depends on the format of A. For example, if A is an X.509 certificate, then S and K_p can be included as certificate extensions. Alternatively, the original challenge C can be expanded to also include S and K_p, and in that case we do not rely on the extensibility of the attestation data format but instead require that service providers are able to validate the attestation accordingly. Finally, the secure keystore (TA) signs the attestation with the provisioned device key, as it would in prior art.

At the verification stage, in this first implementation the method of performing the device- specific key attestation and the application-specific key attestation includes a service provider receiving the attestation A and corresponding device certificates from a device, and verifying the validity of the received data by querying the validation service provided by the device vendor, where K_p and the device certificate are the input.

Optionally, the service provider further verifies the signature S against the challenge C and K_p locally without using the vendor service 404.

Optionally, the service provider further verifies that the supplementary attestation key K identified by K_p has not been revoked by the vendor, by consulting the validation service provided by the vendor.

The computing device 400 with the key attestation ability disclosed above enables application providers and service providers to uniquely identify the computing device 400 where an application is hosted. At the same time, the computing device 400 with the key attestation ability disclosed above enables a device vendor to individually revoke compromised devices. The computing device 400 with the key attestation ability disclosed above includes a shared device key for each device group that avoids high loads on the certification authority (CA). A computing device 400 with the key attestation ability disclosed above is optionally provisioned with a random seed, while manufacturing, that (i) enables the computing device 400 to support multiple service providers at the same time and (ii) improves the preservation of user privacy when combining application providers or service providers for some specific tasks.

A second technical implementation will now be described.

At the provisioning stage, the method of performing device-specific key attestation and application-specific key attestation according to this second implementation optionally includes, after all N sets of SAK for M devices in the same device group have been generated, (i) computing a Bloom filter value V from these M * N keys; (ii) the Bloom filter value is used as verification data, V, and this is included into the shared device certificate as an X.509 certificate extension; and (iii) during the provisioning of the device-specific supplementary attestation keys, SAK, which can again be done either by injecting all generated keys into the device, or alternatively, by injecting only a random seed, and allowing the devices to generate all the required SAKs from the seed, even after manufacturing using random seeds and recording the Bloom filter values. Instead of recording all the public keys of SAKs, the random seeds that were used to generate SAK and the Bloom filter value V are recorded. The Bloom filter value V includes an initial version number (For example: 0). The initial version number should be updated when a compromised device is identified, and the Bloom filter value V computed again from remaining devices that are not compromised.

Note that a Bloom filter is a probabilistic data structure that allows fast membership query with no false negatives but a small false positive. The parameters of the Bloom filter should be chosen in such a way that the incidence of false positives is acceptable for the application in question.

In the attestation phase, the method of performing the device-specific key attestation and the application-specific key attestation optionally includes, (i) selecting one of the device- specific supplementary attestation keys, SAK, according to an application identifier, (ii) providing a challenge, C, that is signed by the selected key, K and (iii) including a public key, Kp, of the key, K, and the signature, S, into the attestation. For example, as X.509 certificate extensions. When an application is requesting for attestation for the first time, the secure persistent storage 412 may randomly select a key, K, from the provisioned supplementary attestation keys, SAK. A relationship between the application and the key, K, is recorded to use the same key, K, for all subsequent attestation requests from the same application. This is the same as in the previously described first implementation.

In the verification phase, the method of performing the device-specific key attestation and the application-specific key attestation includes (i) the device vendor configuring a publicly available service that enables a service provider to query the latest version of the Bloom filter value that belongs to the device group identified by a device certificate, (ii) verifying the signature, S, against the attestation challenge, C, and public key, Kp, and (iii) verifying the key attestation by querying a validation service provided by the vendor service 404, where the shared device certificate, and optionally the current version number of the bloom filter value is the input for the verification of the key attestation. The cloud service 402 verifies that Kp is an element of the device-specific supplementary attestation keys, S AK, for the device group by checking the Bloom filter value V included in the device certificate. If the vendor service 404 reports that there is a new version of the Bloom filter value V, then the service provider optionally retrieves the latest version and repeats the Bloom filter verification. The Bloom filter value included in the shared device certificate allows for fast local validation, and may be cached by the service provider to reduce the number of queries that need to be handled by the vendor validation service provided by the vendor service 404.

A further alternative technical implementation will now be described.

At the provisioning stage, the method of performing the device-specific key attestation and the application-specific key attestation according to this third technical implementation includes generating the device-specific supplementary attestation keys, SAK, from a random seed for the computing device 400 as a set of symmetric keys. Since the symmetric keys are secret keys that do not include a public portion from a cryptographic process, we assign a short (say, 2 bytes) identifier Kid for each key, K, and use Kid as the public portion of the supplementary attestation keys, SAKs. and (ii) recording Kid identifiers for all the device-specific supplementary attestation keys, SAKs, in a database of the vendor service 404, and are associated with the computing device 400, and a device group that the computing device 400 belongs to. The identifier only needs to be long enough so that all the keys in the device-specific supplementary attestation keys, SAKs, for the computing devices in the same computing device group to have a uniquely assigned Kid. The Kid identifiers for all the keys are recorded in a database system maintained by the device vendor, and are associated with the specific device, and the device group that the computing device 400 belongs to. To revoke a compromised device, all the Kid identifiers belonging to that device are marked as revoked.

At the attestation stage, the method of performing the device-specific key attestation and the application-specific key attestation according to this third technical implementation includes (i) selecting one of the device-specific supplementary attestation keys, SAK, according to an application identifier, (ii) the application provides the challenge, C, signed by the selected key, K, using a symmetric digital signature algorithm, such as HMAC and (iii) the identifier Kid and the signature, S, are included in the attestation. When an application is requesting for attestation for the first time, the secure persistent storage 412 may randomly select a key, K, from the provisioned supplementary attestation keys, SAKs. A relationship between the application and the key, K, is recorded to use the same key, K, for all subsequent attestation requests from the same application.

At the verification stage, the method of performing the device-specific key attestation and the application-specific key attestation according to this third technical implementation includes (i) configuring a publicly available service that allows a service provider to validate if an identifier Kid belongs to the computer device group identified by the shared device certificate, and that the device certificate and Kid have not been revoked (ii) verifying the signature, S, on the challenge, C, using the key referenced by the identifier Kid, (iii) verifying the signature, S, against the challenge, C, and the identifier Kid using the vendor service 404 and (iv) providing the identifier Kid and the shared device certificate as the input for the verification of the key attestation.

A further alternative technical implementation will now be described.

At the provisioning stage, the method of performing device-specific key attestation and application-specific key attestation according to this fourth technical implementation includes providing a random seed for the device-specific supplementary attestation keys, SAK, to the computing device 400, to generate all elliptic curve cryptography, ECC, key pairs and also a certificate for each key, K, of the supplementary attestation keys, SAKs. The certificate is optionally represented as SAKCert, and the SAKCert is signed using the provisioned shared device key. The device-specific supplementary attestation keys, SAK, are a set of asymmetric key pairs. Optionally, a validation service provided by a device vendor is utilized by the computing device 400 to verify the attestation as a verification data, V. The verification data, V, is implicit and the device certificate may be used for verification.

At the attestation stage, the method of performing the device-specific key attestation and the application-specific key attestation optionally includes (i) selecting one of the device- specific supplementary attestation keys, SAK, according to an application identifier, (ii) providing a challenge, C, by an application that is not signed - in other words, this step is skipped. Kp is optionally a public portion of the key, K, that is included in the SAKCert for the key, K. The attestation certificate is signed with the selected key, K, from the device-specific supplementary attestation keys, S AKs, for the requesting application. The SAKCert for the key, K, and the shared device certificate form a valid certificate chain, and are returned to the application as such.

At the verification stage, the method of performing the device-specific key attestation and the application-specific key attestation according to this fourth technical implementation includes (i) configuring a publicly available service that enables a service provider to validate if the SAKCert is valid with respect to the shared device certificate and (ii) providing the SAKCert for the key, K, and the shared device certificate as the input for the verification of the key attestation. The attestation certificate signature verification is performed by the public key, Kp, contained in the SAKCert.

FIG. 5 is an interaction diagram of a method of provisioning a computing device with a key attestation ability in accordance with an implementation of the disclosure. At step 508, authentication of a user is initiated at an application 502 to a cloud service 504 when the user uses the application 502 for the first time. The user authentication may be performed using other authentication factors such as messages sent to a trusted phone number. At step 510, the user is authenticated at the application 502 by the cloud service 504 using a user name and a password. At step 512, an attestation challenge, C, is requested by the application 502 from the cloud service 504. At step 514, the attestation challenge, C, is provided to the application 502 by the cloud service 504. At step 516, a key pair, TK, is generated by the trusted application 506 and stored in secure persistent storage on request by the application 502. At step 518, a public part of the generated key pair is obtained from the trusted application 506 by the application 502. At step 520, attestation of the generated key pair is requested by the application 502. At step 522, the generated key pair is attested and signed by the trusted application 506. At step 524, the cloud service 504 is requested to register the generated key pair by the application 502. At step 526, the generated key pair is registered and transactions are initiated by the cloud service 504. At step 528, the trusted application 506 is requested to sign a transaction by the application 502. At step 530, the transaction that is requested by the application 502 is signed by the trusted application 506. At step 532, the application 502 performs a transaction process. At step 534, the transaction process that is performed by the application 502 is completed by the cloud service 504.

The application 502 may enable the user to perform actual payment transactions, where transaction messages are signed with a private portion of the generated key pair. The transaction messages are optionally verified by the cloud service 504 before the transactions.

FIG. 6 is a flow diagram that illustrates an application-specific key attestation method performed on a computing device in accordance with an implementation of the disclosure. The computing device has a rich execution environment, REE, a secure execution environment, SEE, a first software application, a trusted application, a secure persistent storage, a shared device key, common to a plurality of other computing devices, and a corresponding digital certificate chain, and a plurality of device-specific supplementary attestation keys. The first software application performs secure transactions and operates in the rich execution environment, REE. The trusted application operates in the secure execution environment, SEE and generates keys and performs key management and cryptographic operations. The secure persistent storage is only accessible by the trusted application in the secure execution environment, SEE. The plurality of device-specific supplementary attestation keys, SAK, are generated from a secret seed, and the shared device key are all stored in the secure persistent storage. At a step 602, an attestation challenge, C is provided, to the trusted application by the first software application, and the trusted application is requested to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK. At a step 604, attestation data, A is generated by the trusted application. The attestation data, A, includes a public part of the transaction key pair, TK, and a key description, KD, of a key, K, being one of the device-specific supplementary attestation keys. The key description, KD, including parameters, other than the secret seed, to generate the key, K and when the key, K, is an asymmetric key pair, the public portion, Kp, of K. At a step 606, the attestation challenge, C, is signed with the device-specific supplementary attestation key K, by the trusted application to produce a signature, S. The signature, S and the key description, KD, being included in the attestation data A. At a step 608, the attestation is signed with the shared device key by the trusted application. At a step 610, the trusted application sends the signed attestation together with the corresponding digital certificate chain to the first software application.

The application-specific key attestation method can support a large number of user devices. The application-specific key attestation method supports multiple applications and services at a same time on each computing device without new keys. The application- specific key attestation method provides the shared device certificate for each device group of the computing devices reduces a load on Certification Authority, CA. The application-specific supplementary attestation keys, SAK, may be unique for each device group of the computing devices. The unique supplementary attestation keys, SAK, enables different keys to be used for different applications to prevent linking of the keys. The individual revocation is provided to the service providers by allowing them to use vendor services to check validity of the application-specific supplementary attestation keys, SAK. Optionally, the method includes the trusted application recording an association between the first software application and the device-specific supplementary attestation key, K, so that the key, K is no longer available for use with another software application.

Optionally, the method includes the first software application generating the attestation challenge, C, that is subsequently provided to the trusted application. Optionally, the method includes the first software application obtaining from a second software application, which may be operating on the same computing device as the first software application or on a remote computing device, the attestation challenge, C, that is subsequently provided to the trusted application.

The first software application may initially (i) request the trusted application to generate the transaction key pair, (ii) receive the public portion of the transaction key pair from the trusted application and (iii) subsequently provide the attestation challenge, C, to the trusted application.

The first software application providing the attestation challenge, C, to the trusted application and requesting the trusted application to generate the transaction key pair, TK, and the attestation may include the first software application issuing a single request to the trusted application, the single request containing both the attestation challenge, C, and the request to generate the transaction key pair, TK.

The signing of the attestation challenge with the device-specific supplementary attestation keys, SAK, may include signing the attestation challenge with the device-specific supplementary attestation key K using an asymmetric digital signature algorithm. The asymmetric digital signature algorithm may for example be ECDSA.

The first software application and the trusted application are optionally software components that are hosted by the computing device. The secure persistent storage may be a sub-component in the computing device that is protected by hardware in a way that the secure persistent storage is more secure and trusted than normal applications running on the computing device. Optionally, one of the device-specific supplementary attestation keys, SAK, is provisioned to the computing device that is denoted as K. The K signs the attestation challenge C. The resulting signature, S, and the public portion of K are optionally denoted as Kp, which are included in the attestation data A. The K may be random initially but is fixed for the requesting application afterwards.

The public portion, Kp, of K, and the signature, S, are optionally included in the attestation as extensions to an X.509 certificate.

The plurality of device-specific supplementary attestation keys, SAK, are optionally asymmetric key pairs generated from a random seed, each asymmetric key pair having an associated key description, KD, that includes Kp.

The plurality of device-specific supplementary attestation keys, SAK, may be symmetric keys generated from a random seed, each symmetric key having an associated key description, KD, that includes parameters, not including the random seed, required to generate the symmetric keys. Optionally, the method includes signing the attestation challenge, C, with the device-specific supplementary attestation key, K, using a symmetric digital signature algorithm such as HMAC.

FIG. 7 is a flow diagram that illustrates a method of provisioning a computing device to provide the computing device with a device-specific key-attestation ability in accordance with an implementation of the disclosure. The computing device includes a rich execution environment, REE, a secure execution environment, SEE, device-specific key material, and a persistent memory that includes a secure storage portion. At a step 702, a shared device key and a corresponding digital certificate chain are stored in the secure storage portion of the persistent memory, the shared device key and the corresponding digital certificate chain being common to each of a plurality of computing devices M (say at least 10,000 devices) . At a step 704, a trusted application is stored in the secure storage portion of the persistent memory to operate in the secure execution environment, SEE, to generate keys and perform key management and cryptographic operations. At a step 706, the device-specific key material is stored in the secure storage portion of the persistent memory for use by the trusted application in providing application-specific key- attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE.

The device-specific key attestation method provides a shared device certificate for each device group of the computing devices which reduces the load on the Certification Authority, CA. The application-specific supplementary attestation keys, SAKs, are unique to each computing device. The unique supplementary attestation keys, SAKs, enable different keys to be used for different applications to prevent linking of the keys.

Optionally, the method includes installing the plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE.

The device-specific key material may include a device-specific random seed for the generation of a plurality of device-specific attestation keys. Optionally, the method includes using a key generation process in the computing device to generate a plurality of device-specific supplementary key-attestation keys, SAK, from the device-specific random seed and, for each, K, of the device-specific supplementary attestation keys, a key description, KD. The key description, KD, includes parameters, other than the device- specific random seed, to generate K, the key description, KD, further including the public portion, Kp, of K when K is an asymmetric key pair. The plurality of device-specific supplementary attestation keys, SAK, may include multiple asymmetric key pairs. Optionally, the method includes using the key generation process outside the computing device to generate public portions of the multiple asymmetric key pairs. Optionally, the method includes, storing in a database the generated public portions of the asymmetric key pairs in association with the device-specific random seed used to generate the asymmetric key pairs and a device identity for the computing device. Optionally, the method includes storing in the database a device group identity for each computing device that shares the shared device key.

Optionally, the method includes generating the public portions of the asymmetric key pairs for each of the plurality of devices that share the shared device key. Optionally, the method includes computing a Bloom filter value from the public keys of the plurality of devices that share the shared device key and including the Bloom filter value in a device certificate for each of the devices that share the shared device key. Optionally, the method includes recording in a database the Bloom filter value and the device-specific random seed that was used to generate the supplementary attestation keys.

The plurality of device-specific supplementary attestation keys, SAK, may include a plurality of symmetric keys each symmetric key having an associated key description, KD. The key description, KD, may include parameters, other than the device specific random seed, required to generate the symmetric keys. Optionally, the method includes storing in a database the key descriptions, KD, for each of the symmetric keys in association with a device identity for the computing device. Optionally, the method includes storing in the database a device group identity for each computing device that shares the shared device key.

The device-specific key material may include a plurality of device-specific supplementary attestation keys, SAK, generated from a device-specific random seed.

FIG. 8 is a flow diagram that illustrates a method of verifying a key attestation, A, generated for a user of a secure application installed on a computing device in accordance with an implementation of the disclosure. The key attestation, A, being for an asymmetric application-specific transaction key pair for the secure application, the method being performed by an entity. At a step 802, the key attestation, A, is received at the entity. The key attestation, A, includes (i) a data part that includes a public key of the transaction key pair, an attestation challenge, C, a key, K. The key, K, being one of a plurality of device- specific supplementary attestation keys, SAK, from the computing device, a signature, S computed from the attestation challenge, C, the challenge, C, being signed by key, K, a key description, KD, for the key, K, the key description, KD, including parameters to generate K and, when K is an asymmetric key pair, a public portion, Kp, of K; and (ii) a signature part that contains a digital signature, the digital signature having been computed in respect of the data part and a private portion of a shared device key; and (iii) a device certificate chain part that containing a shared device certificate or shared device certificate chain or part thereof. At a step 804, check if the signature part can be verified using the data part and a public key of the shared device key. At a step 806, check if the signature, S, can be verified by the public key, Kp, if the public key, Kp, of K is included in the key description, KD. At a step 808, check if the certificate chain part is a valid chain. At step 810, check with an external validation service, the validity of the key description, KD.

The key attestation, A, enables application providers and a service provider to uniquely identify a specific computing device in a group of computing devices as the key K is unique to a particular computing device and also to a specific application installed on the computing device.

The service provider optionally verifies the signature, S, against the challenge, C, and Kp. The service provider optionally verifies the device-specific supplementary attestation keys, SAK, identified by Kp is provisioned to the group of computing devices that share the same verification data included in the device certificate chain. The service provider optionally verifies a revocation of the device-specific supplementary attestation keys, SAK, identified by Kp by consulting a validation service provided by, for example, the device vendor.

Optionally, the method includes checking if the attestation challenge, C, in the data part is the same as the attestation challenge, C, that was previously issued by the entity in respect of the attestation;

Optionally, the method includes (i) receiving a Bloom filter value as part of the device certificate chain part and (ii) checking that the public key, Kp, is a member of the Bloom filter value. The Bloom filter value having been generated from the public keys of the plurality of devices that share the shared device key. Optionally, the method includes checking with the external validation service the validity of the Bloom filter value.

The device certificate chain part may contain only a portion of the shared device certificate chain, the portion including the public key of the shared device key.

In the event that verification is successful, the entity may issue to the secure application another set of digital certificates in respect of the application-specific transaction key pair.

In the event that verification of the key attestation A is successful, the entity may record the public key of the application-specific transaction key pair as a valid transaction key for the user in respect of the secure application.

A shared device certificate and additional (N) unique supplementary attestation keys, SAK, are optionally provisioned for each device group of the computing devices. The M * N supplementary attestation keys, SAK, are optionally associated with the shared device certificate by public verification data that is included in the device certificate.

It should be understood that the arrangement of components illustrated in the figures described are exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the scope of the disclosure as defined by the appended claims.

Claims

1. An application-specific key attestation method performed on a computing device (102, 202, 304, 400), the computing device (102, 202, 304, 400) having: a rich execution environment, REE (104); a secure execution environment, SEE, (106); a first software application (208) to perform secure transactions and that operates in the rich execution environment, REE, (104); a trusted application (114, 506) to generate keys and perform key management and cryptographic operations that operates in the secure execution environment, SEE, (106); a secure persistent storage (212, 412, 506) that is only accessible by the trusted application (114) in the secure execution environment, SEE, (106); a shared device key (110) and a corresponding digital certificate chain (112), the shared device key (110) being common to a plurality of other computing devices, and a plurality of device-specific supplementary attestation keys, SAK, generated from a secret seed, all stored in the secure persistent storage (212, 412); the key attestation method comprising: the first software application (208) providing an attestation challenge, C, to the trusted application (114, 506) and requesting the trusted application (114) to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK; the trusted application (114, 506) generating attestation data, A, which includes at least: a public part of the transaction key pair, TK; a key description, KD, of a key, K, K being one of the device-specific supplementary attestation keys, SAK, the key description, KD, including parameters, other than the secret seed, to generate K, and when K is an asymmetric key pair, the public portion, Kp, of K; the trusted application (114, 506) signing the attestation challenge, C, with the device- specific supplementary attestation key, K, to produce a signature, S, the signature, S, and the key description, KD, being included in the attestation data A; the trusted application (114, 506) also signing the attestation with the shared device key (110); and the trusted application (114, 506) sending the signed attestation to the first software application (208), together with the corresponding digital certificate chain (112).

2. The method of claim 1, further comprising the trusted application (114, 506) recording an association between the first software application (208) and the device- specific supplementary attestation key, K, so that the key, K is no longer available for use with another software application.

3. The method of claim 1 or claim 2, further comprising the first software application (208) generating the attestation challenge, C, that is subsequently provided to the trusted application (114, 506).

4. The method of claim 1 or claim 2, further comprising the first software application (208) obtaining from a second software application, which may be operating on the same computing device (102, 202, 304, 400) as the first software application (208) or on a remote computing device, the attestation challenge, C, that is subsequently provided to the trusted application (114, 506).

5. The method of any one of the preceding claims, wherein the first software application (208): initially requests the trusted application (114, 506) to generate the transaction key pair; receives the public portion of the transaction key pair from the trusted application (114, 506); and subsequently provides the attestation challenge, C, to the trusted application (114, 506).

6. The method of any one of claims 1 to 4, wherein the first software application (208) providing the attestation challenge, C, to the trusted application (114, 506) and requesting the trusted application (114, 506) to generate the transaction key pair, TK, and the attestation includes: the first software application (208) issuing a single request to the trusted application (114, 506), the single request containing both the attestation challenge, C, and the request to generate the transaction key pair, TK.

7. The method of any one of the preceding claims, wherein the signing the attestation challenge with the device-specific supplementary attestation key, K, includes: signing the attestation challenge with the device-specific supplementary attestation key K using an asymmetric digital signature algorithm.

8. The method of any one of the preceding claims, wherein the public portion, Kp, of K and the signature, S, are included in the attestation as extensions to an X.509 certificate.

9. The method of any one of the preceding claims, wherein the plurality of device- specific supplementary attestation keys, SAK, are asymmetric key pairs generated from a random seed, each asymmetric key pair having an associated key description, KD, that includes Kp.

10. The method of any one of claims 1 to 6, wherein the plurality of device-specific supplementary attestation keys, SAK, are symmetric keys generated from a random seed, each symmetric key having an associated key description, KD, that includes parameters, not including the random seed, required to generate the symmetric keys.

11. The method of claim 10, further comprising signing the attestation challenge, C, with the device-specific supplementary attestation key, K, using a symmetric digital signature algorithm such as HMAC.

12. A method of provisioning a computing device (102, 202, 304, 400) to provide the computing device (102, 202, 304, 400) with a device-specific key-attestation ability, the computing device (102, 202, 304, 400) having: a rich execution environment, REE (104); a secure execution environment, SEE, (106); and a persistent memory (108) that includes a secure storage portion; the method comprising: storing in the secure storage portion of the persistent memory (108) a shared device key (110) and a corresponding digital certificate chain (112), the shared device key (110) and the corresponding digital certificate chain (112) being common to each of a plurality of computing devices; storing in the secure storage portion of the persistent memory (108) a trusted application (114, 506) to operate in the secure execution environment, SEE, (106) to generate keys and perform key management and cryptographic operations; and storing in the secure storage portion of the persistent memory device-specific key material (116) for use by the trusted application (114, 506) in providing application-specific key- attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE, (104).

13. The method of claim 12, further comprising installing the plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE, (104).

14. The method of claim 12 or claim 13, wherein the device-specific key material (116) comprises a device-specific random seed for the generation of a plurality of device specific attestation keys.

15. The method of claim 14 further comprising using a key generation process in the computing device (102, 202, 304, 400) to generate a plurality of device-specific supplementary key-attestation keys, SAK, from the device-specific random seed and, for each, K, of the device-specific supplementary attestation keys, a key description, KD, wherein the key description, KD, includes parameters, other than the device-specific random seed, to generate K, the key description, KD, further including the public portion, Kp, of K when K is an asymmetric key pair.

16. The method of claim 15, wherein the plurality of device-specific supplementary attestation keys, SAK, comprise multiple asymmetric key pairs. 17. The method of claim 16, further comprising using the key generation process outside the computing device (102, 202, 304, 400) to generate public portions of the multiple asymmetric key pairs.

18. The method of claim 17, further comprising storing in a database the generated public portions of the asymmetric key pairs in association with the device-specific random seed used to generate the asymmetric key pairs and a device identity for the computing device (102, 202, 304, 400).

19. The method of claim 18, further comprising storing in the database a device group identity for each computing device (102, 202, 304, 400) that shares the shared device key (110). 20. The method of claim 17, further comprising generating the public portions of the asymmetric key pairs for each of the plurality of devices that share the shared device key

(110).

21. The method of claim 20, further comprising computing a Bloom filter value from the public keys of the plurality of devices that share the shared device key (110) and including the Bloom filter value in a device certificate for each of the devices that share the shared device key (110).

22. The method of claim 21, further comprising recording in a database the Bloom filter value and the device-specific random seed that was used to generate the supplementary attestation keys. 23. The method of claim 15, wherein the plurality of device-specific supplementary attestation keys, SAK, comprise a plurality of symmetric keys each symmetric key having an associated key description, KD, that includes parameters, other than the device specific random seed, required to generate the symmetric keys.

24. The method of claim 23, further comprising storing in a database the key descriptions, KD, for each of the symmetric keys in association with a device identity for the computing device (102, 202, 304, 400).

25. The method of claim 24, further comprising storing in the database a device group identity for each computing device (102, 202, 304, 400) that shares the shared device key

(110).

26. The method of claim 12 or claim 13, wherein the device-specific key material (116) comprises a plurality of device-specific supplementary attestation keys, SAK, generated from a device-specific random seed. 27. A computing device (102, 202, 304, 400) having a device-specific key-attestation ability, the computing device (102, 202, 304, 400) having: a rich execution environment, REE, (104); a secure execution environment, SEE, (106); a persistent memory (108) that includes a secure storage portion; and stored in the secure storage portion of the persistent memory (108): a shared device key (110) and a corresponding digital certificate chain (112), the shared device key (110) and the corresponding digital certificate chain (112) being common to each of a plurality of computing devices; a trusted application (114, 506) to operate in the secure execution environment, SEE, (106) to generate keys and perform key management and cryptographic operations; and device-specific key material (116) for use by the trusted application (114) in providing application-specific attestation for a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE, (104).

28. The computing device (102, 202, 304, 400) of claim 27, further comprising a plurality of software applications to perform secure transactions and that operate in the rich execution environment, REE, (104).

29. The computing device (102, 202, 304, 400) of claim 27 or claim 28, wherein the device-specific key material (116) comprises a device-specific random seed for the generation of a plurality of device-specific attestation keys.

30. The computing device (102, 202, 304, 400) of claim 27 or claim 28 wherein the device-specific key material (116) comprises a plurality of device-specific supplementary attestation keys, SAK, generated from a device-specific random seed.

31. The computing device (102, 202, 304, 400) of claim 30, wherein the plurality of device-specific supplementary attestation keys, SAK, comprise multiple asymmetric key pairs.

32. The computing device (102, 202, 304, 400) of claim 31, further comprising a Bloom filter value in a device certificate, the Bloom filter value having been computed from public keys of the plurality of devices that share the shared device key (110).

33. A computing device (102, 202, 304, 400) having application-specific key- attestation ability, the computing device (102, 202, 304, 400) having: a rich execution environment, REE, (104); a secure execution environment, SEE, (106); a first software application (208) to perform secure transactions and that operates in the rich execution environment, (104); a trusted application (114, 506) to generate keys and perform key management and cryptographic operations that operates in the secure execution environment, SEE, (106); a secure persistent storage (212, 412) that is only accessible by the trusted application (114) in the secure execution environment, (106); a shared device key (110) and a corresponding digital certificate chain (112), the shared device key (110) being common to a plurality of other computing devices, and a plurality of device-specific supplementary attestation keys, SAK, generated from a secret seed, all stored in the secure persistent storage (212, 412); and being configured to perform a key attestation method in which: the first software application (208) provides an attestation challenge, C, to the trusted application (114, 506) and requests the trusted application (114, 506) to generate a transaction key pair, TK, and an attestation for the transaction key pair, TK; the trusted application (114, 506) generates attestation data, A, which includes at least: a public part of the transaction key pair, TK; a key description, KD, of a key, K, K being one of the device-specific supplementary attestation keys, SAK, the key description, KD, including parameters, other than the secret seed, to generate K, and when K is an asymmetric key pair, a public portion, Kp, of K; the trusted application (114, 506) signs the attestation challenge, C, with the device- specific supplementary attestation key, K, to produce a signature, S, the signature, S, and the key description, KD, being included in the attestation data A; the trusted application (114, 506) also signs the attestation with the shared device key (110); and the trusted application (114, 506) sends the signed attestation to the first software application (208), together with the corresponding digital certificate chain (112).

34. A method of verifying a key attestation, A, generated for a user of a secure application installed on a computing device (102, 202, 304, 400), the key attestation A being for an asymmetric application-specific transaction key pair for the secure application, the method being performed by an entity, and the method comprising: i) receiving at the entity a key attestation A that contains: a data part that includes a public key of the transaction key pair, an attestation challenge, C, a key, K, the key, K, being one of a plurality of device-specific supplementary attestation keys, SAK, from the computing device (102, 202, 304, 400), a signature, S, computed from the challenge, C, the attestation challenge, C, being signed by key, K, a key description, KD, for key, K, the key description, KD, including parameters to generate K and, when K is an asymmetric key pair, a public portion, Kp, of K; a signature part that contains a digital signature, the digital signature having been computed in respect of the data part and a private portion of a shared device key (110); a device certificate chain part containing a shared device certificate or shared device certificate chain or part thereof; and subsequently ii) checking if the signature part can be verified using the data part and a public key of the shared device key (110); iii) if the public key, Kp, of K is included in the key description, KD, checking if the signature, S, can be verified by the public key, Kp; iv) checking if the certificate chain part is a valid chain; and thereafter v) checking with an external validation service the validity of the key description, KD.

35. The method of claim 34, further comprising checking if the attestation challenge, C, in the data part is the same as a challenge that was previously issued by the entity in respect of the attestation;

36. The method of claim 34 or claim 35, further comprising: receiving a Bloom filter value as part of the device certificate chain part, the Bloom filter value having been generated from the public keys of the plurality of devices that share the shared device key (110); and checking that the public key, Kp, is a member of the Bloom filter value.

37. The method of claim 36, further comprising: checking with the external validation service the validity of the Bloom filter value.

38. The method of any one of claims 34 to 37, wherein the device certificate chain part contains only a portion of the shared device certificate chain, the portion including the public key of the shared device key (110).

39. The method of any one of claims 34 to 38, wherein, in the event that verification is successful, the entity issues to the secure application another set of digital certificates in respect of the application-specific transaction key pair.

40. The method of any one of claims 34 to 38, wherein, in the event that verification of the key attestation A is successful, the entity records the public key of the application- specific transaction key pair as a valid transaction key for the user in respect of the secure application.