Apparatus and method for remote attestation using symmetric keys

Abstract

An apparatus is configured to support secret key cryptography based remote attestation. A device is provisioned with an attestation secret key and the apparatus is provisioned with a device secret key corresponding to the device. A verifier is provisioned with a verifier secret key. The attestation secret key may be derived from the verifier secret key and extra information, where the extra information is generated based on a device id and the device secret key. The device protects evidence with the attestation secret key and forwards the evidence to the apparatus along with a device id. The apparatus generates extra information based on the device id and a device secret key and forwards the evidence and extra information to a verifier. The verifier derives the attestation secret key based on the extra information and the verifier secret key and uses the derived key to verify the evidence.

Description

[0001] APPARATUS AND METHOD FOR REMOTE ATTESTATION USING SYMMETRIC KEYS

[0002] TECHNICAL FIELD

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

[0004] BACKGROUND

[0005] Remote attestation is a process by which devices prove the security and configuration state of their software and hardware to relying parties. An attesting party sends information, referred to as attestation evidence, to a verifier where it is verified and audited. The verifier then returns an attestation result to the relying party.

[0006] Attestation can be particularly important in systems that are distributed across the internet and has seen increasing use with smaller and less costly loT (Internet of Things) devices. Remote attestation is most often secured using public key cryptography. However, it is well known that public key cryptography requires relatively more processing power and storage space than other cryptographic systems, such as secret key cryptography. Many smaller loT devices, such as sensors and wearables, do not contain sufficient processing resources to support public key cryptography.

[0007] Secret key cryptography offers a less resource intensive alternative to public key cryptography. However, with secret key cryptography, each secret key needs to be securely distributed to both the attester and the verifier. Furthermore, the verifier needs to securely store and maintain many device specific secret keys.

[0008] Constrained devices that do not have sufficient resources to support public key cryptography can also be less secure than their larger and more powerful counterparts. Thus, secret keys stored within a constrained device are more easily compromised. It would therefore be desirable to employ a remote attestation process that improves security of the secret key material necessary to compromise a remote attestation system.

[0009] Thus, there is a need for improved apparatus and methods capable of supporting secret keybased remote attestation while avoiding the drawbacks associated with distributing and maintaining many device specific secret keys while also improving overall security of the system. Accordingly, it would be desirable to provide methods and apparatus that addresses at least some of the problems described above.

[0010] SUMMARY

[0011] The aspects of the disclosed embodiments are directed to apparatus and systems configured to perform secret key cryptography-based remote attestation on small or resource constrained devices having limited memory and computing power. The use of secret key cryptography allows a constrained device to efficiently generate attestation evidence, while a novel key derivation approach simplifies the key distribution problem typically associated with secret key cryptographic techniques. Pairing the constrained device with a controller improves security by strengthening protection of secret keys and increasing the number of devices an attacker needs to compromise in order to compromise the attestation process.

[0012] According to a first aspect, the above and further implementations and advantages are obtained by an apparatus including a processor communicatively coupled to a memory and a network interface, where the processor is configured to transmit and receive data via the network interface. The memory includes program instructions that when executed by the processor cause the apparatus to: receive a device secret key and store the device secret key in a secure execution environment; receive a device public information, wherein the device public information is associated with an attesting device; generate a device extra information based on the device public information and the device secret key; receive an attestation evidence, wherein the attestation evidence includes information corresponding to a state of the attesting device, and the attestation evidence is protected with an attestation secret key; and transmit the attestation evidence together with the device extra information. The attestation secret key is derived based on the device extra information and a verifier secret key.

[0013] In a possible implementation form, the device extra information is generated by applying a first hash function to the device public information and the device secret key. Hashing the device public information with the device secret key, prevents an attacker from extracting the secret key from the device extra information.

[0014] In a possible implementation form, the attestation secret key is derived by applying a second hash function to the device extra information and the verifier secret key. This allows the verifier to derive the attestation secret key without the need to securely distribute and store device specific key material by the verifier.

[0015] In a possible implementation form, the first hash function and the second hash function comprise a cryptographically secure one-way function. The use of cryptographically secure one-way functions improves security of the overall system.

[0016] In a possible implementation form, the attestation secret key is derived by applying an algebraic operation to the device secret key and the verifier secret key. This provides additional design flexibility during implementation.

[0017] In a possible implementation form, the apparatus includes a controller public information and the attestation secret key is derived based on the device public information, the controller public information, the device secret key, and the verifier secret key. Diversifying the attestation secret key with controller information, binds the attestation evidence to both the constrained device and the associated controller.

[0018] In a possible implementation form, the apparatus is further configured to: receive a second device public information, wherein the second device public information is associated with a second attesting device; generate a second device extra information based on the second device public information and the device secret key; receive a second attestation evidence, wherein the second attestation evidence includes information corresponding to a state of the second attesting device and the attestation evidence is protected with a second attestation secret key; and transmit the second attestation evidence together with the second device extra information. The second attestation secret key is derived based on the second device extra information and the verifier secret key. Sharing the device secret key among multiple devices reduces the number of secret keys that need to be managed, and provides flexibility beneficial to overall system design.

[0019] In a possible implementation form, the attestation secret key is derived based on the device extra information and the second device extra information. Diversifying the attestation secret key with information from multiple constrained devices allows devices to be bound together. For example, an operation may not be allowed unless all bound devices are successfully attested. In a possible implementation form, the apparatus comprises a virtual machine executing within a hypervisor. The controller apparatus need not be a separate device, such as a smartphone, it may for example be a separate process running within a hypervisor on the same hardware platform as other entities in the remote attestation system.

[0020] In a possible implementation form, the device extra information is generated based on a first device secret key and the second device extra information is based on a second device secret key, and the first device secret key is different than the second device secret key.

[0021] According to a second aspect, the above and further implementations and advantages are obtained by a system for remote attestation where the system includes a device, such as a constrained device, a controller, a verifier, and a relying party. The system is configured to: provision the verifier with a validation secret key; provision the controller with a device secret key; and provision the device with an attestation secret key, wherein the attestation secret key is derived based at least in part on a device extra information, the device secret key, and the validation secret key. The device receives an attestation challenge and generates attestation evidence, wherein the attestation evidence includes information corresponding to a state of the device and is protected with the attestation secret key. The controller receives the attestation evidence and a device public information, and generates the device extra information based on the device public information and the device secret key, wherein the device public information is associated with the device. The verifier receives the device extra information and the attestation evidence, derives the attestation secret key based at least in part on the device extra information and the verifier secret key, validates and audits the attestation evidence based at least in part on the attestation secret key, and generates an attestation result. The use of secret key cryptography allows a constrained device to efficiently generate attestation evidence, while the key derivation approach simplifies the key distribution problem typically associated with secret key cryptographic techniques. Pairing the constrained device with a controller improves security by strengthening protection of the device secret key and increasing the number of devices an attacker needs to compromise in order to compromise the attestation evidence.

[0022] In a possible implementation form of the system according to the second aspect, the controller includes a secure execution environment and the controller is configured to protect the device secret key with the secure execution environment. Protecting the device secret key with the SEE improves security of the device secret key. In a possible implementation form of the system according to the second aspect, the device extra information is generated by applying a first hash function to the device public information and the device secret key. Hashing the device public information with the device secret key, prevents the secret key form being recovered by an attacker who has access to the device extra information.

[0023] In a possible implementation form of the system according to the second aspect, the attestation secret key is derived by applying a second hash function to the device extra information and the verifier secret key. This allows the verifier to derive the attestation secret key without the need to securely distribute and store device specific key material within the verifier.

[0024] In a possible implementation form of the system according to the second aspect, the first hash function and the second hash function include a cryptographically secure one-way function. The use of cryptographically secure one-way functions improves security of the overall system.

[0025] In a possible implementation form of the system according to the second aspect, the attestation secret key is derived by applying an algebraic operation to the device secret key and the verifier secret key. This provides additional design flexibility during implementation.

[0026] In a possible implementation form of the system according to the second aspect, the system is configured to generate within the device an attestation challenge and receive, within the controller, the attestation challenge. The controller generates a second attestation evidence and the device extra information, wherein the second attestation evidence includes information corresponding to a state of the controller. The verifier receives the attestation challenge, the second attestation evidence, and the device extra information, then validates and audits the attestation challenge and the second attestation evidence. The verifier generates the attestation result, wherein the attestation result is protected with the attestation secret key. The device receives the attestation result and validates the attestation result based at least in part on the attestation secret key. The system is easily adapted to have the device act as the relying party.

[0027] In a possible implementation form of the system according to the second aspect, the verifier is configured to derive a result protection key by applying a deterministic key derivation function to the attestation secret key, and the attestation result is protected with the result protection key. Deriving a result protection key improves “crypto-hygiene” based on the principle that every key should be used for only one purpose. These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

[0028] BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 1 illustrates a block diagram of an exemplary apparatus, and remote attestation process configured to provide secret key cryptography based remote attestation incorporating aspects of the disclosed embodiments;

[0031] Figure 2 illustrates a block diagram of a remote attestation system incorporating aspects of the disclosed embodiments;

[0032] Figure 3 illustrates a pictorial diagram of a secret key derivation process appropriate for derivation of an attestation secret key incorporating aspects of the disclosed embodiments;

[0033] Figure 4 illustrates a flow diagram of an exemplary secret key cryptography-based remote attestation process appropriate for use with a constrained device incorporating aspects of the disclosed embodiments.

[0034] DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

[0035] Figure 1 illustrates a block diagram of an exemplary apparatus 100, and remote attestation (RA) process 150 configured to provide secret key cryptography based remote attestation incorporating aspects of the disclosed embodiments. The exemplary apparatus 100 of the disclosed embodiments, generally includes an apparatus 100, also referred to herein as a controller 100, that is configured to improve security of secret key based remote attestation in a fashion that allows implementation on constrained devices 114 and prevents an attacker, who has compromised the constrained device 114, from compromising the remote attestation process 150. Among other benefits, the herein disclosed embodiments avoid the need for a verifier to securely receive and maintain a large number of secret keys, and require an attacker to compromise both the controller 100 as well as the constrained device 114 before being able to pre-empt the RA process 150. These improvements and advantages are obtained in part by a secret key derivation process that is distributed across the attesting device 114 and a controller 100.

[0036] As shown in the example of Figure 1, the exemplary apparatus 100, includes a processor 102 communicatively coupled to a memory 104 and a network interface 106. In one embodiment, the processor is configured to transmit and receive data via the network interface 106. The memory 104 includes program instructions that when executed by the processor 102 cause the apparatus 100 to: receive a device secret key (Kd) and store the device secret key (Kd) in a secure execution environment 108; receive a device public information, wherein the device public information is associated with an attesting device 114; generate a device extra information based on the device public information and the device secret key (Kd); receive an attestation evidence, wherein the attestation evidence includes information corresponding to a state of the attesting device 114 and the attestation evidence is protected with an attestation secret key. In one embodiment, the attestation secret key is derived based on the device extra information and a verifier secret key Kv. The attestation evidence is then transmitted with the device extra information.

[0037] The processor 102 is generally configured to exchange data with other networked computing apparatus via the network interface 106. In certain embodiments it is beneficial to include a secure execution environment 108 within the apparatus 100 to protect sensitive algorithms and to prevent unauthorized access or modification of confidential information, such as secret key material.

[0038] The apparatus 100 may be any desired type of computing apparatus or communications apparatus including but not limited to a mobile communications device such as a smartphone, wearable, or tablet. In certain embodiments the apparatus 100 may be a personal computing apparatus such as a laptop or other type of personal computing device, a server apparatus such as those used in cloud computing data centers, or any desired computing apparatus that includes a processor a memory and a means for communicating over a computer network.

[0039] As is shown in the example of Figure 1, the processor 102 is communicatively coupled to the memory 104 and is configured to read and perform operations on data stored in the memory 104. In certain embodiments the apparatus 100 may also include a system storage (not shown) such as a disk drive or solid-state disk configured to provide high-capacity long term storage capabilities.

[0040] The processor 102 can generally comprise any suitable processing device including but not limited to a high-performance multi-core computer processing device such as those used in large cloud computing data centers, a multi-core or single core microprocessor such as those used in workstations and laptop computers, a processing device embedded in a system such as a system on a chip (SoC), or any suitable or specialized processing device such as those used in mobile communications devices, smartphones, phablets, tablet computers, telecommunications equipment, and smart devices configured for the internet of things (loT).

[0041] The memory 104 may include any desired type or combination of computer accessible memory, such as random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile computer memory.

[0042] A network interface 106 is communicatively coupled to the apparatus 100 and is configured to exchange data and messages between the apparatus 100 and other endpoints or nodes in the computer network, such as a key generation center 132, a Relying Party (RP), a constrained device 114, and a verifier 116. The network interface 106 may be any suitable type of computer network configured to allow the apparatus 100, or other computerized device, to share information and resources. The network interface 106 may be adapted to exchange information over any desired type of physical computer network media such as wired, optical, or wireless media, using any desired networking protocol. When operating in a virtualized environment, the network may be adapted to communicate over virtual networks present within the virtualized environment.

[0043] Wired networks include any desired type of computer network configured to use electric signals to carry information over network links, such as links constructed of conductive wires. Optical networks include any type of network configured to use optical signals to carry information over network links, such as links constructed of fiberoptic materials. Wireless networks include any suitable type of computer network that uses radio signals to transmit information through air, such as WIFI, Bluetooth, long term evolution (LTE), or other wireless broadband communication mechanisms.

[0044] In certain embodiments, the apparatus 100 includes a secure execution environment (SEE) 108, also referred to as a trusted execution environment (TEE). The SEE 108 may include any desired type of secure execution environment such as a trusted execution environment (TEE), a trusted application (TA), a trusted platform module (TPM), enclave, or other desired type of suitably secure execution environment. For example, as is the case with most new smartphones manufactured today, the apparatus 100 may include an implementation of the ARM® architecture's TrustZone™ TEE.

[0045] As used herein the term remote attestation (RA) refers to a process in which devices prove the security and configuration state of their software and hardware to relying parties (RPs). The attested, i.e. proven, properties are referred to as attestation claims. Typical attestation claims include: measurements, such as hashes of static code and files; runtime measurements, such as hashes of executable code residing in program memory; identifiers, such as version numbers, components identifiers, etc.; and identities such as cryptographic keys. The attestation claims may include any information useful for proving the identity and integrity of a device.

[0046] An entity, such as the constrained device 114, wishing to prove its identity and integrity is referred to herein as the attester. The evidence, sometimes referred to as attestation evidence, is presented to a verifier 116 for verification and auditing. The entity that verifies and appraises the evidence is referred to herein as the verifier 116. The verifier 116 produces an attestation result 128 that can be used by RPs, such as the RP 112, to decide whether to trust the attesting device, such as the constrained device 114, for a particular purpose.

[0047] All messages involved in attestation, especially the evidence 120 and the result 128, must be protected against forgery and tampering. Protection of attestation evidence and results is typically provided using public-key cryptography. The attester can sign the evidence using its attestation private key. A verifier can then use the corresponding public key to verify the signature before appraising the claims. There are two primary types of cryptographic system. Secret key cryptography, also referred to as symmetric key cryptography, uses a single secret key to encrypt data and uses the same secret key to decrypt the encrypted data. Public key cryptography, also referred to as asymmetric key cryptography, uses a pair of keys, where a first key in the key pair, sometimes referred to as the private key, is used to encrypt data, and a second key in the key pair, sometimes referred to as a public key, is used to decrypt the data that was encrypted with the first key.

[0048] Public-key cryptography and its use for protecting an RA process is well-established. Unfortunately, public key cryptography is resource intensive requiring significant memory and processing power to adequately perform the required operations. Therefore, due to resource and processing power constraints, public key cryptography is not available to a large class of devices, such as sensors, wearables, and other small embedded devices. These devices having limited computing power are referred to herein as constrained devices.

[0049] As an example of constrained devices, consider devices based on some popular device architectures. Some of these popular architectures allow a “mini” build configuration intended for small or low-cost devices. This “mini” build configuration includes only 128 kilobytes of memory. The operating system, networking code, and main application code of the devices must fit into that memory. Typical public-key cryptographic algorithms have a code size of tens of kilobytes of memory, making it at least difficult and often impossible to fit the necessary public key cryptographic algorithms into device memory. Public key cryptographic algorithms are also computationally intensive and can run unacceptably slowly due to processing power limitations on constrained devices.

[0050] As used herein, the term ‘constrained device’ refers to a small or low-cost computing device having memory and / or processing power constraints that prevent it from adequately performing public key cryptographic operations. Constrained devices are limited by their computing resources to symmetric key cryptography. Thus, conventional attestation methods based on public-key cryptography are not suitable for use with small or constrained devices, such as the constrained device 114.

[0051] Because symmetric-key cryptography is computationally efficient and can be implemented with small code size, it is a good choice for use in constrained devices. However, symmetric-key cryptography suffers from a critical problem: the symmetric key used to protect and de-protect messages must be shared between the sender and the recipient. In the context of remote attestation, the verifier must possess the same symmetric key that was used by the attesting device to protect the attestation evidence. Similarly, the RP must have the same symmetric key that was used by the verifier to protect the attestation results.

[0052] Constrained devices are often deployed in very large quantities. For example, the number of sensors and microcontrollers currently deployed in the field is likely in the billions of units. To support the large number of deployed devices using symmetric-key cryptography, the verifier would need to be pre-provisioned with an extremely large number of symmetric keys. This is clearly not practical. As a further complication, the deployed devices may be manufactured by many different companies. A trusted channel must be set up between each manufacturer and the verifier to securely provision the verifier with the necessary device secret keys.

[0053] One solution to the key distribution problem would be to use the same symmetric key for a large batch or group of devices, a sort of group key. However, this significantly degrades security by allowing a single compromised device to masquerade as any other device in the same group.

[0054] In many deployment scenarios, constrained devices are used together with a more powerful controller or gateway device. The controller can be used to receive data and send commands to the constrained device. For example, consumer IOT devices, such as a garden sprinkler controller, are usually paired with a smartphone. Smartphones typically have several gigabytes of memory and include processing power that approaches the processing power of a desktop computer. Also, most modem smartphones include security features, such as the TEE described above, that provide an enclave, protecting code and data from attacks originating outside of the enclave.

[0055] Requiring a constrained device to work together with a controller improves overall security of the attestation process 150. Due to their cost and size constraints, constrained devices, such as the constrained device 114, are less secure and more vulnerable to attack than larger more powerful controller devices, such as the controller 100. By pairing a constrained device with a more powerful controller device, an attacker who compromises a single constrained device cannot compromise the attestation process 150. An attacker would need to compromise both the constrained device 114 as well as the more secure controller device 100 with which the constrained device 114 is paired, to gain access to the device secret key. Referring once again to the RA process 150 illustrated in Figure 1, initialization of the RA process 150 begins by provisioning appropriate key material to the controller 100, the constrained device 114, and the verifier 116. A key generation center 132 generates a unique verifier secret key Kvand securely provisions 138 a verifier 116 with the verifier secret key Kv. The verifier secret key Kvmay then be securely stored by the verifier 116 for use when verifying attestation evidence. A unique device secret key Kdis generated for each constrained device 114 and a controller 100 is securely provisioned 134 with the device secret key Kd.

[0056] A unique attestation secret key Kais derived based on the device secret key Kd, the verifier secret key Kv, and a device public information ID. The attestation secret key Kais unique to a particular constrained device 114 and is provisioned 136 within the constrained device 114. Once provisioned, the attestation secret key Kanever leaves the constrained device 114. During RA, the constrained device 114 uses the attestation secret key Kato protect attestation evidence. For example, the protection may involve symmetric encryption or a signature computed using a symmetric-key algorithm, such as HMAC.

[0057] Derivation of the attestation secret key Kamay be performed in two steps. For example, a device extra information Ide may be computed by applying a first hash function to the device public information and the device secret key Kd,' Ide= hash(JD, Ka). The attestation secret key Kamay then be derived by applying a second hash function to the device extra information Ide and the verifier secret key Kv,' Ka= hash (Ide, Kv). Any suitable cryptographically secure one-way function may be used for the first hash function and the second hash function. In certain embodiments it may be advantageous to use a well understood cryptographically secure one-way function such as HMAC, MFG1, HKDF, PBKDF2, etc., or other suitable industry standardized cryptographically secure one-way function.

[0058] It is not necessary that the first hash function and the second hash function be the same. When desired, the first hash function and the second hash function may be different cryptographically secure one-way functions.

[0059] Optionally, derivation of the attestation secret key Kamay be achieved by applying an algebraic operation to the device secret key Kdand the verifier secret key Kv. For example, the attestation secret key Kamay be derived by adding the device secret key Kvand the verifier secret key KvKa= Kd+ Kv, where the addition (+) is an exclusive OR operation. In certain embodiments it may be beneficial to diversify the attestation secret key Kawith information associated with the controller. For example, a controller public information Ic, such as a controller device ID, controller serial number, or other information associated with the controller, may be incorporated into derivation of the attestation secret key Ka, thereby binding the controller 100 to the RA process 150. In an exemplary embodiment, incorporation of the controller public information Icmay be achieved for example, by concatenating the controller public information Icwith the device public information ID and using the concatenated result to derive the attestation secret key Ka'. Ka= hash hash Ic\ \Ide, Kd~), Kv)- Alternatively, the attestation secret key Kamay be derived as: Ka= hash(c\ \hash(de, Kd), Kv)- Those skilled in the art will readily recognize that any suitable key derivation function (KDF) may be advantageously employed to incorporate a controller public information into the attestation secret key including but not limited to hash functions and / or algebraic equations.

[0060] When an RP 112 needs to verify the security and configuration state of a constrained device 114, an attestation challenge 118 is sent to the constrained device 114. The constrained device 114 generates Evidence, also referred to herein as attestation evidence, which is protected with the attestation secret key Ka. The constrained device transmits 120 the Evidence back to the RP 112. Device public information ID, such as a device identifier or serial number associated with the constrained device 114, is transmitted 120 from the constrained device 114 to the RP 112. The device public information ID may be formatted in any desired fashion such as being included in the Evidence or appended to the Evidence as desired. In certain embodiments, security may be strengthened by including the attestation challenge in the generated Evidence.

[0061] The RP 112 then forwards 122 the Evidence and device public information ID to the controller 100. As described above, the controller 100 received and securely stored the device secret key Kd during provisioning. A device extra information De may then be generated within the controller 100 based on the pre-provisioned device secret key Kd and the received device public information ID. When desired, a TEE 108 may be employed for computation of the device extra information De, thereby protecting the algorithms and device secret key Kd from access, or tampering by an unauthorized entity.

[0062] The controller 100 transmits 124 the Evidence together with the device extra information De to the verifier 116. The verifier 116 is then able to independently derive the attestation secret key Kaby taking a hash of the device extra information e and the verifier secret key Kv, and employ the derived attestation secret key Kato verify the received Evidence.

[0063] Once the Evidence has been verified and successfully audited, the verifier 116 generates an Attestation Result and protects the Attestation Result with the attestation secret key Ka. The Attestation Result may then be sent 126 to the controller 100 where it is forwarded 128 to the RP 112. When desired, crypto-hygiene may be improved by diversifying the attestation secret key Kato derive a result protection key Krfor use when generating the Attestation Result.

[0064] Optionally, security may be enhanced by creating a secure channel 130 between the controller 100 and the verifier 116. The secure channel 130 may be any desired type of secure connection such as an encrypted channel set up using TLS and mutual authentication.

[0065] In the illustrated embodiment, the controller 100 is paired with a constrained device 114 by provisioning the controller 100 with a device secret key Kd corresponding to the attestation secret key Kaprovisioned in the constrained device 114. At sometime prior to remote attestation, the device secret key Kd is received by the controller 100 and stored internally for later use. Beneficially, the device secret key Kd may be stored in a SEE 108.

[0066] It should be understood that storing the device secret key Kd in the SEE 108 means that the SEE 108 is used to protect the key from access or tampering by an unauthorized party, and should not be so narrowly construed as to mean the key is actually stored in memory within the SEE 108. In certain embodiments, the key may be stored in memory protected within the SEE 108. Alternatively, the device secret key Kd may be protected by the SEE 108, such as through encryption, then the resulting cyphertext may be safely stored external to the SEE 108, such as in the memory 104.

[0067] The controller 100 also receives a device public information associated with the constrained device 114. The device public information may be any desired information associated with the constrained device 114 that may be revealed publicly without compromising the RA process 150. In certain embodiments the public information may include unique information associated with a particular constrained device 114, such as a serial number or other useful information identifying the constrained device 114.

[0068] Device extra information he is generated within the controller 100 based on the device secret key Kd and the device public information ID. As described above, the device extra information Ide may later be used in conjunction with a corresponding verifier secret key K, to derive the attestation secret key Ka.

[0069] During RA, the controller receives attestation evidence, also referred to herein as evidence. The attestation evidence may be generated by a constrained device, such as the constrained device 114, that is acting as an attester in an RA process, such as the RA process 150. The attestation evidence may include any desired information corresponding to a state of the attesting device 114 and is protected with the corresponding attestation secret key Ka.

[0070] The controller then transmits the attestation evidence together with the device extra information Ide to the verifier 116 where it may be verified and audited.

[0071] In certain embodiments the device secret key Kd is unique to a single constrained device 114. Alternatively, device secret key Kd may be viewed as a group secret key that is shared among a plurality or group of constrained or attesting devices. When performing RA with a shared device secret key Kd, the controller 100 receives a second device information, where the second device information is associated with a second attesting device. The second device information may be any suitable information associated with the second attesting device, and when desired may be configured to uniquely identify the second attesting device. For example, in certain embodiments, the second device information may include a device identifier, a serial number, or other suitable unique information associated with the second attesting device.

[0072] In certain embodiments, the second attesting device may be an entity executing on a second constrained device, for example when multiple sensors are being used by a single RP. Alternatively, the second attesting device may be a second entity executing on the same constrained device 114.

[0073] The controller 100 generates a second device extra information based on the received second device public information ID2 and the shared device secret key Kd. Generation of the second device extra information may for example be generated based on a hash function as described above where the second device extra information Ide2 is generated as: Ide2= hash(ID2, Kd). Alternatively, any suitable KDF may be advantageously employed to derive the second device extra information Ide2 from the second device public information ID2 and the shared device secret key Kd, including but not limited to a hash function, and an algebraic equation. During RA, the controller 100 receives a second attestation evidence from the second attesting device, wherein the second attestation evidence includes information or claims corresponding to a state of the second attesting device, such as but not limited to measurements, identifiers, or identities as described above. The second attestation evidence is protected based on a second attestation secret key derived from the second device extra information Ide2 and the verifier secret key Kv.

[0074] The second attestation evidence is then transmitted together with the second attestation evidence to a verifier, such as the verifier 116.

[0075] When desired it may be beneficial to bind two or more attesting devices together by deriving a single attestation secret key based on the device extra information from two or more attesting devices. For example, the attestation secret key may be derived from a first device extra information corresponding to a first attesting device, a second device extra information corresponding to a second attesting device, and the verifier secret key. The first device extra information and the second device extra information may, when desired, be based on a single shared device secret key. Alternatively, the first device extra information may be generated based on a first device secret key and the second device extra information may be based on a second device secret key where the first device secret key is different than the second device secret key.

[0076] The controller 100, as well as other entities such as the RP, constrained device, and verifier, need not all be physically separate devices. Some or all the entities may be virtualized entities executing within a hypervisor on a single physical computing apparatus. For example, the controller 100 may be an application or operating system executing directly on a hardware processor. Alternatively, the controller 100 may be a virtual machine executing within a hypervisor.

[0077] Figure 2 illustrates a block diagram of a remote attestation system 200 incorporating aspects of the disclosed embodiments. The RA system 200 of the disclosed embodiments is appropriate for implementation of the RA process 150 described above and with respect to Figure 1. In the RA system 200, the use of derived secret keys allows a constrained device 204 to protect attestation evidence while avoiding the key distribution problem typically associated with secret key cryptographic systems. Security of the RA system 200 is improved by pairing the constrained device 204 with a controller 206 and using the controller 206 to protect confidential device specific key material, thereby forcing an attacker to compromise both the constrained device as well the controller 206 before a successful attack can be achieved.

[0078] Prior to attestation, a key generation center 202 generates a device secret key Kd and a verifier secret key Kv. An attestation secret key Kais derived from the device secret key Kd, the verifier secret key Kvand device public information ID as described above. The attestation secret key Kais securely provisioned 212 into the constrained device 204, the device secret key Kd is securely provisioned 214 into the controller 206, and the verifier secret key Kvis securely provisioned 216 into the verifier. Constrained devices 204, such as IOT sensors or embedded IOT device controllers, are typically less expensive and less sophisticated than the controller 206 and are therefore more easily compromised. The controller 206, which may for example be a device such as a smartphone that includes a SEE, is significantly more secure than the constrained device 204 and is therefore able to better protect the device secret key Kd.

[0079] When attestation of the constrained device 204 is required, the constrained device 204 generates attestation evidence by preparing a set of claims, such as measurements, identifiers, and identities, associated with the constrained device, and protecting the set of claims, such as with a digital signature or encryption, using the attestation secret key Ka. The attestation evidence is sent 218 together with device public information ID to the controller 206. In certain the device public information ID may be appended to the attestation evidence, or when desired the device public information ID may be incorporated into the attestation evidence.

[0080] The controller 206 combines the device public information ID with the device secret key Kd, as described above, to generate the device extra information Ide. The device extra information Ide is then sent 220 together with the attestation evidence to the verifier 208. In certain embodiments, the verifier 208 may be a publicly available service accessed over a public wide area network, such as the internet. When sending information over a wide area network it is often desirable to use secure communication channels, such as TLS, to send 220 and receive 224 information to / from the verifier 208.

[0081] A significant benefit of the disclosed embodiments is provided by structuring the secret keys in a way that obviates the need for the verifier to securely receive and maintain a database containing many secret keys. As described above, the attestation secret key Ka, which was used by the constrained device 204 to protest the attestation evidence, can be derived by the verifier 208 from the received device extra information Ide and the verifier secret key v. After receiving the attestation evidence, the verifier derives the attestation secret key Ka, verifies the attestation evidence, audits the included claims, and generates an attestation result. The attestation result is then sent 224 to the RP 210, where it may be used to determine whether the attester, which in the illustrated embodiment is the constrained device 204, may be trusted.

[0082] Figure 3 illustrates a pictorial diagram of a secret key derivation process 300 appropriate for derivation of the attestation secret key Kaincorporating aspects of the disclosed embodiments. The exemplary key generation process 300 of the disclosed embodiments is appropriate for use in the secret key cryptography-based RA processes 150 described above and with respect to Figure 1. The exemplary key generation process 300 facilitates reliable and secure remote secret key cryptography-based remote attestation without the need to securely distribute and store numerous secret keys by a verifier.

[0083] To begin the key derivation process, a key generation center or other secure facility generates a verifier secret key Kv, and one or more device secret keys Kd. The verifier secret key Kvis provided to a verification service and is the only key required by the service to verify attestation evidence. A device secret key Kd is generated for each device desiring to participate in RA.

[0084] In a first step 302 a device extra information Ide is generated based on the device secret keys Kd, and a device public information ID. The device public information ID may be any suitable publicly accessible information associated with the device such as a device identifier, a serial number, or other suitable device information as described above. The device public information ID is then combined 306 with the device secret keys Kd to generate the device extra information Ide. In certain embodiments the device public information ID may be combined 306 with the device secret keys Kd based on a hash function or other cryptographically secure one-way function: Ide= hash ID, Kd), thereby preventing anyone having access to the device extra information Ide from recovering the device secret keys Kd, and allowing safe transmission of the device extra information Ide over a computer network.

[0085] In a second step 304, a verifier, such as a network verification service exposed to the internet, derives the device specific attestation secret key Kafrom device extra information Ide and its own verifier secret key Kv. The device extra information Ide includes all information necessary for a verification service having possession of the appropriate verifier secret key Kv, to derive the attestation secret key Ka. In certain embodiments, the attestation secret key Kamay be derived 308 based on a hash or other cryptographically secure one-way function: Ka= hash (lde, Kv). Optionally, the attestation secret key Kamay be derived based on any suitable KDF, such as an algebraic equation as described above.

[0086] Figure 4 illustrates a flow diagram of an exemplary secret key cryptography-based remote attestation process 400 appropriate for use with a constrained device incorporating aspects of the disclosed embodiments. The exemplary remote attestation process 400 of the disclosed embodiments is appropriate for use in the RA system described above and with respect to Figure 2 where like reference numerals refer to like elements. At times it may be desirable for a constrained device 204 to verify the identity and integrity of a controller device 206. The illustrated process 400 allows a constrained device 204, to employ secret key cryptography and a verification service to verify a controller 206 efficiently and reliably without requiring the verification service to securely receive and maintain a large number of secret keys.

[0087] Prior to performing the exemplary process 400 a key generation center or other desired key authority provisions each entity with key material. The constrained device 204 is provisioned with an attestation secret key Ka. The controller 206 is provisioned with a device secret key Kd. And the verifier 208 is provisioned with a verifier secret key Kv. The attestation secret key Kais derived from the device secret key Kd, verifier secret key K, and device public information ID associated with the constrained device 204 as described above.

[0088] Once provisioning is complete, verification of a controller 206 may be accomplished with the exemplary process 400. In the exemplary process 400, the constrained device 204 is acting as a RP and the controller 206 is acting as the attester. To begin the exemplary process 400, the constrained device 204 sends an attestation challenge 402 to the controller 206.

[0089] In response to the attestation challenge 402, the controller 206 generates attestation evidence Ea, where the attestation evidence Eamay include any desired information useful for verifying the identity, and integrity of the controller 206. Because the controller 206 and verifier 208 include sufficient computing resources, the attestation evidence Eamay be protected with any appropriate cryptographic means, such as with public key cryptography.

[0090] The controller generates a device extra information Ide based on device public information ID and a device secret key Kd. As described above, the device extra information Ide may be generated by applying a hash function or other cryptographically secure one-way function to the device extra information Ide and the device secret key Kd. The device public information ID may include any appropriate publicly available information associated with the constrained device 204 such as a device identifier, serial number, or other suitable device public information. In certain embodiments the device public information ID may be provisioned in the controller 206 along with the device secret key Kd and retained in the controller 206 for use during the RA process 400. Alternatively, it may be beneficial for the constrained device 204 to include the device public information ID in the attestation challenge 402.

[0091] After completing generation of the necessary information, the controller 206 sends the attestation challenge 402, the attestation evidence Ea, and the device extra information Ide, to the verifier 408. The verifier 208 verifies and audits the attestation evidence Eaand determines an appropriate attestation result 406. The attestation result 406 may be protected using the attestation secret key Ka, where the attestation secret key Kais derived by the verifier 208 based on the device extra information Ide and the verifier secret key Kvas described above. The attestation result 406 may be protected with the attestation secret key Kabased on any suitable cryptographically secure approach as desired, such as by generating a digital signature based on the attestation secret key Kaor encrypting the attestation result 406 with the attestation secret key Ka.

[0092] The attestation result is then returned to the constrained device, such as by sending 406 the attestation result to the controller 206 and having the controller 206 forward 408 the attestation result to the constrained device 204. Whereupon, the constrained device 204 may use the attestation secret key Kato verify the attestation result 406. Successful verification of the attestation result by the constrained device 204 establishes trust between the constrained device 204 and the controller 206.

[0093] In certain embodiments, it may be desirable to protect the attestation result with a separate result protection key Krrather than protect the attestation result 406 using the attestation secret key Ka. The advantage of using a separate result protection key Kris improved “crypto-hygiene” based on the principle that every key should be used for only one purpose. A key should be used either for evidence protection or result protection but not both. In one embodiment, the result protection key r may be further diversified from the attestation secret key Kaby applying a deterministic KDF with some simple context information, such as: Kr= KDF (Ka," attestation result protection" , where “attestation result protection” is any suitable context information as desired.

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

Claims

CLAIMSWhat is claimed is:

1. An apparatus (100) comprising a processor (102) communicatively coupled to a memory(104) and a network interface (106), wherein the processor (102) is configured to transmit and receive data via the network interface (106) and wherein the memory (104) comprises program instructions that when executed by the processor (102) cause the apparatus (100) to: receive a device secret key (K ) and store the device secret key (Kd) in a secure execution environment (108); receive a device public information, wherein the device public information is associated with an attesting device (114); generate a device extra information based on the device public information and the device secret key (Kd) receive an attestation evidence, wherein the attestation evidence comprises information corresponding to a state of the attesting device (114) and the attestation evidence is protected with an attestation secret key, and wherein the attestation secret key is derived based on the device extra information and a verifier secret key (A ); and transmit the attestation evidence together with the device extra information.

2. The apparatus (100) according to claim 1, wherein the device extra information is generated by applying a first hash function to the device public information and the device secret key (Kd).

3. The apparatus (100) according to any one of the preceding claims, wherein the attestation secret key is derived by applying a second hash function to the device extra information and the verifier secret key (Kv).

4. The apparatus (100) according to any one of the preceding claims, wherein the attestation secret key is derived by applying an algebraic operation to the device secret key (Kd) and the verifier secret key (Kv).

5. The apparatus (100) according to any one of the preceding claims, wherein the apparatus(100) comprises a controller public information and the attestation secret key is derivedbased on the device public information, the controller public information, the device secret key (Kd), and the verifier secret key (Kv).

6. The apparatus (100) according to any one of the preceding claims, wherein the apparatus(100) is further configured to: receive a second device public information, wherein the second device public information is associated with a second attesting device; generate a second device extra information based on the second device public information and the device secret key (K ) receive a second attestation evidence, wherein the second attestation evidence comprises information corresponding to a state of the second attesting device and the second attestation evidence is protected with a second attestation secret key, and wherein the second attestation secret key is derived based on the second device extra information and the verifier secret key (Kv) and transmit the second attestation evidence together with the second device extra information.

7. The apparatus (100) according to claim 6, wherein the attestation secret key is derived based on the device extra information and the second device extra information.

8. The apparatus (100) according to any one of the preceding claims wherein the apparatus(100) comprises a virtual machine executing within a hypervisor.

9. A system (200) for remote attestation, the system (200) comprising a device (202), a controller (204), a verifier (206), and a relying party (208), wherein the system (200) is configured to: provision the verifier (206) with a validation secret key; provision the controller (204) with a device secret key; provision the device (202) with an attestation secret key, wherein the attestation secret key is derived based at least in part on a device extra information, the device secret key, and the validation secret key; receive, within the device (202), an attestation challenge; generate, within the device (202), an attestation evidence, wherein the attestation evidence comprises information corresponding to a state of the device (202) and is protected with the attestation secret key;receive, within the controller (204), the attestation evidence and a device public information, wherein the device public information is associated with the device (202); generate, within the controller (204), the device extra information based on the device public information and the device secret key; receive, within the verifier (206), the device extra information and the attestation evidence; derive, within the verifier (206), the attestation secret key based at least in part on the device extra information and the verifier secret key ( k); validate and audit, within the verifier (206), the attestation evidence, based at least in part on the attestation secret key; and generate, within the verifier, an attestation result.

10. The system (200) according to claim 9, wherein the controller (204) comprises a secure execution environment and the controller (204) is configured to protect the device secret key with the secure execution environment.

11. The system (200) according to claims 9 or 10, wherein the device extra information is generated by applying a first hash function to the device public information and the device secret key.

12. The system (200) according to any one of claims 9 through 11, wherein the attestation secret key is derived by applying a second hash function to the device extra information and the verifier secret key (Kv).

13. The system (200) according to any one of claims 9 through 12, wherein the first hash function and the second hash function comprise a cryptographically secure one-way function.

14. The system (200) according to any one of claims 9 through 13, wherein the attestation secret key is derived by applying an algebraic operation to the device secret key and the verifier secret key (Kv).

15. The system (200) according to any one of claims 9 through 14, wherein the system (200) is configured to: generate within the device (202) an attestation challenge; receive within the controller (204), the attestation challenge;generate within the controller (204) a second attestation evidence and the device extra information, wherein the second attestation evidence comprises information corresponding to a state of the controller (204); receive within the verifier (206), the attestation challenge, the second attestation evidence, and the device extra information; validate and audit, within the verifier (206), the attestation challenge and the second attestation evidence; generate, within the verifier (206), the attestation result, wherein the attestation result is protected with the attestation secret key; receive within the device (202), the attestation result; and validate, within the device (202), the attestation result based at least in part on the attestation secret key.

Images