GB2588647A

GB2588647A - Attestation for constrained devices

Info

Publication number: GB2588647A
Application number: GB1915779.1A
Authority: GB
Inventors: Claude Robert Giraud Jean-Luc; James Moran Brendan
Original assignee: Arm IP Ltd
Current assignee: Arm IP Ltd
Priority date: 2019-10-30
Filing date: 2019-10-30
Publication date: 2021-05-05
Anticipated expiration: 2039-10-30
Also published as: GB201915779D0; GB2588647B; WO2021084221A1

Abstract

Device attestation with a server hosting a service, including a first execution stage 106a and at least a second execution stage 106b where each execution stage is associated with a corresponding set of computer code or instructions stored 107, 110 on the device 102 and that is configured to execute on the device during execution of said execution stage. Each execution stage sequentially executes on the device. The first execution stage is enabled to have access to a first stage key on the device. During execution of the first execution stage, attestation data is generated for the second execution stage based on data representative of the first stage key, a device counter 122c, and a digest associated with the second execution stage 122b. Attestation data for the second execution stage is stored for sending to the server. The attestation data is used by the server as an indication or trust of at least the second execution stage or the device. The first stage key is accessible for use by the first execution stage during execution of the first execution stage on the device and inaccessible to the second execution stage thereafter.

Description

ATTESTATION FOR CONSTRAINED DEVICES

[0001] The present application relates to a system and method for attestation and key generation for constrained devices.

Backqround [0002] Attestation is a mechanism for a device to prove to a server or a server hosting a service what version or configuration of software, bootloader(s), application firmware/software, configuration, resources, data and/or images and the like that it is running or storing. Generally, the device generates attestation data (or authentication data) for sending to the server or service hosted by a server and the like to prove the device is what it says it is. As the device is usually a remote device and is communicating over a communication network with the server or the service, remote attestation is required which suffers greatly from replay attacks. A replay attack is when an attacker intercepts and copies the attestation data generated by the device to prove it is what it says it is. The attacker may also tamper with the device and use the copied attestation data to pretend to the server or the server hosting the service that the device is legitimate. Boot-time attestation generally consists of a secure environment that signs the contents of target memory sections for reporting to a server or service at a later time. The problem with this approach is that a malicious application or actor could copy this report and continue to report it later.

[0003] Boot-time secure remote attestation is largely unsolved issue for extremely constrained devices. A constrained device may comprise or represent any device that lacks or is without a mechanism for implementing privilege separation features (e.g. various runtime levels such as ELO-EL3 etc. or mechanisms like TrustZone (RTM)) such as, by way of example only but not limited to, devices with computational resources configured to sequentially execute multiple stages of execution. Examples of constrained devices may include, by way of example only but not limited to, embedded devices, real-time operating system devices, loT devices, smart home appliance(s), CCTV cameras, embedded sensors in industrial plants or power plants, smart TV, sensors, small form factor devices, automotive system devices, safety critical systems, communication devices and/or any other device that is constrained in terms of processing capacity and/or memory capacity, and/or has very constrained operating environments, constrained memory, processing power, and/or battery power, and/or has sequential executable stages in which there is no separation of privilege or a lack of privilege separation features.

[0004] Privilege execution separation (or separation of execution privilege), also known as privilege separation, is a technique or mechanism used for separating different types of executable code executing on a computing device based on different levels of trust and/or privilege requirements and the like. Privilege separation controls and/or restricts each executable code executing on the device only to those resources that are required for said each executable code to perform a task or process. The different types of executable code may include, by way of example but not limited to, initial bootloaders, other bootloaders or device drivers, applications, tasks, processes, system sub-components and/or operating system resources and the like.

[0005] Privilege separation mechanism on the device may, by way of example only but is not limited to, creating one or more "sandboxes" or "sandboxed environments" for the different types of executable code executing on the device. Each sandboxed environment may have a different level of trust and/or privilege attributed to it for controlling, limiting and/or restricting access to resources and the like on the device. This essentially creates "mini-firewalls" or "moats" around each type of sandboxed environment so that access to device and/or system resources and data and the like is controlled or restricted based on the privilege or level of trust settings. Privilege separation further mitigates the potential damage of a computer security vulnerability such as, by way of example only but not limited to, containing intruders or malicious attackers within a sandboxed environment on the device based on the privileges or levels of trust restricting that sandboxed environment. Thus, damage to the device is limited by the privileges or level of trust attributed to that sandboxed environment.

[0006] Unconstrained devices such as laptops or personal computers typically have a trusted computing environment, such as TrustZone (RTM) that operates "sandboxed" environments using privilege separation features for different types of executable code such as, by way of example only but not limited to, operating system/sub-components and various applications and the like. Once these are fully executing, which may execute in parallel or in a non-sequential order and the like, each may execute within its own sandboxed environment or share a sandboxed environment. However, privilege separation execution requires operating multiple sandboxed environments for one or more of the applications and/or operating systems/subcomponents, which requires a substantial amount of computational resources and can be resource intensive. A constrained device does not typically have the resources to have a trusted environment, multiple sandboxed environments, or privilege separation features like an unconstrained device. For a constrained device, the most trusted execution stage of the constrained device is typically the initial boot stage or first stage of execution, which typically is configured to have no network access because otherwise the device will have an overly large attack surface. Thus, remote attestation of a constrained device may only occur once network access or communications have been established between the device and the server of the service requiring attestation of the constrained device.

[0007] Most secure remote attestation systems perform attestation at runtime by signing a hash of the target memory, which is calculated at boot time, with a private key of an asymmetric key pair and including a remote challenge in the signature. However, asymmetric cryptography has a large cost in terms of non-volatile key storage, computationaVpower resources, random access memory (RAM) resources, and time. For every attestation, a challenge must be received which further incurs network costs in relation to power usage and time/bandwidth usage that a constrained device may ill afford. Such systems put a heavy burden on secure storage and trusted execution for a remote constrained device.

[0008] There is a desire for a lightweight methodology or apparatus for use in remote attestation of a constrained device to prove to a server or service at least the version of firmware the device is executing or operating/running and/or that the device firmware/software has not been tampered with. There is further a desire to perform efficient key generation for execution stages of constrained devices do without sacrificing security and the like.

[0009] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of the known approaches described above.

Summary

[0010] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter; variants and alternative features which facilitate the working of the invention and/or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention disclosed herein.

[0011] The present disclosure provides hybrid attestation mechanism and/or key generation mechanism for use on constrained devices configured to operate with a service hosted by one or more servers. The constrained device has multiple sequential or consecutive execution stages in which there is no separation of privilege. When a current execution stage executes on the device, it is configured to iteratively generate attestation data for the next execution stage based on the device counter and a current stage key whilst also iteratively generating a next stage key based on the current stage key for use by the next execution stage. The first execution stage, which may include an initial bootloader, is trusted and operates on a first stage key such as a hardware stored secret or derivation thereof and also a device counter for iteratively generating attestation data for the second execution stage whilst also iteratively generating second stage keys for use by the second execution stage.

[0012] Attestation data may be stored or aggregated on the device until an execution stage establishes communication with the server hosting the service, whereby stored attestation or aggregated attestation data for previous and/or the current execution stage is sent to the server hosting the service for performing trust management of the device in relation to the attestation data. The server is a trusted device that has access to data representative of the first stage key, and a server counter that tracks the device counter such that it can iteratively generate stage keys of the device and thus iteratively generate attestation data based on the received attestation data, which may include attestation code(s) and/or current device counter values.

[0013] In a first aspect, the present disclosure provides a computer-implemented method of device attestation with a server hosting a service, the device including a first execution stage and at least a second execution stage, wherein each execution stage is associated with a corresponding set of computer code or instructions stored on the device and that is configured to execute on the device during execution of said execution stage, and wherein each execution stage sequentially executes on the device, the method comprising: enabling the first execution stage to have access to a first stage key on the device; generating attestation data for the second execution stage, during execution of the first execution stage, based on data representative of the first stage key, a device counter, and a digest associated with the second execution stage; storing the attestation data for the second execution stage for sending to the server, wherein the attestation data is used by the server as an indication of trust of at least the second execution stage of the device; and wherein the first stage key is accessible for use by the first execution stage during execution of the first execution stage on the device and inaccessible to the second execution stage thereafter.

[0014] Preferably, the device includes a first execution stage, a second execution stage and one or more subsequent execution stages, each execution stage sequentially executes on the device, wherein for each execution stage of the second and one or more subsequent execution stage(s), the method further comprising: generating, during execution of a next execution stage, attestation data for the next execution stage comprising data representative of a current stage key, a device counter, and a digest associated with the next execution stage, wherein the current stage key is generated during execution of the previous execution stage of the device based on the previous stage key; storing the attestation data in relation to the current execution stage for sending to the server, wherein the attestation data for the next execution stage is used by the server as an indication of trust of at least the next execution stage of the device; and wherein the first stage key is accessible for use by the first execution stage during execution of the first execution stage on the device and inaccessible to the second execution stage and subsequent execution stage(s) thereafter.

[0015] Preferably, the method further comprising: aggregating the attestation data associated with one or more execution stages of the device; and sending the aggregated attestation data to the server after the device has established communications with the server.

[0016] Preferably, the method further comprising: tracking the status of the device in relation to the number of updates, shared secret refreshes of the first stage key, and/or reboots of the device by adjusting the device counter prior to each update, shared secret refresh of the first stage key, and/or reboot, wherein the server monitors the device counter based on a corresponding service counter associated with the device and performs trust management in relation to the second and/or subsequent execution stage(s) and/or the device based on an expected behaviour of the device counter in relation to the service counter and/or any received attestation data sent from the device in relation to one or more execution stages of the device.

[0017] Preferably, the method further comprising, during execution of the first execution stage: generating a digest of data representative of the second execution stage on the device; generating an attestation code using a message authentication code, MAC, algorithm based on the generated digest, the device counter, and the first stage key; creating the attestation data associated with the second execution stage comprising data representative of the attestation code and the device counter.

[0018] Preferably, the method further comprising, during execution of the second or any subsequent execution stage apart from the last execution stage of the device: generating a digest of data representative of the next execution stage on the device; generating an attestation code using a message authentication code, MAC, algorithm based on the generated digest, the device counter, and the current stage key; creating the attestation data associated with the current execution stage comprising data representative of the attestation code and the device counter.

[0019] Preferably, the method further comprising creating the attestation data comprising data representative of the attestation code, the device counter, and the generated digest.

[0020] Preferably, the method further comprising sending stored attestation data from the device to the server, wherein the server has access to a trusted copy of the first stage key and a service counter corresponding to and/or following the count of the device counter, the server configured to use a MAC algorithm to generate an attestation code based on the trusted copy of the first stage key, the service counter and/or a trusted copy of the digest of at least the second execution stage and comparing the generated attestation code with the received attestation code, wherein the server is configured to perform trust management in relation to the second execution stage and/or the device based on at least the comparison between attestation codes.

[0021] Preferably, the server compares the service counter with the device counter and performs trust management in relation to the second execution stage and/or the device based on at least the comparison between counters.

[0022] Preferably, the device counter comprises a first device counter and a second device counter, the first device counter for counting the number of times the server requests an update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device.

[0023] Preferably, the server is configured to use the first device counter to implement a challenge-response protocol with the device.

[0024] Preferably, the method further comprising: receiving an internal trigger or signal for rebooting the device; adjusting the second device counter; and rebooting the device.

[0025] Preferably, the method further comprising: receiving an internal trigger or signal for rebooting the device; rebooting the device; and adjusting the second device counter.

[0026] Preferably, the method further comprising: receiving, from the server hosting a service associated with the device, a message for requesting performing a change on the device; adjusting the first device counter of the device to indicate a change occurring on the device; rebooting the device; and adjusting the second device counter of the device after reboot.

[0027] Preferably, the method further comprising performing the requested change on the device. Preferably, performing the change on the device comprises one or more from the group of: performing an update on the device; performing a secret key refresh on the device; performing a key update on the device; performing an increment of the first counter of the device; performing a challenge response protocol on the device; and any other operation or function for changing the device that the server hosting the service is authorised to request in relation to the device.

[0028] Preferably, receiving, from the server hosting a service associated with the device, a message comprising a first count value corresponding to a service counter; replacing the current count value of the first device counter with the received first count value; rebooting the device; and adjusting the second device counter upon reboot of the device.

[0029] Preferably, the device counter is a monotonically increasing counter and adjusting the device counter comprises incrementing the device counter. Preferably, the server is configured to determine whether the device counter is monotonically increasing in relation to the service counter and performs trust management in relation to the next execution stage of the device or the device [0030] Preferably, the device counter is a monotonically decreasing counter and adjusting the device counter comprises decrementing the device counter. Preferably, the server is configured to determine whether the device counter is monotonically decreasing in relation to the service counter and performs trust management in relation to the second execution stage of the device.

[0031] Preferably, adjustments to the device counter are based on a known behaviour or pattern of increasing and/or decreasing the device counter, wherein adjusting the device counter comprises incrementing and/or decrementing the device counter based on the known behaviour or pattern. Preferably, the server is configured to determine whether the device counter is being adjusted in accordance with the known behaviour or pattern in relation to corresponding adjustments to the service counter and performs trust management in relation to the second or subsequent execution stage(s) of the device.

[0032] Preferably, the server performs trust management based on the attestation data and/or device counter, wherein trust management is configured to perform at least one from the group of: indicating to the server that each execution stage of the device is trusted based on the comparison matching and/or frequency of matches of previous comparisons in relation to received attestation data associated with the execution stage(s); indicating to the server that a number of execution stages of the device is trusted based on comparison matching or frequency of matches in relation to received aggregated attestation data associated with said number of execution stage(s); indicate to the server a trust level associated with the next execution stage or the device is increased to a higher level of trust based on the comparison matching and/or frequency of matches of previous comparisons based at least on the data representative of the attestation data; indicate to the server a trust level associated with the next execution stage or the device has decreased to a lower level of trust based on a mismatch in the comparison and/or frequency of mismatches of previous comparisons based at least on the data representative of the attestation data; and any other rule or threshold indicating a level of trust associated with the next execution stage or the device based at least on the data representative of the attestation data.

[0033] Preferably, generating, prior to/or during execution of the first execution stage, a next stage key for use by the next execution stage based on the first stage key accessible by the first execution stage; storing the generated next stage key in accessible storage on the device for access and use by the corresponding next execution stage; and disabling access to the first stage key for the next and any subsequent execution stage(s) prior to execution of the next and any subsequent execution stage.

[0034] Preferably, generating the next stage key for the next execution stage further comprises using a key derivation function to generate said next stage key based at least on the first stage key and the device counter.

[0035] Preferably, the device further including one or more subsequent execution stages, wherein each execution stage consecutively or sequentially executes on the device, the method further comprising: generating an attestation data for a subsequent execution stage, during execution of a current execution stage, based on data representative of the current stage key, the device counter, and a digest associated with the subsequent execution stage scheduled to execute on completion of the current execution stage, where the subsequent execution stage executes sequentially after the current execution stage; and storing the attestation data of the subsequent execution stage for sending to the service for attesting or determining an indication of trust in relation to the device or at least the subsequent execution stage of the device.

[0036] Preferably, the device includes a number of M consecutive execution stages, where /<=m<=M, the method further comprising: generating an (m+1)-th stage key for the (m+1)-th execution stage, during execution of an m-th execution stage, based on an m-th stage key accessible to the m-th execution stage; storing the (m+1)-th stage key in accessible storage for use by the (m+1)-th execution stage; wherein, when m=/, the 1-th stage key corresponds to the first stage key and the 1-th execution stage corresponds to the first execution stage of the device, the first stage key being accessible to the first execution stage during execution and inaccessible to /<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other /<=m<=M subsequent execution stages.

[0037] Preferably, generating the (m+/)-th stage key for the (m+V-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the m-th stage key.

[0038] Preferably, the first stage key is a stored secret and, when m=/, generating the (m+/)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the 14h stage key and the device counter, wherein 1-th stage key is the first stage key, wherein the stored secret and first stage key is accessible to the first execution stage during execution and inaccessible to /<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other /<m<=M subsequent execution stages.

[0039] Preferably, generating the first stage key based on a key derivation function with a stored secret and the device counter, wherein the first stage key and the stored secret is accessible to the first execution stage during execution and inaccessible to i<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other frm<=M subsequent execution stages.

[0040] Preferably, generating the (m+/)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the m-th stage key and the device counter.

[0041] Preferably, the m-th stage key is accessible to the m-th execution stage during execution of the m-th execution stage and is inaccessible to any other n-th execution stage, where m<n, after execution of the m-th execution stage and prior to and during execution of said any other n-th execution stage.

[0042] Preferably, generating attestation data for the (m+/)-th execution stage, during execution of the m-th execution stage, based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage; and storing the attestation data for the (m+/)-th execution stage for sending to the service for determining an indication of trust associated with at least the (m+1)-th execution stage of the device and/or the device.

[0043] Preferably, aggregating the attestation data for each (m+1)-th execution stage of the device; and sending the aggregated attestation data to the server once the device has established communications with the server during execution of an n-th execution stage of the device, where man.

[0044] Preferably, sending attestation data for the p-th execution stage to the server, where nv, during execution of the p-th execution stage.

[0045] Preferably, disabling access to the m-th stage key for all execution stages during or after execution of the m-th execution stage on the device, but prior to and during execution on the device of any subsequent execution stage.

[0046] Preferably, the first stage key is a stored secret on the device, the stored secret initially inaccessible to all the execution stages.

[0047] Preferably, the stored secret is a hardware stored secret on the device, and the method further comprising: enabling the first execution stage to have access to the first stage key comprising triggering hardware on the device associated with the first stage key to provide the first execution stage with access via accessible storage to the first stage key.

[0048] Preferably, disabling subsequent execution stage(s) access to the first stage key by triggering removal of the first stage key from the accessible storage, wherein the first stage key is inaccessible by all the execution stages.

[0049] Preferably, disabling the first execution stage access to the first stage key by triggering removal of the first stage key from the accessible storage, wherein the first stage key is inaccessible by all the execution stages.

[0050] Preferably, disabling access to the first stage key for all execution stages during or after execution of the first execution stage on the device, but prior to and during execution on the device of any subsequent execution stage.

[0051] Preferably, the first execution stage comprises an initial bootloader and the next execution stage or one or more subsequent execution stages comprise further bootloaders, application firmware and/or software for execution on the device after execution of the first execution stage.

[0052] Preferably, the first execution stage is stored on a non-volatile memory, NVM, of the device, and the first stage key is derived from a hardware stored secret stored on the device and is initially inaccessible, the method comprising: initiating execution of only the first execution stage when the device is booted; enabling, prior to or during execution of the first execution stage, access to the first stage key; and disabling access to the first stage key for all execution stages prior to execution of any other execution stage on the device, wherein the first stage key is inaccessible to all execution stages thereafter.

[0053] Preferably, the first stage key is encrypted using the hardware stored secret and stored in accessible memory of the device, wherein: enabling access to the first stage key comprises decrypting the encrypted first stage key using the hardware stored secret; and disabling access to the first stage key comprises removing or clearing any data representative of the plaintext first stage key from the accessible memory.

[0054] Preferably, the device has stored thereon: a hardware stored secret; and the first stage key encrypted by the hardware stored secret; wherein the hardware stored secret is inaccessible to all execution stages, and the first stage key being inaccessible to all execution stages when executed on the device other than the first execution stage, the device further configured to execute the first execution stage upon start-up or reboot, the method further comprising: enabling the first execution stage to have access to a first stage key further comprising, prior to execution of the first execution stage, decrypting the encrypted first stage key based on the hardware stored secret and storing the decrypted first stage key in accessible storage; and disabling the subsequent execution stages access to the first stage key by, prior to execution of any other execution stage, removing of any data representing the decrypted first stage key from the accessible storage, wherein the first stage key is inaccessible by all the execution stages thereafter.

[0055] Preferably, the device has stored thereon: a hardware stored secret; and the first stage key encrypted by the hardware stored secret; the hardware stored secret has been shared with the service hosted by one or more servers; the hardware stored secret is inaccessible to all execution stages; and the first stage key being inaccessible to all execution stages other than the first execution stage, wherein the first stage of execution is executed after a reboot of the device, the method further comprising: receiving, during execution of a subsequent execution stage on the device after establishing communications with a server hosting the service, a secret key refresh request from the server hosting the service, the secret key refresh request comprising a new first stage key encrypted by the hardware stored secret of the service and an indication of a first device counter adjustment; storing the secret key refresh request; initiating reboot of the device; in response to detecting a newly received secret key refresh request from the service, performing a secret key refresh on the device based on the steps of: adjusting the first device counter in line with the indication of the first device counter adjustment; replacing the encrypted first stage key with the encrypted new first stage key; decrypting the encrypted first stage key using the hardware stored secret for use by the first stage of execution; and disabling access to the first stage key prior to execution of any subsequent execution stage on the device.

[0056] Preferably, the device has stored thereon: a device private key and a first stage key, wherein the device is configured to remove access to the first stage key and device private key for all execution stages, when executed on the device, except the first execution stage, the method further comprising: receiving a key update request from the server hosting the service for updating the first stage key of the device, wherein the key update request comprises data representative of a service public key exchange data; storing data representative of the key update request on the device; initiating reboot of the device; in response to detecting a newly stored key update request, performing an update of the first stage key based on the steps of: generating a new first stage key based on a device private key exchange data and the received service public key exchange data; replacing the first stage key with the newly generated first stage key; generating a key update response including data representative of a device public key exchange data derived from the device private key exchange data; and initiating reboot of the device; executing the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first execution stage is executed prior to all execution stages of the device; disabling access to the first stage key and device private key for all other execution stages during or after execution of the first execution stage; and when a subsequent execution stage establishes a communication connection with the server hosting the service, sending the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service.

[0057] Preferably, the device has stored thereon: a hardware stored secret; a device private key encrypted by the hardware stored secret; the first stage key encrypted by the hardware stored secret; a service public key; and a key update counter, wherein the first stage key being inaccessible to all execution stages when executed on the device other than the first execution stage, the method further comprising: receiving a key update request from the server for updating the first stage key of the device, the key update request comprising signed data representative of a service public key exchange data and a key update counter value, the signed data having been digitally signed by the server hosting the service with a service private key corresponding to the service public key; storing data representative of the key update request on the device; initiating reboot of the device; in response to detecting a newly stored key update request and validating the key update request using the service public key, performing an update of the first stage key based on the steps of: updating the key update counter of the device with the received key update counter; decrypting the device private key and first stage key based on the hardware stored secret; generating a new device private key exchange data; generating a new first stage key based on the new device private key exchange data and the received service public key exchange data; removing data representative of the decrypted device private key from the device; encrypting the new first stage key based on the hardware stored secret; and replacing the encrypted first stage key with the encrypted new first stage key; generating a key update response comprising a new device public key exchange data derived from the device private key exchange data and a key update counter value of the device key update counter; executing the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first execution stage is executed prior to all execution stages on the device; and disabling access to the first stage key by removing data representative of the decrypted first stage key and/or newly generated device secret from accessible storage during or after execution of the first execution stage; and when a subsequent execution stage establishes a communication connection with the server hosting the service, sending the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service when the received key update counter value matches the key update counter value of the server hosting the service.

[0058] Preferably, the device has stored thereon: a hardware stored secret; a device private key encrypted by the hardware stored secret; the first stage key encrypted by the hardware stored secret; a service public key; and a key update counter, wherein the first stage key being inaccessible to all execution stages when executed on the device other than the first execution stage, the method further comprising: receiving a key update request from the server for updating the first stage key of the device, the key update request comprising signed data representative of a service public key exchange data and a key update counter value, the signed data having been digitally signed by the server hosting the service with a service private key corresponding to the service public key; storing data representative of the key update request on the device; initiating reboot of the device; in response to detecting a newly stored key update request and validating the key update request using the service public key, performing an update of the first stage key based on the steps of: updating the key update counter of the device with the received key update counter; decrypting the device private key and first stage key based on the hardware stored secret; generating a new device private key exchange data; generating a new first stage key based on the new device private key exchange data and the received service public key exchange data; removing data representative of the decrypted device private key from the device; encrypting the new first stage key based on the hardware stored secret; and replacing the encrypted first stage key with the encrypted new first stage key; generating a key update response comprising a new device public key exchange data derived from the device private key exchange data and a key update counter value of the device key update counter; initiating reboot of the device; executing the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first execution stage is executed prior to all execution stages on the device; and disabling access to the first stage key by removing data representative of the decrypted first stage key and/or newly generated device secret from accessible storage during or after execution of the first execution stage; and when a subsequent execution stage establishes a communication connection with the server hosting the service, sending the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service when the received key update counter value matches the key update counter value of the server hosting the service.

[0059] Preferably, adjusting, after initiating reboot of the device, the first device counter to indicate the key update of the first stage key.

[0060] Preferably, the second counter is adjusted to indicate the reboot of the device.

[0061] Preferably, disabling, after an execution stage has completed executing, access to the execution stage key that was accessible to that execution stage in accessible storage by triggering deletion of the data representative of the execution stage key of that execution stage stored in accessible storage.

[0062] Preferably, storing each generated next stage or one or more subsequent stage key(s) corresponding to the next execution stage or one or more subsequent execution stage(s) in accessible storage for access and use by said each of the execution stage(s) for cryptographic operations during execution of said each execution stage, wherein the first stage key is inaccessible to said next execution stage and any subsequent execution stages.

[0063] Preferably, each of the generated keys may be used by the corresponding execution stage, during execution of the corresponding execution stage, for authentication, encryption and/or decryption operations.

[0064] Preferably, the encryption and/or decryption operations are performed during a communication session between the device and another device, apparatus, or server hosting a service.

[0065] In a second aspect, the present disclosure provides a computer-implemented method of operating a server hosting a service, the service associated with a device operating according to the computer-implemented method according to the first aspect, features thereof, combinations thereof, modifications thereto and/or as described herein, the service including access to storage comprising data representative of a copy of the first stage key associated with the device and a service counter for tracking the device counter of the device, the method comprising: receiving attestation data from the device associated with at least the second execution stage of the device, wherein the received attestation data is generated by the device based on data representative of the first stage key of the device, a device counter and a digest associated with the second execution stage; generating second attestation data for the second execution stage based on data representative of the copy of the first stage key, the service counter and a trusted copy of the digest associated with the second execution stage; performing trust management in relation to the second execution stage and/or the device based on the received attestation data and the generated second attestation data.

[0066] Preferably, the device includes a first execution stage, a second execution stage and one or more subsequent execution stage(s), the method further comprising: receiving attestation data from the device associated with one or more of the subsequent execution stage(s), wherein the attestation data for each execution stage of the subsequent execution stage(s) is based on data representative of a previous stage key of the immediately preceding execution stage to said each execution stage, a device counter, and a digest associated with said each execution stage, wherein the previous stage key is generated by the device during execution of the immediately preceding execution stage; generating, for each execution stage of the one or more subsequent execution stages, attestation data for said each execution stage based on a derived previous stage key, the received device counter or service counter and a trusted copy of the digest associated with said each execution stage; and performing trust management in relation to said each execution stage and/or the device based on the received attestation data for said each execution stage and the generated attestation data for said each execution stage; wherein the second stage key is derived from the copy of the first stage key.

[0067] Preferably, the method further comprising: establishing communications with the device during execution of a current execution stage of the device, wherein the current execution stage is one of the second execution stage or any subsequent execution stage(s); receiving aggregated attestation data associated with multiple execution stages of the device including the current execution stage; and performing trust management in relation to each execution stage of the multiple execution stages based on the received attestation data for said each execution stage of the multiple execution stages and generated attestation data for said each execution stage of the multiple execution stages.

[0068] Preferably, monitoring the device counter based on the corresponding service counter associated with the device and the received device counter; and performing trust management in relation to received attestation data for each execution stage based on an expected behaviour of the device counter in relation to the service counter and/or the received attestation data.

[0069] Preferably, the received attestation data for each execution stage comprises data representative of an attestation code and the device counter associated with said each execution stage, wherein the received attestation code is generated by the device using a message authentication code, MAC, algorithm based on a generated digest associated with said each execution stage, the device counter, and a previous stage key of the immediately preceding execution stage to said each execution stage of the device, the method further comprising for said each execution stage: generating a second attestation code using a MAC algorithm based on a trusted copy of the digest associated with said each execution stage, the received device counter or the service counter, and a derived previous stage key of the immediately preceding execution stage to said each execution stage; comparing the second attestation code with the received attestation code; and performing trust management in relation to said each execution stage of the device based on the comparison of attestation codes.

[0070] Preferably, the method further comprising: comparing the service counter with the received device counter; performing trust management in relation to said each execution stage of the device based on at least the comparison between counters.

[0071] Preferably, the device counter comprises a first device counter and a second device counter, the first device counter for counting the number of times the service requests an update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device, wherein the service counter comprises a first service counter and a second service counter, the first service counter for counting the number of times the service requests an update or shared secret refresh of the device and the second service counter for tracking the number of reboots of the device.

[0072] Preferably, the service counter comprises a first service counter and a second service counter, wherein the first service counter is for counting the number of times the service requests a shared secret refresh of the device, the service adjusting the first service counter before requesting the shared secret refresh of the device, and wherein the second service counter is for counting the number of reboots of the device.

[0073] Preferably, the method further comprising: tracking the device counter of the device based on received attestation data for at least one execution stage of the device, the received attestation data for at least one execution stage including data representative of the current device counter of the device; comparing the first device count of the received current device counter with the first service count of the service counter; performing trust management in relation to the at least one execution stage of the device based on the comparison of the first device count and the first service count; comparing the second device count of the received current device counter with the second service count of the service counter; performing trust management in relation to the at least one execution stage of the device based on the comparison between the second device count and the second service count; and adjusting the service counter by replacing the second service count with the second device count when the second device count value is determined to be following an expected behaviour or trend in relation to the second service count.

[0074] Preferably, performing trust management further includes one or more from the group of: indicating to the service hosted by one or more servers that the second or any other subsequent execution stage of the device is trusted based on the comparison of the received device counter matching the service counter and/or frequency of matches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device is increased to a higher level of trust based on the comparison of the received device counter matching the service counter and/or frequency of matches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device has decreased to a lower level of trust based on a mismatch in the comparison of the received first device counter and the first service counter and/or frequency of mismatches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device has decreased to a lower level of trust based on a mismatch in the comparison of the received second device counter and the second service counter, when the second service counter is greater than the received second device counter, and/or frequency of mismatches of previous comparisons; and any other rule or threshold indicating a level of trust associated with the second or any other subsequent execution stage or the device based on the received device counter and seNice counter.

[0075] Preferably, the method further comprising: adjusting the first service counter for a shared secret refresh of the device; transmitting, to the device, a request for a shared secret refresh of the device, wherein the shared secret refresh request includes data representative of the first service counter, wherein the device replaces the first device counter with the received first service counter in response to receiving the shared secret refresh request and/or when the device performs the shared secret refresh.

[0076] Preferably, the method further comprising: receiving, from the device, a attestation data comprising data representative of a second device counter value; and replacing the second service counter value of the service counter with the received second device counter value when the received second device counter value is determined to be following an expected behaviour or trend in relation to the second service counter value.

[0077] Preferably, the device counter is a monotonically increasing counter and the method further comprising: determining whether the device counter is monotonically increasing in relation to the service counter; and performing trust management in relation to the at least one execution stage of the device or the device based on the determination of whether the device counter is monotonically increasing.

[0078] Preferably, the device counter is a monotonically decreasing counter and the device counter is decremented rather than incremented, the method further comprising: determining whether the device counter is monotonically decreasing in relation to the service counter; and performing trust management in relation to the at least one execution stage or the device based on the determination of whether the device counter is monotonically increasing.

[0079] Preferably, performing trust management based on the received attestation data associated with said second and/or any subsequent execution stage(s), further comprises performing trust management based on one or more from the group of: indicating to the service that an execution stage of the device is trusted based on the comparison of received and generated attestation codes for the execution stage matching and/or frequency of matches of previous comparisons based at least on the data representative of the attestation data for said execution stage; indicating to the service a trust level associated with an execution stage of the device is increased to a higher level of trust based on the comparison of received and generated attestation codes for the execution stage matching and/or frequency of matches of previous comparisons based at least on the data representative of the attestation data for said execution stage; indicating to the service a trust level associated with an execution stage of the device has decreased to a lower level of trust based on a mismatch in the comparison of received and generated attestation codes for the execution stage and/or frequency of mismatches of previous comparisons based at least on the data representative of the attestation data for said execution stage; and any other rule or threshold indicating a level of trust associated with the execution stage of the device based at least on the data representative of the attestation data for said execution stage.

[0080] Preferably, the method further comprising: generating a stage key for a subsequent execution stage(s) of the device based on a previously generated stage key of the immediately preceding execution stage and the service counter, wherein the second stage key is generated based on the copy of the first stage key; storing the generated stage key for said subsequent execution stage for use with authentication, encryption and/or decryption operations during execution of the subsequent execution stage on the device.

[0081] Preferably, generating the stage key for the subsequent execution stage further comprises using a key derivation function to generate said stage key for the subsequent execution stage based on the previously generated stage key and the service counter, wherein the second stage key is generated using a key derivation function based on the copy of the first stage key and the service counter.

[0082] Preferably, the authentication, encryption and/or decryption operations are performed during a communication session between the device and the server hosting the service during execution of the at least one execution stage on the device using keys generated for the at least one execution stage of the device.

[0083] Preferably, the device includes a number of Msequential execution stages, where /<=m<=M, the method further comprising: generating an (m+1)-th stage key for the (m+1)-th execution stage based on an m-th stage key generated for the m-th execution stage; storing the (m+1)-th stage key in accessible storage for use in cryptographic operations including encryption/decryption or attestation operations with the device in relation to the (m+1)-th execution stage, wherein, when m=1, the generated 1-th stage key corresponds to data representative of the copy of the first stage key and the 1-th execution stage corresponds to the first execution stage of the device.

[0084] Preferably, as an option, generating the (m+1)-th stage key in relation to the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the m-th stage key.

[0085] Preferably, as an option data representative of the copy of the first stage key is a stored secret shared with the device, when m=/, generating the (m+1)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+1)-th stage key based at least on the 1-th stage key and the service counter, wherein 1-th stage key is data representative of the copy of the first stage key.

[0086] Preferably, as an option, generating data representative of the copy of the first stage key based on a key derivation function with a stored secret and the service counter, wherein the stored secret is shared between device and server.

[0087] Preferably, generating the (m+/)-th stage key for the (m+V-th execution stage further comprises using a key derivation function to generate said (m+1)-th stage key based at least on the m-th stage key and the service counter.

[0088] Preferably, receiving, from the device, (m+1)-th attestation data for the (m+1)-th execution stage, the attestation data for the (m+1)-th execution stage based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage; generating second (m+1)-th attestation data based on the generated m-th stage key, the received device counter or service counter and a trusted copy of the digest associated with the (m41)-th execution stage; and performing trust management in relation to the (m+/)-th execution stage of the device based on the received (m+1)-th attestation data and the second (m+1)-th attestation data.

[0089] Preferably, the server hosting the service has stored thereon: a hardware stored secret, wherein the hardware stored secret has been shared with the device; and a copy of the first stage key of the device; the method further comprising: generating a new first stage key; transmitting, during execution of a subsequent execution stage on the device after communications has been established between the device and the server hosting the service, a secret key refresh request to the device, the secret key refresh request comprising a new first stage key encrypted by the hardware stored secret of the service and an indication of a first device counter adjustment; and updating the copy of the first stage key with the new first stage key.

[0090] Preferably, the device has stored thereon: a hardware stored secret; a private key encrypted by the hardware stored secret; and a first stage key encrypted by the hardware stored secret, wherein the service has a public key and a corresponding private key, the device has a public key and a corresponding private key, the service has a copy of the public key of the device and the device has a copy of the public key of the service, the method further comprising: generating a new service private key exchange data, a new service public key exchange data based on the service private key exchange data, and a key update counter value; transmitting a signed key update request to the device, the signed key update request comprising data representative of the new service public key exchange data and the key update counter value, wherein the signed key update request is signed by the private key of the service, wherein the device is configured to receive the key update request, validate the received signed key update request with the public key of the service, confirm the received key update counter value has been adjusted as expected in relation to the key update counter of the device, use the new service public key exchange data and a new device private key exchange data to generate a new first stage key, update a key update counter on the device with the received key update counter value; receiving a signed key update response from the device, the key update response comprising the new device public key exchange data derived from the new device private key exchange data, and a key counter update value of the key update counter of the device, the signed key update response signed by the private key of the device, wherein the device computed a new first stage key based on the new device private key exchange data and the new service public key exchange data; in response to validating the signed key update response with the public key of the device and determining that the received key update counter value matches the key update counter value of the service, performing the steps of: generating a new first stage key based on the received new device public key exchange data and the new service private key exchange data; and replacing the copy of the first stage key with the new first stage key.

[0091] Preferably, retrieving a copy of the first stage key from a key manifest or list associated with the manufacturer of the device.

[0092] In a third aspect, the present disclosure provides an apparatus comprising a processor unit, a memory unit and a communication interface, the processor unit connected to the memory unit and communication interface, wherein the apparatus is adapted or configured to implement the computer-implemented method according to the first aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[0093] In a fourth aspect, the present disclosure provides an apparatus associated with hosting a service comprising a processor unit, a memory unit and a communication interface, the processor connected to the memory and communication interface, wherein the apparatus is adapted or configured to implement the computer-implemented method according to the second aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[0094] In a fifth aspect, the present disclosure provides a system comprising: one or more devices according to the apparatus of the third aspect, features thereof, combinations thereto, modifications thereto and/or as described herein; one or more servers hosting a service according to the apparatus of the fourth aspect, features thereof, combinations thereto, modifications thereto and/or as described herein; wherein the one or more devices are configured to perform one or more cryptographic operation(s) or activity(ies) and/or are configured to communicate with the service hosted by one or more servers and perform one or more cryptographic operation(s) or activity(s) therebetween.

[0095] In a sixth aspect, the present disclosure provides a system comprising: one or more devices configured according to the computer-implemented method according to the first aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein; one or more servers hosting a service and configured according to the computer-implemented method according to the second aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein; wherein the one or more devices are configured to communicate with the service using encrypted communications based on corresponding keys accessible to those execution stages of the devices and/or for sending attestation data to the service.

[0096] In a seventh aspect, the present disclosure provides a computer-readable medium comprising computer readable code or instructions stored thereon, which when executed on a processor, causes the processor to implement the computer-implemented method according to the first aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[0097] In an eighth aspect, the present disclosure provides a computer-readable medium comprising computer readable code or instructions stored thereon, which when executed on a processor, causes the processor to implement the computer-implemented method according to the second aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[0098] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0099] This application acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[00100] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Brief Description of the Drawings

[00101] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which: [00102] Figure la is a schematic diagram illustrating an example attestation system according to the invention; [00103] Figure lb is a flow diagram illustrating an example device attestation process according to the invention; [00104] Figure lc is a flow diagram illustrating an example service attestation process for a service according to the invention; [00105] Figure ld is another schematic diagram illustrating another example attestation system according to the invention; [00106] Figure le is another schematic diagram illustrating another example attestation system with a first stage key refresh according to the invention; [00107] Figure 2a is a schematic diagram illustrating iterative generation of attestation data and next stage keys on a device with multiple execution stages according to the invention; [00108] Figure 2b is a flow diagram illustrating an iterative key generation process for a device according to the invention; [00109] Figure 2c is a flow diagram illustrating another example iterative key generation process for use in cryptographic operations with a device with M executable stages; [00110] Figure 2d is a flow diagram illustrating another example iterative key generation and attestation process for use with a device with M executable stages, [00111] Figures 3a and 3b are a flow diagram illustrating an example attestation and key generation process for an loT device and corresponding service according to the invention; [00112] Figures 3c and 3d are a flow diagram illustrating a refresh key process for refreshing a key according to the invention; and [00113] Figure 4 is a schematic diagram illustrating an example computing system for a device and/or service according to the invention.

[00114] Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description

[00115] Embodiments of the present invention are described below by way of example only. These examples represent the best mode of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[00116] The inventors propose a hybrid attestation mechanism and/or key generation mechanism for use on constrained devices configured to operate with a service hosted by one or more servers. The constrained devices have multiple sequential or consecutive execution stages in which there is no separation of privilege. The first execution stage, which may include an initial bootioader, is trusted and operates on a first stage key such as a hardware stored secret and also a device counter for generating attestation data and/or next stage keys for use by the next execution stage. The first stage key (e.g. hardware stored secret) is only accessible to the first execution stage during execution and inaccessible thereafter. For example, the hardware stored secret may be a number which is securely stored in the device, e.g. burnt in device on manufacture, and configured to be accessible only to the first execution stage.

[00117] The device counter is configured to be adjusted (e.g. incremented or decremented) on each reboot of the device and may be similarly adjusted (e.g. incremented or decremented) in response to a request by the service or server hosting the service. Data representative of the second and/or one or more subsequent execution stage(s) is stored on the accessible read/writeable device memory. The attestation data for the second execution stage and/or second stage keys are generated and stored by the first execution stage in the accessible memory of the device. The second or each subsequent execution stage computes a next stage key for the next execution stage and attestation data for the next execution stage. Each of the execution stages may store the attestation data for the next execution stage computed on the device for later use. Thus, the attestation data for each execution stage may be aggregated until it is required for remote attestation by the service hosted by one or more server(s) i.e. when a network/communication connection is established between device and the server(s) hosting the service. The next stage keys may also be stored in accessible memory used for authentication and/or cryptographic operations such as, by way of example only but not limited to, authentication, encryption/decryption operations based on the next stage keys when the device communicates with the server or service.

[00118] For example, once the device establishes a network connection and/or communications have been established with the server or service hosted by a server performing remote attestation of the device, the device may send the aggregated attestation data of one or more execution stages to the server of the service. The server of the service may process the aggregated attestation data to determine an indication of trust of the device and/or each execution stage of the device. In another example, should the device establish network connectivity quickly or immediately with the server and/or service, then each subsequent execution stage may either send attestation data associated with that execution stage to the service for use in attesting or determining an indication of trust of the device and/or that execution stage.

[00119] In a further example, the device may store/aggregate the attestation data generated for successive execution stages (or stages of execution) for later use or later remote attestation of the device once or after networking/communications is established or available between device and the server hosting the service. Alternatively or additionally, when networking between device and server is established, the attestation data for each execution stage may be generated and stored by the immediately preceding execution stage. The attestation data for each execution stage may then be sent, when said each execution stage executes, to the service hosted by one or more servers for attesting that the device and/or that said each execution stage is trustworthy or not.

[00120] The first execution stage that is executed by the device may be, by way of example only but is not limited to, an initial bootloader, which is assumed to be trusted code. During execution of the initial bootloader, attestation data for the next execution stage and/or next stage keys may be generated based on a first stage key such as a hardware stored secret. When the initial bootloader of the first execution stage finishes its checking and generation of attestation data for the next execution stage and next stage keys, access to the first stage key is removed prior to the device "jumping" into executing said next execution stage, which may be firmware and/or application code that are more likely to contain vulnerabilities. The body of code of firmware/applications and/or further bootloaders of subsequent execution stages is typically much larger than that of the initial bootloader of the first execution stage. Such firmware/applications and/or further bootloaders are likely to be less validated and/or have security bugs or holes which allow such code to be modified or even replaced. As such, the next and any subsequent execution stage will require attestation with the service each time the device operates.

[00121] Furthermore, an attacker who manages to tamper with the device at the second or subsequent execution stage(s) can only get access to the next stage keys (i.e. application keys or device keys) but is incapable of accessing the first stage key (e.g. hardware stored secret). Thus, when the device is rebooted, the device adjusts (e.g. increments/decrements) the device counter, and thus generates new attestation data and new next stage keys and so has to prove its integrity again with the service. This is because, whatever occurs after the first execution stage (e.g. initial bootloader, which is trusted code) has completed, the first stage key (e.g. hardware secret key) is not accessible to or visible to the microcontroller/processor or second or subsequent execution stages during execution, as it is no longer accessible after the first execution stage completes execution.

[00122] The invention provides boot time attestation for a constrained device using, by way of example only but is not limited to, hash-based key derivation function (HKDF) on keys or passwords in which a secret (e.g. a key) plus a device counter (or changing value or nonce) are used to generate derived key(s). For example, initially the device counter may be used in the first execution stage to generate the one or more next execution stage derived key(s), whilst the device counter is not used in the next and/or subsequent execution stage(s) when generating subsequent execution stage key(s) and the like. Derived key(s) may be based on hash-based key derivation function (HKDF) or KDF, where the secret is made inaccessible to subsequent execution stages of the device prior to execution of the subsequent execution stages.

[00123] With a device with multiple stages of execution, the initial execution stage has access to an initial secret (or a first stage key), and uses it to compute a new derived key (e.g. a new next stage key) for use by the next execution stage, where the initial secret (e.g. first stage key) is made inaccessible to the other execution stages. The next execution stage uses its new derived key (e.g. the next stage key) and/or input data (e.g. key usage parameters) to generate another derived key (e.g. another next stage key) for the next execution stage and makes its derived key (e.g. the next stage key) inaccessible. This process may be iterated for subsequent execution stages.

[00124] Although a next stage key or subsequent stage key is described as being generated based on a first stage key or next stage key, respectively, this is for simplicity and by way of example only, it is to be appreciated by the person skilled in the art that there may be a set of one or more first stage key(s) used to derive or generate a set of one or more next stage key(s), which are used to derive or generate a set of one or more subsequent stage key(s) and so forth and/or as the application demands. By having each execution stage generate a set of keys for the immediate subsequent execution stage allows each execution stage to get a unique execution stage key or a unique set of execution stage key(s) at runtime for the device and/or for use in cryptographic operations and/or applications in, by way of example only but not limited to, authentication, attestation, digital signature, encryption/decryption, and/or any other cryptographic operation or process in which keys and the like are used as the application demands. In attestation, the attestation mechanism and/or key generation mechanism for a device that has different stages of execution of decreasing trust, allowing each execution stage to use a secret for generating a new secret for next execution stage and a proof of what the next execution stage is.

[00125] The constrained device may use the stage keys generated by the immediately preceding execution stage for attestation, authentication, encryption and/or decryption during a communication session with a trusted device such as, by way of example only but not limited to, a server hosting a service that the constrained device is configured to operate, communicate with and/or exchange data with and the like. The trusted device is configured to have a copy of the hardware stored secret or first stage key(s) of the constrained device, which have been previously and securely shared with the trusted device or between the trusted device and the constrained device. The constrained device may be configured to send the device counter used for iteratively generating the next stage key(s) or an encrypted version of the device counter (e.g. encrypted using the hardware stored secret or first stage key) to the trusted device enabling the trusted device to use the copy of the hardware stored secret and/or first stage key(s) and received device counter to iteratively generate each set of execution stage key(s) for each execution stage. This enables the trusted device and constrained device to perform tasks, cryptographic operations and the like and/or as the application demands that require the same set of execution stage key(s) to be used at the trusted device and the constrained device. Alternatively or additionally, the trusted device may be a server hosting a service and may use a server/service counter, which is akin to a trusted device counter and is referred to herein as service counter, that is configured to track the device counter based on the number of reboots, and/or updates sent from the trusted device, thus, the received device counter may be used to check whether the server/service counter matches and if so, be used in the iterative key generation mechanism when generating the first stage, second stage and next execution stage key(s) at the trusted device.

[00126] For example, the trusted device may be, without limitation, for example a server of a service that is configured to perform an attestation protocol with the constrained device and may be required to process attestation data associated with each execution stage generated by the constrained device to determine an indication of trust of the constrained device and/or each execution stage of the constrained device. The attestation data associated with each execution stage may be generated by the immediately preceding execution stage on the constrained device using the immediately preceding stage key(s) in an iterative manner similar to the iterative generation of execution stage keys. As previously described, the server of the service may be configured to iteratively generate the execution stage keys for each execution stage of the constrained device, and so may use these to determine a level of trust (or an indication of trust) of the constrained device based on the received attestation data of each execution stage. In another example, the server of the service may be configured to securely communicate with the constrained device, and so, may be configured to generate the required execution stage key that the constrained device is using for cryptography operations during the communication session with the server hosting the service. For example, the device and server hosting the service may use TLS for secure communications.

[00127] Figure la is a schematic diagram illustrating an example attestation system 100 according to the invention. The attestation system 100 includes a constrained device 102 and a remote service 104 (i.e. a trusted device) hosted by one or more servers. The one or more servers may be distributed and/or networked to form a cloud platform 103. The device 102 may communicate with the service 104 over a communications network. The device 102 and the service 104 hosted by one or more server(s) are configured to perform an attestation protocol in which the service 104 can determine whether the device 102 may be trusted or not. The attestation protocol is used for proving to the remote service 104 that the device 102, by way of example only but is not limited to, is what it says it is and/or is executing or running software (e.g. bootloaders and/or application firmware) it says it is using. For example, the device 102 is a constrained device such as, by way of example only but is not limited to, an Internet of Things (loT) device or a sensor device with access to the Internet or a communication network and is configured to, by way of example only but is not limited to, upload data to the remote service 104. However, in order for the remote service 104 to trust the uploaded data, the device 102 needs to prove to the service 104 that the device 102 is what it says it is and/or the software and data stored on the device 102 has not been tampered with and the like.

[00128] The device 102 may include one or more processor core(s) or unit(s) (not shown), volatile and/or non-volatile memory including, by way of example only but not limited to: a secure memory storage 107 such as, by way of example only but not limited to, a read-only-memory (ROM) for storing trusted code such as, by way of example only but not limited to, an initial bootloader 107a and/or other trusted code 107b; a non-secure memory storage 108 (e.g. application and/or data memory) for storing one or more application firmware(s) 110 (e.g. applications, further bootloaders, drivers, network code and the like) and/or for storing data and/or results from processed data and the like; one or more registers for storing, by way of example only but not limited to, a hardware stored secret 112 and/or a device counter 114.

The one or more registers for storing the hardware stored secret 112 and/or device counter 114 may be non-volatile storage based to ensure hardware stored secret 112 and/or device counter 114 values persist across reboots and/or power cycles of the device 102. The device 102 may also include a communication interface (not shown) for connecting to and communicating with the server(s) hosting the service 104. The one or more processor core(s) are connected to the volatile and/or non-volatile memory, ROM, and/or register(s) or storage one or more registers and/or memory storage 108, and the communication interface. The service 104 may be hosted by a cloud-based system 103 that includes one or more servers networked together, in which the one or more servers provide the storage and processing capacity necessary for the service 104 to operate on data received from device 102.

[00129] As described previously, the device 102 is a constrained device that may comprise or represent any device without or lacking a mechanism for privilege execution separation such as, by way of example only but not limited to, a device configured to and/or capable of executing two or more executable stages sequentially. For example, sequentially executing a first executable stage 106a, a second executable stage 106b, a third executable stage, and so forth. For example, the constrained device 102 according to the invention may include, by way of example only but is not limited to, embedded devices, real-time operating system devices, smart meter(s), an loT device, smart home appliance(s), CCTV cameras, embedded sensors in industrial plants or power plants, smart TV, one or more sensor(s), small form factor devices, automotive system devices, safety critical systems, communication devices any other device that is constrained in terms of, by way of example only but not limited to, processing capacity and/or memory capacity, and/or has very constrained operating environments, constrained memory, processing power, and/or battery power, and/or has sequential executable stages in which there is no separation of privilege, and/or any other constrained device with access to a communication network for uploading data to a service 104 for subsequent processing and/or storage and the like.

[00130] Given this, the device 102 may be configured to be limited to have two or more execution stages or multiple execution stages in which each execution stage consecutively or sequentially executes after a previous execution stage has completed execution. The device 102 may be further configured to not require different levels of privileges and does not provide runtime separation of privileges. In this example, the constrained device 102 includes at least a first execution stage 106a (e.g. Stage 1) that includes execution of the initial bootloader 106a and a second execution stage 106b (e.g. Stage 2) that includes execution of at least part or all of the application firmware 110 for operating the device 102. The device 102 may include further execution stages that include, by way of example only but is not limited to, further bootloader(s) and/or further application firmware (e.g. service drivers, network code, and other application code and the like) and the like and/or as the application demands. Each execution stage may be associated with a corresponding set of computer code, instructions and/or logic stored on the device 102 that is configured to execute on the device 102, e.g. via processing core(s) and/or other hardware, during execution of said execution stage. Each execution stage consecutively or sequentially executes on the device 102 after the previous execution stage has completed execution. In this example, the first stage of execution 106a executes the initial bootloader 107a and the second execution stage 106b executes at least some or all of the application firmware 110.

[00131] The first execution stage 106a comprises executable data in the secure memory 107 that is configured to be trusted and includes execution of the initial bootloader 107a or trusted code 107b for starting the device 102 and subsequent execution stage(s) 106b. The instruction code or data representative of the first execution stage 106a (e.g. the initial bootloader) is stored in the secure memory 107 such as, by way of example only but not limited to, ROM or other read-only logic or trusted component or portion of the device 102. Thus, the initial bootloader 107a may be trusted code that is booted from ROM as the first stage of execution 106a (or first execution stage), in which the data representative of the initial bootloader 107a cannot be changed. However, the second execution stage 106b and/or any subsequent execution stage(s) may include, by way of example only but is not limited to, other bootloader(s) and/or application firmware(s) that may be based on a larger set of computer code/instructions, which may be more vulnerable, less validated, and/or have security bugs or holes and the like, and so may be considered untrusted code and/or less trusted or untrustworthy. This is because the data representative of the subsequent execution stages such as, without limitation, for example application data 110 of the second execution stage 106b is typically stored in non-secure memory 108 such as application/data memory 108. Application memory 108 may be read/writeable memory and may be accessible and read/writeable by any other execution stage and the like. In this example, a second execution stage 106b includes the application firmware 110, which may include, by way of example only but is not limited to, drivers, network code and the like.

[00132] For example, the second and any subsequent execution stages 106b are typically considered to be less trusted because they include more complex instructions/code/firmware compared with the initial bootloader 107a of the first execution stage 106a. Essentially, an initial bootloader 107a of a secure memory (e.g. a ROM bootloader) is verified or de-bugged to the same standard as a processor core itself because it cannot be replaced or updated. Such initial bootloaders 107a are typically kept as simple as possible and is heavily verified and placed in secure memory or trusted code. Given this, the first execution stage 106a is typically guaranteed not to be able to be changed. This provides the advantage that an attacker or malicious entity/code and the like cannot replace or re-code the first execution stage 106a comprising data representative of the initial bootloader 107a and/or trusted code 107b. This allows the first stage of execution 106a to be considered as having a higher level of trust, i.e. trusted, compared with application firmware 110 and/or other code/instructions and the like stored in application memory 108.

[00133] The second execution stage 106b is considered to be less trusted than the first execution stage 106a. For example, application firmware 110 stored in application memory 108 that is typically read/write memory that is accessible, readable and writable and so can be modified, and/or maliciously changed by other actors. Thus, each subsequent execution stage may have a different and decreasing level of trust associated with it. This means a service 104 hosted by one or more server(s) may not be able to "blindly" trust the operation of constrained device 102 after it has booted from the trusted first execution stage 106a. The attestation protocol according to the invention is used for determining by the service 104 whether the device 102 and/or one or more subsequent execution stages of the device 102 may be trusted by the service 104 hosted by one or more server(s). For example, in this respect, an application firmware update is a double-edged sword: devices need to be updatable in order to fix software vulnerabilities, however using a rewritable non-volatile storage technology (e.g. Flash) 108 enables the application firmware to be updateable to fix software vulnerabilities and/or software bugs and the like, but this also brings the risk that an attacker, malicious entity and/or malicious code may be able to modify the application firmware code and the like of any executable stage 106b that is held in non-secure memory 108 or re-writable memory 108 and the like. Thus, an iterative attestation protocol that uses the iterative key generation mechanism as described herein mitigates this risk and enables a service 104 hosted by one or more server(s) to establish a level of trust in relation to device 102.

[00134] The device 102 is configured to have a hardware stored secret 112 stored thereon in non-volatile memory (NVM) or within logic on the hardware of the device 102 in which the hardware stored secret 112 may be retrieved even after the device 102 having been power cycled, rebooted and the like. For example, the hardware stored secret 112 may be placed or put into a one-time programmable (OTP) ROM or a masked ROM on the device 102 at the time of manufacture of the device 102. The manufacturer may also store a copy of the hardware stored secret 112 in a manifest or list including data representative of a mapping between the device 102 and the hardware stored secret 112. The manifest or list may be made available to the server hosting the service 104 to allow the service 104 access to a trusted copy of the hardware stored secret 112. The hardware stored secret 112 may be data representative of a secret number or value that may be set at the time the device 102 is manufactured and is protected, by hardware/software components of the device 102, from unauthorised access. For example, the hardware stored secret 112 may be, by way of example only but not limited to, any type of data or value depending on the size of the register or memory that is available on the device for securely storing it. In another example, the hardware stored secret 112 may be, by way of example only but not limited to, a value or data representative of a symmetric cryptography key (e.g. key size of 128 to 256 bits), or data representative of an asymmetric non-elliptic curve cryptography (ECC) key (e.g. key size of 2048 bits or more), or data representative of an asymmetric ECC key (e.g. key size of 384 bits or more). Although several key sizes are described, by way of example only but is not limited to, for use in relation to the hardware stored secret 112, it is to be appreciated by the skilled person that the hardware stored secret 112 may be of any suitable size or value depending on the requirements and/or specifications of the registers and/or device on which it is to be securely stored, accessed and used by the device 102 and/or as the application demands.

[00135] The device 102 may be further configured for enabling the first execution stage 106a, when executing, to have access to the hardware stored secret 112 and also for disabling access to the hardware stored secret 112. Thus, the hardware stored secret 112 may be secured and configured to be accessible by the initial bootloader 107a of the first execution stage 106a. For example, the device 102 may enable the initial bootloader or first execution stage 106a to have access to the hardware stored secret 112 during execution of the first execution stage 106a and then making the hardware stored secret 112 inaccessible thereafter, where it is inaccessible to subsequent execution stages. For example, the device 102 may disable access by the initial bootloader or first execution stage 106a prior to execution of application firmware of the second execution stage 106b and the like.

[00136] For example, the constrained device 102 may have its memory storage partitioned into secure and non-secure memory, in which the hardware stored secret 112 is stored in the secure memory and the application firmware 110 and/or associated data and the like is stored in non-secure memory 108 such as an application and/or data memory. The first execution stage 106a may have access to the secure memory 107 onto which the hardware stored secret 112 is stored, whereas all execution stages may have access and/or use the non-secure memory 108 such as application and/or data memory. The first execution stage 106a or bootloader 107a may be configured to have access to everything on the device 102 including the hardware stored secret 112, and then be configured to protect the hardware stored secret 112 and make it non-accessible to subsequent execution stages 106b and/or future executable code (e.g. application firmware, network code, other bootloaders and the like). Enabling access and disabling access to the hardware stored secret 112 may be implemented based on, by way of example only but is not limited to, one or more from the group of: memory management units; one or more register(s) storing the hardware stored secret 112 in which the register(s) have a control bit for turning access off to the register(s) holding the hardware stored secret 112, but in which access is turned on based on a reset of the device 102; or any other logic, hardware/software that may be used to enable the first stage of execution access to the hardware stored secret 112, but which is inaccessible thereafter or prior to execution of subsequent execution stages.

[00137] In other examples, the hardware stored secret 112 may be stored in a non-volatile memory region or register that is configured to be only accessible whilst executing the initial bootloader of the first execution stage 106a. The first execution stage 106a is stored in, by way of example only but is not limited to, a secure memory 107such as a ROM. So as long as running from the secure memory 107, then the non-volatile memory region or register can be accessed and hence the hardware stored secret 112 accessed. The secure memory 107 may include data representative of the initial bootloader of the first execution stage 106a and also the hardware stored secret 112, when the execution of the initial bootloader finishes, then the non-volatile memory storing the hardware stored secret 112 becomes inaccessible.

In another example, the hardware stored secret 112 may be stored in non-volatile memory with a register in front of it. On a reset/reboot of the device 102, the device loads the register with the hardware stored secret 112 from the non-volatile memory, the register is writeable so it can be cleared so that it becomes inaccessible at the appropriate time prior to execution of the second execution stage 106b. It is made inaccessible to all execution stage(s) during execution of the first execution stage 106a and/or after the first execution stage 106a completes execution. In a further example, a pad of the non-volatile memory holding the hardware stored secret 112 may be configured to be accessible by regular reads, and configured to be inaccessible, when a bit is written to a control register, such that the read access disappears and so the hardware stored secret 112 cannot be accessed as the written bit to the control register is configured to not clear unless there is a reboot of the device 102. In another example, some hardware on the device 102 may be configured, as part of the reset process, to copy the contents of a non-volatile memory storing the hardware stored secret 112 into regular RAM or non-secure memory 108 where the non-volatile memory is not accessible by the processor, and to make the hardware stored secret 112 inaccessible again it may be overwritten in the non-secure memory 108. Although several examples of storing and/or accessing the hardware stored secret 112 have been described, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that any other suitable hardware, mechanism and/or method may be used for securely storing the hardware stored secret 112 on the device and securely controlling access to the hardware stored secret 112 such that it is accessible for use by the first execution stage 106a during execution but inaccessible to any subsequent execution stage 106b and/or as the application demands.

[00138] In this example, the constrained device 102 also includes a trusted component or trusted attestation component or module 114-120 based on logic, hardware and/or software that is configured to perform an attestation protocol with the service 104. The trusted attestation component or module may be implemented as part of the first stage of execution, implemented as part of each stage of execution, and/or implemented independently of the first stage of execution and subsequent stages of execution, but which controls the necessary logic and/or hardware/software components required to perform an attestation protocol with the service 104.

[00139] For example, the constrained device 102 is configured to retrieve the hardware stored secret as a first stage key (or a device key) accessible to the initial bootloader of the first execution stage 106a. During execution of the initial bootloader of the first execution stage 106a, the first execution stage 106a performs: 1) a measurement of the subsequent execution stage 106b (e.g. generates a digest of the subsequent execution stage 106b). As an option, the first execution stage may verify the signature or message authentication code (MAC) of the subsequent stage 106b; 2) adjustment of the device counter 114 based on a known pattern or expected manner (e.g. increment, decrement of the counter); 3) storing the measurement of the subsequent execution stage, the device counter 114 any other attestation data such as, by way of example only but not limited to, device epoch and/or device identifier in a cryptographic or attestation container; 4) performs a MAC calculation, attaching the tag (e.g. "MAC") to that container, which may be referred to herein as an attestation code or Tag; and 5) computes a next-stage key for the subsequent execution stage 106b that will execute after the first execution stage 106a and places the next stage key in memory 108 that is accessible to the subsequent execution stage 106b (e.g. the next stage's memory); 6) eliminates access to the first stage key and/or hardware stored secret 112 such that it is inaccessible to any subsequent execution stage; and 7) forwards control or execution to the next subsequent execution stage 106b of the device 102. The subsequent execution stage 106b of the device 102 then performs steps 1) and 3)-7) in relation to any further subsequent execution stage that will execute, where any more measurements and attestation data and another tag or attestation code, excluding the counter data, are appended to the cryptographic container. Once the device 102 has established communications with the server hosting the service 104 (e.g. at some later stage), then the aggregate cryptographic or attestation container that includes all measurements of subsequent execution stage(s) and all tags/attestation codes may be forwarded to the service 104 for performing attestation of the device 102. Thus, the service 104 is able to use the received aggregate attestation measurements to determine an indication of whether the device 102 is trusted or not. No later execution stage can access the first stage key (e.g. hardware stored secret) or counter value, and each counter value can be expired based on application policies, for example: once per connection, once per reboot, once per day, once per month, etc. [00140] The trusted attestation component 114-120 includes, by way of example only but is not limited to, a device counter 114, a message authentication code (MAC) function 116, and/or digest generation function 120. The MAC function 116 may be based on, by way of example only but not limited to, keyed-hash message authentication function, or any other MAC involving a cryptographic hash or digest function and secret cryptographic key, and/or any other MAC function as the application demands. Initially, the attestation component 114120 is configured to generate attestation data for use by the service 104 in attesting the device 102. In this example, the attestation component takes a measurement of the second stage of execution or application firmware 110 by using a digest generation function 120 (e.g. a hash function) to generate a digest of the second stage of execution or application firmware 110. The firmware/software 110 prior to execution is simply treated as data in application memory 108, so that a digest may be calculated by passing the data representative of the application firmware/software 110 through the digest generation function 120 (e.g. a hash function) prior to and/or in the initial stages of execution of the second stage of execution 106b. The attestation component may then generate a message authentication code, which is referred to herein as a tag or an attestation code, based on the hardware stored secret 112, the digest of the data representative of the second stage of execution or application firmware 110 and the device counter 114.

[00141] The device counter 114 may be configured, adjusted and updated to track the number of reboots of the device 102 and/or device key refreshes of the device 102 and the like. The device counter 114 may be adjusted in a known or expected manner, which allows the service 104 hosted by one or more server(s) to also track the expected behaviour of the device counter 114. For example, the device counter 114 may be configured to be either a monotonically increasing counter or a monotonically decreasing counter. In this example, it is assumed to be a monotonically increasing counter.

[00142] The hardware stored secret 112, the digest of the second execution stage 120, and the device counter 114 are input to the MAC function 116 for generating a tag/attestation code 122a associated with the second execution stage 106b. The attestation data 122a-122c includes data representative of the tag/attestation code 122a associated with the second execution stage 106b, the digest 122b associated with the second execution stage 106b used to generate the tag/attestation code 122a, and the device counter value 122c used to generate the tag/attestation code 122a. The attestation data 122a-122c may be stored in non-secure memory 108 prior to sending to the server hosting the service 104 for performing attestation of the device 102. The attestation data 122a-122c may be sent to the service 104 after the device 102 has established network connectivity or communications with the server hosting the service 104. Although the digest 122b of the second execution stage 106b is shown to be sent to the service 104 as part of the attestation data 122a-122c, it is to be appreciated by the skilled person that only the attestation data corresponding to the tag/attestation code 122a in relation to each subsequent execution stage 106b and the device counter 122c need be sent to the server hosting the service 104. This is because the server hosting the serviced 104 can have a trusted copy of the digest of each stage of execution 106b of the device 102. For example, at the time of manufacture or programming of the application firmware 110, the manufacturer/programmer may generate a manifest of the digest in relation to each execution stage of the device 102, which may then be accessed and used by the service 104 when performing attestation of the device 102.

[00143] The attestation data 122a-122c may be stored in memory 108 by the initial bootloader of the first execution stage 106a for access and sending of the required portions of attestation data 122a-122c by subsequent execution stages 106b after the device 102 has established communication with service 104. This may be because the initial bootloader of the first execution stage 106a may not have the capability to connect with the service 104 and send an attestation data in relation to subsequent execution stages 106b of the device based on the stored attestation data 122a-122c. In which case, when the initial bootloader of the first execution stage 106a completes and boots the application firmware associated with the second execution stage 106b, the application firmware may, as part of the attestation protocol, connect with service 104 and send stored attestation data 122a-122c (or portions of attestation data 122a and 122c) to the service 104, or an aggregation of the attestation data in relation to each subsequent execution stage at a later time.

[00144] The service 104 is configured to receive the attestation data in relation to the second execution stage 106b and determine or attest, based on the received attestation data 122a- 122c (or attestation data 122a and 122c), whether the device 102 and/or the second execution stage 106b of the device 102 is to be trusted or not. In order to do this, the service 104 is configured to have access to a secure copy of the hardware stored secret 112 of the device 102, referred to as hardware stored secret 126 and/or a trusted copy of the digest in relation to the second execution stage 106b and/or each execution stage of the device 102. The hardware stored secret 112 and/or digest in relation to each execution stage of the device 102, may be, by way of example only but is not limited to, pre-provisioned from a database or manifest during manufacture and/or configuration of the device 102, derived from a master key known to the service 104. For example, a manufacturer of the device 102 may generate the hardware stored secret 112 for storage on the device 102 during manufacture of the device 102. The hardware stored secret 112 of the device 102 may also be stored within a manifest or database associated with manufactured devices. The service 104 may have registered the device 102 with the service 104, which may involve provisioning the service 104 with a copy of the hardware stored secret 126 of the device 102 from the manifest or database. For example, the hardware stored secret 112 may be derived from a master key known to the service 104, using, by way of example only but is not limited to, the device's identity (e.g. serial number) and/or any other method for securely ensuring the service 104 has access to and/or is capable of deriving the hardware stored secret 112. In any event, the service 104 is assumed to have a trusted copy of hardware stored secret 126, which is the same as the hardware stored secret 112 that is stored on the device 102, and a trusted copy of the expected digest in relation to the second execution stage and/or any other subsequent execution stage(s) of the device 102.

[00145] Given the service 104 knows the hardware stored secret 112, it can then calculate a second tag (or attestation code) 128 associated with the second execution stage 106b by inputting data representative of: a trusted copy of the expected digest associated with the second execution stage 106b, the received device counter (or a service counter/trusted counter used to track the expected behaviour of the device counter 114), and the copy of the hardware stored secret 126 into a MAC function 130, which is the same as the MAC function 116 of device 102. The received tag 122a associated with the second execution stage 106b is compared with the second tag 128 calculated by the service 104. If both the tags 122a and 128 match, then the service 104 may trust the device 102 is what the device 102 says it is and/or trust that the second execution stage 106b of the device 102 is what the device 102 says it is executing or will be executing. Thus, the service 104 may be able to trust the application firmware 110 of the device 102 if the second tag 128 matches the received tag 122a. If the second tag 128 does not match the received tag 122a, then the service 104 is configured not to trust the device 102 and/or at least the second execution stage 106b of the device 102.

[00146] Furthermore, the service 104 may also perform trust management of the device 102 by monitoring the behaviour of the received device counter 122c based on the knowledge that the device counter 114 may be set to be monotonically increasing and/or monotonically decreasing. The service 104 hosted by one or more servers (or trusted device(s)) may have a trusted copy of the device counter 114, which may be based on a service counter 124 (or trusted counter) that is adjusted to track the expected behaviour of the device counter 114 and/or is adjusted on what it expects the device counter 114 to be. This may be used for generating a tag or attestation code 128 in place of the device count 122c sent in the attestation data 122a-122c. The service counter 124 may also be used to perform further trust management of the device 102 based on the expected behaviour of the device counter 114. As mentioned previously, the device counter 114 may be used to track the number of reboots of the device 102 and may be adjusted each time the device 102 is rebooted. If the device counter 114 is monotonically increasing, then it will be adjusted by incrementing the device counter 114 in relation to each reboot of the device 102. If the device counter 114 is monotonically decreasing, then it will be adjusted by decrementing the device counter 114 in relation to each reboot of the device 102. Thus, even if an attacker were to perform a replay attack by storing a copy of the attestation data such as, by way of example only but not limited to, the tag 122a, digest 122b and device counter 122c, the service 104 may then have a reasonable chance of detecting the replay attack by monitoring or tracking the expected adjustments that the device 102 may make to the device counter 114 using a service counter 124 (or trusted copy of the device counter 114). For example, given that the device counter 114 is used with the hardware stored secret 112 and digest to generate the tag 122a, then the attacker would have to maintain the received device counter 122c at its current value without being detected. Otherwise, if the attacker attempted to increment/decrement the device counter 122c of the attestation data, then the service 104 would detect a mismatch between the second tag or attestation code 128 and the received tag or attestation code 122a as the attacker would not be able to generate a new tag to replace or update the received tag 122a since it does not know the hardware stored secret 112. Furthermore, the server of the service 104 or the service 104 may be configured to have a corresponding service counter 124 that may be used to track the device counter 114 to monitor its expected behaviour. For example, the service 104 may request a reboot of the device 102 and so expect the device counter 114 to be adjusted in an expected manner (e.g. incremented/decremented etc.) according to a set of rules or policies that the device 102 is meant to operate with in relation to adjusting the device counter 114 etc. This may be used to determine whether the device counter 114 is behaving as expected and so will provide an additional layer of confidence to the attestation of device 102. In such cases, the trust management of the service 104 may include rules and/or thresholds (e.g. in relation to the device counter 114) that when not met indicate the device 102 may not be trusted and consider it may have been tampered with. This may be used to prompt or indicate to users of the device 102 and/or service personnel that the device 102 may need to be reset to factory settings, or the device 102 is to be replaced, and/or any other action or indication as the application demands.

[00147] Moreover, the rules and/or policies of the trust management of the service 104 may also be used to monitor the behaviour of the device counter 114, which may be via the service counter 124 that corresponds to the device counter. Thus, when the attacker does not change the attestation data 122a-122c, then the service 104 may be able to detect that the device counter 114 is not being adjusted in the expected manner (e.g. monotonically increasing at the expected rate that it should increase at or monotonically decreasing at the expected rate that it should decrease at, etc.). The service counter 124 may be adjusted in the expected manner as the device counter 114 is adjusted in. For example, the trust management of the service 104 may have rules and/or policies that expect that the device 102 to have scheduled reboots (e.g. daily, weekly, monthly etc.), and so expect the device counter 114 to be adjusted according to an expected adjustment pattern/schedule or manner.

The device counter 114 may be adjusted, by way of example only but not limited to, by either monotonically increasing the device counter 114 or monotonically decreasing the device counter 114, and/or any other adjustment pattern/schedule (e.g. an increasing and/or decreasing pattern/schedule and the like). Thus, if the device counter 114 were to be maintained at its state or value for longer than expected by the service 104, the trust management of the service 104 may then be configured to determine whether to trust the device 102 or not or the second execution stage of the device 102 based on the expected behaviour of the device counter 114. The service 104 may be configured to request the device 102 reset itself and/or reboot itself and update the device counter 114 by adjusting (e.g. incrementing/decrementing) the device counter 114 in the expected manner according to the rules/policies for when the device counter 114 is to be adjusted. The service counter 124 may be adjusted in a similar fashion in order to track the adjustments to the device counter 114. In which case, the service 104 would then expect a new (e.g. incremented/decremented) device counter value 122c corresponding to the updated device counter 114 in the next set of attestation data compared with the previous value of the device counter 114 the previous set of attestation data. Thus, the service 104 may be able to reasonably detect a replay attack of an attacker by monitoring the device counter 114 in relation to the service counter 124 and/or simply monitoring the received device counter 122c values follow the expected adjustment behaviour of the device counter 114.

[00148] Although the cryptographic operation of attestation is described herein, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the attestation and/or iterative key generation system(s) may be modified and/or applied for use with any other type of cryptographic operation, activity and/or protocol such as, by way of example only but not limited to, other attestation protocols, encryption/decryption (e.g. symmetric and/or public/private key), authentication, Transport Layer Security protocol(s) (TLS), TLS-pre-shared key ciphersuites/protocols (TLS-PSK) and the like and/or any other cryptographic operation, activity or protocol as the application demands. At each execution stage, the execution stage key for said each execution stage may be used for generating further stage key(s) and/or used for attestation operations, encryption/decryption operations and/or authentication/encryption operations and the like, without limitation, for example the current stage key may be used in applications using, without limitation, for example TLS and/or TLS-PSK, and/or any other cryptographic operation/protocol at the application demands.

[00149] Figure lb is a flow diagram illustrating an example device attestation process 140 for a device 102 of figure la to perform the attestation protocol with service 104. The device 102 includes a first execution stage 106a and at least another execution stage 106b, where each execution stage 106a and 106b is associated with a corresponding set of computer code or instructions stored on the device 102 and that is configured to execute on the device 102 during execution of said execution stage 106a or 106b, where each execution stage sequentially executes on the device 102. The device attestation process 140 includes the following steps of: In step 142, enabling the first execution stage 106a to have access to a hardware stored secret on the device 102. In step 144, generating attestation data, during execution of the first execution stage 106a, including data representative of the hardware stored secret 112, the device counter 114, and a digest associated with the next execution stage 106b. In step 145, disabling access to the hardware stored secret 112 during or after execution of the first execution stage on the device 102, but prior to execution of the next execution stage 106b on the device 102, where the hardware stored secret 112 is inaccessible thereafter to all execution stages. In step 146, storing the attestation data for sending to the service 104 for attesting at least the next execution stage 106b of the device 102. For example, the attestation data in relation to each execution stage may be aggregated when it is computed by each stage of execution (or before/during each stage of execution) and stored in the device memory 108 and after the device 102 has established communication with the server of the service 104 does the device 102 send the aggregated attestation data in relation to each execution stage of the device 102 to the service.

[00150] Additionally or alternatively, step 144 may further include the steps of: generating a digest 122b of data representative of the next execution stage 106b on the device 102; generating an attestation code or tag 122a using a MAC algorithm or function based on the generated digest 122b, the device counter 114, and the hardware stored secret 112 of the device 102; and storing attestation data comprising data representative of the attestation code or tag 122a and the device counter 122c. Alternatively or additionally, the attestation data may include data representative of the attestation code or tag 122a, the generated digest 122b, and the device counter 122c.

[00151] The device attestation process 140 may further include tracking the status of the device 102 in relation to the number of reboots of the device 102 by adjusting (e.g. incrementing and/or decremenfing) the device counter 114 prior to each reboot and/or execution of each execution stage of the device 102. The service 104 may monitor the device counter 114 using a server or service counter and perform trust management in relation to the next execution stage 106b and/or device 102 based on an expected behaviour of the received device counter 114 and/or the data received in the attestation data in relation to one or more execution stages of the device 102 from the device 102.

[00152] Figure lc is a flow diagram illustrating an example service attestation process 150 for a service 104 hosted by a server of figure la to perform the attestation protocol with device 102 in response to the device attestation process 140 of figure 1 b. The service attestation process 150 may be performed by the service 104, which may be hosted by a server or one or more server(s), the service 104 associated with the device 102 and/or other device(s), where the service 104 has access to secure storage including a trusted copy of the hardware stored secret 112 of the device 102 and also a trusted copy of each of the execution stage(s) 106b of the device 102. The service attestation process 150 further including the following steps of: In step 152, receiving attestation data from the device 102, when communications are established, the received attestation data associated with the next execution stage 106b of the device 102 and/or aggregated attestation data associated with multiple execution stage(s) of the device 102 (e.g. the device 102 has more than two execution stages). The attestation data for the next execution stage 106b may include data representative of the attestation code or tag 122a and a device counter 122c. Alternatively or additionally, the attestation data for the next execution stage 106b may further include a digest associated with the next execution stage 106b. Although the digest associated with the next execution stage 106b is not required by the service 104 (e.g. it may have a trusted copy of the digest of each execution stage of the device 102), there may be some scenarios in which transmitting the digest is useful. For example, for use in further determining with confidence whether the device 102 has been tampered with and/or for other procedures/protocols and the like. The attestation data may be aggregated on the device 102 prior to the device 102 establishing communications with the server of the service 104, so the attestation data in relation to each execution stage may be aggregated into an attestation data container and/or packet. Once communications with the sewer of the service 104 have been established, the device 102 may send an aggregated attestation data to the service 104 in relation to each of the subsequent stages of execution (apart from the first stage of execution) to the service 104. In step 154, for each execution stage of the device 102 apart from the first execution stage 106a, attestation code or a tag 128 in relation to said each execution stage is generated by the service 104 based on the copy of the hardware stored secret 126, the received device counter and a trusted copy of the digest in relation to said each execution stage. Thus, a set of attestation code or tags 128 may be generated for each subsequent execution stage of the device 102. In step 156, trust management is performed in relation to each execution stage 106b and/or the device 102 based on the comparing the received attestation code or tag 122a in relation to said each execution stage 106b with the generated attestation code or tag 128 in relation to each execution stage 106b.

[00153] The received attestation data may include data representative of an attestation code or tag 122a in relation to the next execution stage 106b and the device counter 122c. The received attestation data may also or optionally include the generated digest 122b associated with the next execution stage 106b. The received attestation code or tag 122a is generated by the device 102 using a MAC algorithm based on the generated digest 120, the device counter 114, and the hardware stored secret 112 of the device 102. Step 154 includes generating a second attestation code or tag 128 using the same MAC algorithm as the device 102 used to generate the corresponding received attestation code or tag 122a. In step 154, generating the second attestation code or tag 128 uses the MAC algorithm based on a trusted copy of the digest, the received device counter 122c, and a copy of the hardware stored secret 126 accessible to the service 104. Step 156 may further include the steps of: comparing the second attestation code or tag 128 with the received attestation code or tag 122a; and performing trust management in relation to the next execution stage 106b and/or the device 102 based on the comparison of attestation code or tags 122a and 128.

[00154] Additionally or alternatively, step 156 may further include the steps of: monitoring the device counter 114 based on the received device counter 122c and the expected behaviour of the received device counter 122c; and performing trust management in relation to the next execution stage 106b and/or device 102 based on an expected behaviour of the device counter 114 in relation to the received device counter and/or the data received in the attestation data from the device 102.

[00155] Although the example attestation and iterative generation system 100 and device 102 are described in relation to attestation with reference to figures la-lc, this is by way of example only but the invention is not so limited, it is to be appreciated by the skilled person that any other cryptographic operation and/or activity may be modified, combined and/or used in place of or in conjunction with, combined with the attestation protocol as described in figures la-1c. For example, one or some of the stage keys generated by the device 202 may be used, without limitation, for example in TLS-PSK authentication and the like, where data including a count value of the device counter 114 may be sent to and/or used by the service 104 hosted by the server to determine a TLS-PSK key and/or for use in TLS communications between device 102 and service 104 hosted by the one or more server(s) and the like.

[00156] Figure 1d is another schematic diagram illustrating another example attestation system 160 according to the invention based on attestation system 100 of figures la-lc in which device 102 and service 104 hosted by one or more server(s) have been further modified to enhance the attestation protocol. The device 102 of the attestation system 160 is further modified by dividing the device counter 114 into a first device counter 114a (e.g. an epoch counter) and a second device counter 114b (e.g. a cohort counter). The first device counter 114a is configured to count the number of events and/or requests for changes from the service 104 in relation to the device 102. For example, the epoch counter or the first device counter 114a may be adjusted by some event associated with the service 104 such as, by way of example only but not limited to, a request of change by the server of the service 104, a request by the service 104 for rebooting the device 102, a request by the service 104 for refreshing the first stage key of the first execution stage 106a (e.g. Stage 1), and/or any other request by the service 104 that changes the configuration of the device 102 and the like.

The second device counter 114b is configured to count the number of reboots of the device 102. The advantage of having the device counter 114 being split into a first and second device counter 114a and 114b, respectively, (e.g. epoch and cohort counters) is that it partitions adjustments of the device counter 114 in relation to various events requested by the server of the service 104 and internal events of the device 102 and the like. For example, the service 104 can control changes made to the first device counter 114 by, by way of example only but not limited to, requesting when a reboot of the device 102 is made, and/or requesting a key refresh of the device 102. The device 102 internally/automatically changes or adjusts the second device counter 114b in the event of a reboot of the device. That is, the device counter 114 is split into a first device counter 114a that changes slowly or less often as the service 104 may request an event that changes the device 102, which means the device 102 is configured to adjust the first device counter 114a accordingly when it receives such requests from the service 104, whereas the second device counter 114b may change more regularly and is internally driven by events occurring on the device 102 (e.g. user reboots, device turns off/on etc.).

[00157] The device counter 114, which includes the first and second device counters 114a-114b, is used in the same manner as calculated for attestation system 100 when device 102 generates the attestation data in relation to the second stage of execution 106b (e.g. Stage 2). The attestation data in relation to the second stage of execution 106b includes the attestation code or tag 122a and the device counter 114 including the first and second device counters 114a and 114b. Alternatively or additionally, the attestation data in relation to the second stage of execution 106b may include the attestation code or tag 122a, the generated digest of the second execution stage 106b, and the device counter 114 including the first and second device counters 114a and 114b.

[00158] The attestation data 122a-122c in relation to the second stage of execution 106b may be stored in memory 108 for access and sending by the second stage 106b or any subsequent execution stages once the device 102 establishes communications with the server of service 104. For example, an attestation data 122a-122c may be sent via an attestation message 123 to server hosting the service 104. This may be because the initial bootloader of the first execution stage 106a may not have the capability to connect with the service 104 (e.g. a security measure) and send attestation data based on the stored attestation data 122a-122c. In which case, when the initial bootloader of the first execution stage 106a boots the application firmware associated with the second execution stage 106b, the application firmware may, as part of the attestation protocol, be configured to connect with server of service 104 and send the required portions 123 (e.g. as an attestation message) of the attestation data in relation to the second execution stage 106b to the service 104. However, if there are subsequent stages of execution (e.g. stage 3) on device 102 and the second stage of execution 106b is not configured to establish communications with server of service 104, then the attestation data for each stage of execution may be aggregated and the aggregated attestation data sent once a subsequent execution stage (e.g. stage 3) establishes communication with server of service 104.

[00159] The service 104 is configured to receive the attestation data in relation to the second execution stage 106b (or subsequent execution stages) sent from the device 102 to the service 104 for use in attesting the device 102 and/or the second execution stage 106b and/or subsequent execution stages. The service 104, for each execution stage, on receiving the attestation data may use as input to a MAC algorithm 130 a trusted copy of the digest 127 in relation to said each execution stage, the received device counter 122c (or a service counter tracking the device counter) and also a trusted copy of the hardware stored secret 126 for generating a second attestation code or tag 128. Trust management of the service 104 may then determine whether the device 102 and/or the said each execution stage 106b is trusted or not based on a comparison of the second attestation code or tag 128 with the received attestation code or tag 122a in relation to said each execution stage 106b. For example, if there is a mismatch between the second attestation code or tag 128 and the received attestation code or tag 122a, then the device 102 may be considered to be untrusted. When this occurs, the service 104 may terminate the communication connection with the device, i.e. send a connection denied message 162 to the device 102, or request the device 102 be rebooted or reset to factory settings, replaced and the like. If there is a match between the second attestation code and/or tag 128 and the received attestation code or tag 122a, then the device 102 may be considered to be trusted and/or authorised to upload data and the like to the service 104. This process of attestation is performed in a similar fashion for any subsequent execution stage of device 102.

[00160]As described previously, the trust management of service 104 may include one or more additional rules based on expected behaviour of the device counter 114. For example, a rule may be made in which the device counter 114 is not allowed to decrease if it is monotonically increasing or not allowed to increase if it is monotonically decreasing. Thus, the trust management of service 104 may assign a level of trust to the device 102 as it knows the conditions under which the device 102 may reboot or have a change of configuration and the like. The trust management of the service 104 may instruct the device to perform a reboot 164, if the trust management determines, after a reboot of the device, that the received device counter value 122c as received by service 104 is the same as was previously received after the reboot, then it knows something is wrong with the device 102 or with the communications between server and the device 102. The trust management of the service 104 may become suspicious of device 102 and/or decrease the level of trust associated with the device 102. The service 104 may also send an epoch update request 166 to the device 102 for rebooting the device 102 in which the device 102 adjusts (e.g. increments or decrements) the first device counter 114a (e.g. increase/decrease the epoch) in an expected manner in response.

If device 102 fails to adjust (e.g. increase/decrease) the first device counter 114a in the expected manner, then the trust management of the service 104 may consider the device 102 untrustworthy and remove the device 102 from the service 104, e.g. connection denial 162, until the device 102 performs a reboot and behaves in an expected manner.

[00161]Although an attacker may intercept the epoch update request 166 from the service 104 for adjusting (e.g. increasing/decreasing) the first device counter 114a (e.g. increasing/decreasing the epoch), then this would prevent the adjusting the first device counter 114a by device 102 in a manner expected by the server of service 104, and when the device 102 re-sends the attestation data in relation to the second stage of execution 106b after the reboot and the like, then the trust management of the service 104 can determine that there is a problem with the device 102 and that communications with the device 102 and/or the device 102 may be being tampered with. As a result the trustworthiness and/or level of trust associated with the device 102 may be decreased, e.g. decreased to untrusted and send a denial 162 of communication connection with device 102. The trust management of service 104 may also perform thresholding, threshold games and/or rules or policies for determining the level of trust that may be assigned to the device 102 and/or to each execution stage of the device 102. For example, counter deviation thresholds/thresholding games/rules may be defined, without limitation, for example for the behaviour of the first counter 114a and the second counter 114b in which the first counter 114a is not allowed to deviate from an expected value whereas the second counter 114b is allowed to deviate from the expected value by up to X count values, where X>=1 (e.g. X=3) provided that the X count values are always "in the future" of the last received second device count value. For example, if it determines an epoch update request (or reboot request) from the service 104 was lost, then it may send this message a predetermined number of times to determine the behaviour of the first device counter 114a and assist in making risk management decisions in relation to the first device counter 114a being adjusted (e.g. increasing/decreasing) as expected or not. If the adjustment has not happened or does not happen for a predetermined number of times, then the device 102 trust ranking may be lowered accordingly. Although several thresholds, thresholding games and/or rules/policies have been described for performing trust management, this is by way of example only and the invention is not so limited, the skilled person would appreciate that any suitable method, mechanism or process for performing trust management based the data received from a device may be used and/or applied as the application demands.

[00162] The device 102 and service 104 may be configured to perform cryptographic operations and/or activities during execution of the second execution stage 106b and/or subsequent execution stages of the device 102 using a second stage key 174 that may be configured for use, by way of example only but not limited to, in generation of one or more further stage keys, signature/verification, authentication, and/or encryption / decryption operations in a communication connection between device 102 and the service 104, and/or for use by the second execution stage in generating attestation data in relation to a next or third execution stage, if any. For example, a device 102 may need several secret keys in the same execution stage for, by way of example only but not limited to, encrypting or decrypting data; establishing a TLS session; generating attestation code or tags, generating next-stage attestation data or attestation data in relation to a next stage of execution; pass a secret key onto another execution stage, etc., prevent key-re-use, and/or as the application demands.

For example, for the second execution stage 106b, the second stage key 174 may be used to generate a set of secret keys or set of second stage keys that may be derived using a KDF on the second stage key 174 and further input data such as, without limitation, for example key usage parameters or a set of key usage parameters and the like, and/or device counters and the like [00163] One or more secret keys (or one or more execution stage keys) for an execution stage may be iteratively derived based on a previous execution stage key of the immediately preceding execution stage in order to provide a unique secret key for each key use. The immediately preceding execution stage is configured, during execution, to derive the one or more execution stage keys for the next execution stage based on the execution stage key(s) (e.g. previous execution stage key(s)) of said immediately preceding execution stage. The immediately preceding execution stage is configured to make the execution stage key(s) of the immediately preceding execution stage inaccessible to subsequent execution stages. This assumes that the other party, e.g. the server of the service 104 and/or other devices, know how each secret key is derived so they may play a part in the cryptographic scheme and/or attestation protocol and the like. For example, a remote TLS server requires access to the TLS key, a remote attestation server or sewer hosting service 104 would require access to the secret key used to generate the attestation code or tag 122a and/or subsequent attestation codes or tags in relation to subsequent execution stages, a remote authentication server would require access to the authentication key, any system interfacing with the next execution stage would require access to the next-stage key. This may be implemented by a common system that is configured and/or understands the key derivation scheme for generating the secret keys for an execution stage and has access to the hardware shared-secret of the device 102 and/or is able to track and/or control the device counter of the device 102 using a service counter and the like. This common system could then distribute derived keys for each execution stage to the systems and/or devices that require them when communicating with device 102. Since the hardware stored secret 112 of the device is meant to be kept secret and inaccessible to the second and/or subsequent execution stage(s) 106b, the device 102 and the service 104 require a method for generating and/or exchanging suitable second stage keys and/or subsequent stage keys. The second stage or subsequent stage keys that are generated may be symmetric keys in which both the service 104 and the device 102 are capable of generating and so may use the same key.

[00164] As described, the data and/or code representative of the second execution stage 106b and/or subsequent execution stages may require, when executing, some form of credential(s) and/or secret key(s) for, by way of example only but not limited to, connecting and/or communicating with service 104 and/or for generating tags/attestation codes in relation to subsequent execution stages and storing as attestation data for sending to service 104.

The generation of a credential and/or a secret key for the second execution stage, a so-called second stage key 174, is performed during execution of the immediately preceding execution stage using a previous execution stage key. In this case, the first execution stage 106a is the immediately preceding execution stage of the second execution stage 106b, and so the first stage execution key 172 is used to generate the second stage key 174. The first stage execution key 172 may be based on, by way of example only but not limited to, the hardware stored secret 112. The first stage execution key 172 is used for generating the second stage key 174 using a Key Derivation Function (KDF) 170a. Thus, the first stage key 172, which is based on the hardware stored secret 112, and the device counter 114 may be input to the KDF 170a along with a key usage parameter 173a to generate the second stage key 174.

Different key usage parameters 173a may be used to generate different second stage keys.

Alternatively or additionally, a single second stage key 174 may be generated and the second execution stage 106b may be configured to use a KDF to generate further second stage keys based on the single second stage key 174 and a set of key usage parameters and the like.

[00165] The key usage parameter 173a is from a set of pre-defined values (e.g. values defining key usage such as, by way of example only but not limited to, data representative of "attestation", "authentication", "encryption", and any other usage) known to the device 102 and/or the service 104 hosted by the one or more server(s). As the service 104 has a trusted copy of the hardware stored secret 112 and also has access to the device counter 114 via attestation data or the service counter 124, which tracks the device counter 114, the service 104 can derive the first stage key 172 and so may also derive the second stage key 174, once it receives the attestation data in relation to the second execution stage 106b. The key usage parameter 173a is used to generate different keys for, by way of example only but not limited to, encryption, decryption, authentication, and any other use that requires different sets of secret keys for different operations. The key usage parameter 173a is an identifier for the type of secret key that is to be generated.

[00166] Generally, KDF 170a is configured to derive one or more secret keys from a secret value such as a master key, a password, or a passphrase and any other agreed information between the device 102 and service 104 (e.g. salt such as device counter 114 and key information such as key usage parameters 173a and the like). Any suitable KDF may be used such as, by way of example only but not limited to, an HMAC KDF or HKDF, Advanced Encryption Standard (AES)-KDF, Argon2 and/or Argon2 variants and the like, and/or any other suitable KDF and the like for generating one or more secret keys and the like and/or as the application demands. In this case, the master key is the first stage key 172, which is based on the hardware stored secret 112 and the agreed information may be the device counter 114 and key usage parameter 173a. The KDF 170a generates a second stage key 174 from the first stage key 172, device counter 114 and key usage parameter 173a, which is stored as the second stage key 174 in memory 108. For example, without limitation, using the HKDF function, which may be defined as output key = HKDF(input key, salt, key information) in which salt and key information are agreed upon values such as, by way of example only but not limited to, device counter 114 and key usage parameter, respectively.

The KDF 170a may generate a second stage key based on second stage key = HKDF(first stage key 172, device counter 114, key usage parameter 173a).

[00167] The KDF 170a is configured to ensure that the second stage key 174 cannot be used to derive the first stage key 172 or the hardware stored secret 112. One or more different second stage key(s) to the second stage key 174 may be generated based on different key usage parameters from the set of predefined values and stored in memory 108. The one or more different second stage key(s) are used by the second execution stage 106b and/or when required. Although the KDF 170a may be based, by way of example only but is not limited to, the HMAC KDF or HKDF and its derivatives etc., it is to be appreciated by the skilled person that any suitable KDF may be used by KDF 170a for generating and/or deriving one or more second and subsequent execution stage keys based on the first stage key and the like and/or as the application demands.

[00168] Once the first execution stage 106a has generated the second stage key(s) 174 and the first execution stage 106a has finished using the first stage key 172, the first stage key 172 and the hardware stored secret 112 are made inaccessible to the second execution stage 106b and any subsequent execution stage(s) prior to execution of the second execution stage 106b. This prevents the first stage key 172 and the hardware stored secret 112 from being exposed to the second execution stage 106b and/or subsequent execution stages. Making the first stage key 172 and/or hardware stored secret 112 inaccessible may include removing any data representative of the first stage key 172 and hardware stored secret 112 from the memory 108 of the device 102, and securing the hardware/memory/registers associated with the first stage key 172 and/or hardware stored secret 112 to be inaccessible. Although the first stage key 172 and hardware stored secret 112 are shown to be stored in separate locations, it is to be appreciated by the skilled person that the first stage key 172 may be the hardware stored secret 112, and thus, is stored securely in one location on the device 102.

The memory 108 is used as an application memory for storing the application firmware of the second execution stage 106b, and can also be used to store the generated one or more second stage key(s) 174 (e.g. different stage keys may be generated using different key usage parameters for each corresponding application of said second stage key(s)) and/or subsequent stage keys for encryption, authentication and any other operation that requires a symmetric key. The second stage key(s) 174 are stored in memory 108, which the first execution stage 106a makes available.

[00169] In addition to the first execution stage 106a of the device 102 generating one or more second stage key(s) 174 for use by the second execution stage 106b during execution of the second execution stage 106b, the service 104 may be modified and configured to implement a similar type of KDF calculation to generate the same corresponding set of second stage key(s) 176. This can be used for symmetric encryption during a communication session between device 102 and service 104. In this regard, the service 104 also has a KDF 170b, which is the same as the KDF 170a of device 102, for generating the corresponding second stage key(s) 176 using the same input key and key information. This is possible because the service 104 has access to the copy of the hardware stored secret 126, from which the first stage key 172 may be derived, and the device counter 122c, and it is configured to know the key usage parameters that the device 102 uses to generate the one or more second stage keys 174. Thus, the service 104 generates a set of second stage keys 176 that correspond to the one or more second stage keys 174 stored in memory 108 of device 102.

[00170] Once the second stage key generation is completed by the first execution stage 106a, the first stage key 172 and hardware stored secret 112 are made inaccessible. During execution of the second execution stage 106b, there may be an application or code that is configured to perform encrypted communications between device 102 and service 104. Thus, an application executing from the second execution stage 106b has access to memory 108 and may retrieve the required second stage key(s) 174 (e.g. application keys for use with the application) and use a second stage key 174 as an encryption key for encrypting a message for sending to service 104. The service 104 may receive the encrypted message and retrieve the corresponding second stage key 176 for decrypting the received encrypted message and produce back the plaintext message.

[00171] For example, when the bootloader of the first execution stage 106a completes, the bootloader then boots 178 the application firmware of the second execution stage 106b. Prior to this point or at this point, the bootloader of the first execution stage 106a completes its execution, and prior to the execution of the application firmware of the second execution stage 106b the first execution stage 106a and the hardware stored secret 112/first stage key 172 are made inaccessible and turned off. Access is denied to the second execution stage and/or subsequent execution stages in relation to the hardware stored secret 112/first stage key 172. The device counter 114 is still accessible by the second execution stages and subsequent execution stages, which may be configured to adjust (e.g. increase or decrease) the device counter as each execution stage is loaded for execution, and/or when the device 102 reboots. Alternatively or additionally, the device counter 114 is incremented by logic/hardware and/or software (e.g. attestation components) that performs the attestation protocol between device 102 and service 104.

[00172] Once booted, the application firmware of the second execution stage 106b takes the attestation data 122a-122c stored by the first execution stage 106a and sends an attestation dataset or container 123 in relation to second execution stage 106b including data representative of at least the attestation data corresponding to the authentication data or tag 122a and device counter 122c to the service 104 once the application firmware connects with the service 104. Alternatively or additionally, the attestation dataset or container 123 in relation to the second execution stage 106b may include, if required, attestation code or tag 122a, the digest 122b of the second execution stage 106b, and device counter 122c. The service 104 may use the received attestation dataset or container 123 to generate the required second stage keys 176 for use in a secure communication session with device 102, and/or for performing the attestation protocol in relation to device 102. For example, the second stage key 174 generated by the device 102 and the corresponding second stage key 176 generated at the service 104 may be used to form, by way of example only but is not limited to, a transport layer security (TLS) session between device 102 and service 104. The second execution stage 106b may also generate a next or third stage key (e.g. Third Stage Key) for the next or third execution stage (e.g. Third Stage) (not shown) based on using a KDF with the second stage key 174. Alternatively or additionally, the third stage key may be generated using a KDF and the second stage key 174 and the device counter 114. Alternatively or additionally, the third stage key may be generated using a KDF and the second stage key 174 and a key usage parameter and the like.

[00173] The server hosting the service 104 may store the previous device counter 114 that it has received as a last device counter 168. This allows the service 104 to perform a comparison 169 between the last device counter 168 and the current received device counter 122c of a currently received attestation dataset or container 124. If the device counter 114 is adjusted as expected (e.g. is a monotonically increasing counter or a monotonically decreasing counter), then if the last device counter 168 when compared to the current received device counter 122c is not behaving as expected, then the service 104 may determine a replay attack may be being performed and the device 102 is to be untrusted.

[00174] The trust management of the service 104 may form multiple rules for determining the behaviour of the device counter 114 and for detecting whether the device 102 and/or communications between service 104 and device 102 are being tampered with by an attacker. For example, the trust management of service 104 may form a rule that after X (e.g. X=10) connection attempts, the service 104 should instruct the device 102 to perform a reboot 164 and/or send an update epoch request 166 to increase the first device counter 114a (e.g. increase epoch) in order to get a new count. Furthermore, the service 104 or the server hosting the service 104 may have a service or server count 124 that may be used to track the device count 114 and/or use to track at least the first device counter 114a. The first device counter 114a is used to track the number of changes requested by the service 104, so the service 104 may adjust its service counter 124 each time it requests a change on the device 102 (e.g. a reboot, epoch update, or secret key refresh etc.), which the device 102 is meant to record by adjusting the first device counter 114a. One or more rules and/or policies may use the service counter 124 and the received device counter 122c to determine whether the device counter 114 is behaving in an expected manner. For example, the service counter 124 may be compared with the corresponding portion of the received device counter 122c (e.g. the first device counter 114a) to determine whether the device counter 114 has been adjusted as requested by the service 104. The trust management may be configured to use the device counter 122c, last count 168 and/or service counter 124 to check whether the device 102 is operating as expected. In essence, the logic and/or software of the trust management may be as simple or as complex as the application demands because the service 104 is operating in a cloud platform 103 and/or is hosted by one or more servers.

[00175] Figure le is another schematic diagram illustrating another example attestation system 180 according to the invention based on attestation systems 100 and 160 of figures la-id in which device 102 and server(s) hosting service 104 have been further modified to enable a secret key refresh or a update of the first stage key 172 whilst enabling the first stage key 172 to be inaccessible prior to execution of the second execution stage 106b. This further enhances the attestation protocol. Figure le will be used, for simplicity and by way of example only, to describe a shared key mode of operation for the secret key refresh and a public key mode of operation for updating the first stage key 172 of the device 102. The shared key mode of operation describes a scenario in which the hardware stored secret 112 is known by both the device 102 and the service 104 hosted by one or more server(s). The public key mode of operation describes a scenario in which the hardware stored secret 112 is not known by the service 104 hosted by the one or more server(s).

[00176] In the example shared key mode of operation of attestation system 180, the hardware stored secret 112 is assumed to have been securely shared with the service 104 associated with the device 102. For example, the hardware stored secret 112 of the device 102, which is stored on non-volatile memory of the device 102, may be securely shared via a manifest provided by the manufacturer of device 102 with the service 104. In another example, the operators or providers of the service 104 may arrange for the hardware stored secret 112 to be set on the device 102 by, for example but not limited to, pre-installing the hardware stored secret 112 in secure non-volatile memory on device 102 before deployment of the device 102.

In a further example, the hardware stored secret 112 of the device 102 may be securely shared with the service 104 via a key exchange mechanism/protocol between device 102 and/or service 104. Although several methods of securely sharing the hardware stored secret 112 have been described, these are by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that any other suitable method of securely sharing the hardware stored secret 112 may be used and/or as the application demands.

[00177] In any event, in the shared key mode of operation, the hardware stored secret 112 of the device 102 has been securely shared with the service 104 hosted by one or more server(s). The device 102 of the attestation system 180 is further configured by having the hardware stored secret 112 act as a key for decrypting the first stage key 172 during execution of the first stage of execution 106a. The first stage key 172 may be stored in encrypted form in non-volatile memory 108, which may be unsecured memory. The first stage key 172 may also be a symmetric key. The first stage key 172 may be decrypted prior to or during execution of the first stage of execution 106a using the hardware stored secret 112. The hardware stored secret 112 may be made accessible only to the first stage of execution 106a as described herein. The decrypted first stage key 172 may be used by the first execution stage 106a in the attestation protocol as described with reference to figures la to 1d and/or as described herein. The first stage key 172 is then made inaccessible when the first execution stage 106a hands over execution to the second execution stage 106b, and is inaccessible thereafter to all other stages of execution.

[00178] Making the first stage key 172 inaccessible may include, by way of example only but is not limited to, removing or deleting data representative of the plaintext first stage key 172 or the decrypted first stage key 172 from memory 108 prior to execution of any of the other stages of execution 106b and the like whilst leaving the first stage key 172 encrypted by the hardware stored secret 112 in memory 108. The hardware stored secret 112 is stored on the device 102 and the corresponding hardware stored secret 126 (e.g. the copy of the hardware stored secret 112) is securely stored by the service 104 and is accessible to the service 104.

The hardware stored secret 112 is configured to be inaccessible to all subsequent execution stages 106b apart from the first execution stage 106a. Additionally or alternatively, the hardware stored secret 112 may be configured to be inaccessible to all execution stages 106a and 106b, but is used for initially decrypting the first stage key 172, which is encrypted with the hardware stored secret 112 prior to or during the execution of the first execution stage 106a. The first stage key 172 is configured to be inaccessible to the second execution stage 106b and any other execution stages when executed on the device 102.

[00179] In the shared mode of operation, the corresponding hardware stored secret 126 stored by the service 104 can be used by the service 104 to deliver at least a new first stage secret key to the device 102. As previously described with reference to figure ld, the first stage secret key 172 may be used to derive one or more second stage keys on the device 102, which are then used to, if required, derive/generate one or more next stage keys on the device 102 and so forth. Alternatively or additionally, this iterative generation process may also be bypassed as the attestation system 180 may be configured such that the service 104 may generate the first stage key and also any further second stage and/or subsequent stage keys and refresh these keys on the device 102 based on the shared mode of operation. Thus, the service 104 or servers hosting the service 104 may iteratively generate the second stage key based on the first stage key and a device counter (nonce or changing value), and iteratively generate subsequent stage keys based on the immediately preceding stage key based on the iterative generation mechanism as described with reference to figures la-1d and/or as described herein. Such methods may be used for extremely constrained devices that may not have the capability to perform key generation.

[00180] Nevertheless, assuming the constrained device 102 is configured to iteratively generate keys as described with reference to figures la-3d and/or as described herein, then the server hosting the service 104 may be configured to refresh the first stage key 172. For a first stage key 172 refresh using the shared mode of operation, the service 104 may determine that a secret key refresh is required of at least the first stage key 172 and so may initiate the secret key refresh by sending the device 102 a secret key refresh request 181 (e.g. shared key mode refresh). For the secret key refresh request 181, the service 104 generates one or more new first stage keys and encrypts, which may be without limitation for example authenticated encryption, these new secret keys using the hardware-stored-secret 126 to generate a secret key refresh ciphertext. These generated one or more new first stage keys may also be stored by the service as data representative of a copy of the first stage key 127. The secret key refresh request includes data representative of the secret key refresh ciphertext and also an indication of an epoch counter adjustment (e.g. increment/decrement) 166 (e.g. adjustment of the first device counter 114a), which is used by the device 102 to initiate a reboot and decrypt the secret key refresh ciphertext after the reboot. The service 104 may adjust a service counter 124 to track the changes requested by the service 104 of the device 102, which includes the secret key refresh request and/or the epoch counter update. The secret key refresh is sent to the device 102, where the device 102 is configured to store the new secret key refresh ciphertext internally in memory 108. This may be in a particular memory location of memory 108, which the device 102 or first execution stage 106a is configured to check and interpret on rebooting as a requirement to perform a secret key refresh. Additionally or alternatively, the new secret key refresh ciphertext may be stored anywhere in memory 108, in which the device 102 or the first execution stage 106a is configured, on rebooting, to validate and identify the most up to date ciphertext for refreshing the secret keys.

[00181] Once the new secret key refresh ciphertext is stored, the device 102 then reboots, where the first execution stage 106a is configured to adjust (e.g. increments/decrements or replaces with the epoch counter value) the first device counter 114a (e.g. ordered by the epoch counter indication). The device 102 is then configured to validate the stored new secret key refresh ciphertext or may be configured validate each of the stored secret key refresh ciphertexts and the new secret key refresh ciphertext and choosing the latest valid secret key refresh ciphertext, which would be the new secret key refresh ciphertext that was recently sent from the service 104. If the new secret key refresh ciphertext only includes data representative of a new first stage key, then the first execution stage 106a may simply overwrite the current encrypted first stage key 172 stored in memory 108, which may be decrypted using the hardware stored secret 112 during execution of the first execution stage 106a.

[00182] Alternatively or additionally, the validated new secret key refresh ciphertext may include both a new first stage key and additional data representative of, by way of example only but not limited to, additional first stage keys and/or one or more further stage keys for use by one or more further execution stages of the device 102. The device 102 is configured to use the hardware stored secret 112 to decrypt the validated new secret key refresh ciphertext and extract the new first stage key and/or additional data, then encrypt the new first stage key with the hardware stored secret 112 and replace the current encrypted first stage key 172 with the encrypted new first stage key. The device 102 may be configured to also place the decrypted additional data into the appropriate memory locations of memory 108 for use by the first stage of execution and/or one or more further stages of execution and the like.

Thus, the encrypted first stage key may be decrypted using the hardware stored secret for use by the first stage of execution in generating attestation data for the second stage of execution 106b, and next stage keys 174 for the second stage of execution 106b and the like. Once the first stage of execution 106a has completed, access to the first stage key is disabled by removing any plaintext data associated with the hardware stored secret and/or first stage key prior to execution of any of the other execution stages 106b and the like on the device 102.

[00183] As a more detailed example, in the shared mode of operation, the service 104 may determine that a secret key refresh is required of at least the first stage key 172 and so may initiate the secret key refresh by sending the device 102 a secret key refresh request 181 (e.g. shared key mode refresh). For the secret key refresh request 181, the service 104 encrypts a new secret key, using authenticated encryption with associated data (AEAD) with the first device counter 114a (e.g. the epoch counter/service counter 124) as the associated data and encrypted using the hardware-stored-secret 126, which is the same as the hardware stored secret 112 of the device 102. The secret key refresh request and associated ciphertext is sent to the device 102, where the device 102 stores the new ciphertext internally in memory 108. The device 102 then reboots, in which the first execution stage 106a is configured to adjust (e.g. increments/decrements) the first device counter 114a accordingly (e.g. as described with reference to figures la-1d and/or as herein described), due to the adjustment of the first device counter 114a (e.g. ordered by the epoch counter) the device 102 is configured to, for example the first stage of execution 106a may be configured to, validate each stored ciphertext, and then chooses the latest valid ciphertext. It also reports to the first stage of execution 106a and/or other stages of execution (e.g. applications) the location in which it may install each new ciphertext (an invalid slot or the oldest valid slot). For refreshing the first stage key, the new ciphertext in relation to the first stage key may be stored in the location of the current encrypted first stage key, where the new ciphertext is simply the first stage key encrypted by the hardware stored secret 126, which is the same as hardware stored secret 112.

[00184] The following describes the public key mode of operation for performing a secret key refresh or updating of the first stage key 172. In the example public key mode of operation for updating the first stage key 172, the hardware stored secret 112 of device 102 is assumed not known by the service 104 hosted by one or more server(s). In this case, the service 104 and device 102 are further modified to perform a partial key exchange by each securely sharing key exchange value data which are combined with corresponding private secrets at each side which is used to generate the same first stage key 172 on the device 102 and the service 104 hosted by one or more server(s). That is, the first stage key 172 on the device 102 and the first stage key 127 of the service 104 hosted by one or more servers are the same. In order to perform this, the device 102 is modified and configured with the following items: a) a Service Public Key 182a associated with the service 104; and b) a Service Public Key integrity protection mechanism 183, which is used to validate the signed "first stage key update package". The Service Public Key 182a and the Service Public Key integrity protection mechanism 183 may be installed on the device 102 at, by way of example only but not limited to, device production, set-up and/or manufacture, or any other installation procedure/firmware update and/or as the application demands.

[00185] The Service Public Key integrity protection mechanism 183 may be, by way of example only but is not limited to, any one or more from the group of, or combinations and/or modifications thereof, the following mechanisms: 1) a trusted location (e.g. ROM or secure non-volatile memory) configured to store the Service Public Key 182a; 2) a trusted location (e.g. ROM or secure non-volatile memory) configured to store a hash of the Service Public Key 182a; an HMAC of the Service Public Key computed using hardware stored secret 112 and stored next to the Service Public Key 182a. The device 102 is also configured to include a first stage key generation/update counter 184a, which may hold a current value set by the service 104 from a previous refresh of the first stage key 172. The current value of "first stage key generation/update counter may be secured with an HMAC computed using hardware stored secret 112. The device 102 also includes a device private key 185b stored in secure non-volatile memory. The Device Private Key 185b may be encrypted or secured based on the hardware stored secret 112 of the device 102.

[00186] Although a first stage key generation/update counter 184a may be a separate counter to the device counter 114, this is for simplicity and by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the first stage key generation/update counter may be implemented in any suitable manner such as, by way of example only but is not limited to, the device counter 114 including one or more additional counters that implement the first stage key generation/update counter 184a, or using the first device counter 114a as the first stage key generation/update counter 184a, or using the second device counter 114b as the first stage key generation/update counter 184a, or any other mechanism or process for implementing the functionality of the first stage key generation/update counter 184a described herein.

[00187] The service 104 hosted by the one or more server(s) is modified and configured with the following items: a) a Service Private Key 184b that corresponds with the Service Public Key 184a, which form a key pair; b) a first stage key generation/update counter 184b corresponding to the first stage key generation/update counter 184a of the device 102, where the first stage key generation/update counter 184b holds a current value set by the service 104 from a previous refresh of the first stage key 172; and c) a Device Public Key 185a of the client device 102, which forms a key pair with the Device Private Key 185b.

[00188] The device 102 of the attestation system 180 is further modified by having the hardware stored secret 112 act as a key for encrypting/decrypting the first stage key 172, the Device Private Key 185b and/or the Service Public Key 182a. The Device Private Key 185b, the Service Public Key 182a and first stage key 172 may be stored in a secure or encrypted form in non-volatile memory. For example, the Service Public Key 182a of the service 104 may be protected/encrypted on the device 102 with the hardware stored secret 112 using, by way of example only but it is not limited to, HMAC or AES-CMAC, or AEAD. The first stage key 172 may be, without limitation, for example a symmetric key.

[00189] In the public key mode, the hardware stored secret 112 is not known by the remote service 104 hosted by one or more server(s). In this case, the remote service 104 and the device 102 exchange public key exchange data that may be derived from corresponding private key exchange data. For example, the service 104 and/or server hosting the service 104 may be configured to generate a service/server private key exchange data (SPrKX data) 187a, which is used for generating a service/server public key exchange data (SPbKX data) 187c. The device 102 may be configured to generate a device private key exchange data (DPrKX data) 187b, which is used to generate a device public key exchange data (DPbKX data) 187d. The SPrKX, SPbKX, DPrKX, and DPbKX data may be key exchange data representative, generated or derived, without limitation, for example using one or more key exchange mechanisms and/or based on, without limitation, for example, data representative of key exchange values, private/public key exchange values generated from/required by a suitable cryptographic protocol/algorithm, and/or key exchange protocols/algorithms enabling the secret key refresh. For example, suitable cryptographic protocol/algorithm, and/or key exchange protocols/algorithms may include, without limitation, for example Diffie-Hellman key exchange (DHKX), Elliptic Curve (EC) cryptography ECDH key exchange algorithms, and/or any other suitable cryptographic protocol and/or key exchange protocol and the like and/or as the application demands.

[00190] In step 4, the service 104 generates a first stage key update request 188a (e.g. First Stage key update with SPbKX data and FKGC) that includes the public key exchange data derived from the SPrKX data 187a and the first key generation counter 184b. The service 104 signs and/or encrypts the first stage key update request 188a with a Service Private Key 182b. For example, the signing/encrypting of the first stage key update request 188a with Service Private Key 182b may be based on, by way of example only but not limited to, Elliptic Curve Digital Signature Algorithm (ECDSA) and/or any other suitable signature/cryptographic algorithm for signing the first stage key update request 188a. In step 5, the service 104 is configured to send the signed first stage key update request 188b containing the SPbKX data 187c derived from the SPrKX data 187a and the value of the first stage key generation counter 184b to the device 102. The signed first stage key update request 188b may be sent from the service 104 to the device 102 when the device 102 is executing the second execution stage 106b and/or any other subsequent execution stage that has established communication with the server hosting the service 104. In step 6, the application firmware of the second execution stage 106b (or other subsequent execution stage) may be configured to store the received signed first stage key update request 188b in a designated, agreed or common location in the memory 108 of the device 102. In step 7, the application firmware of the second execution stage 106b (or other subsequent execution stage) is configured to, on receipt and storing of the received signed first stage key update request 188b, trigger and/or instruct the device 102 to perform a reboot.

[00191] In step 8, after the device 102 reboots and the first stage of execution 106a (e.g. initial bootloader firmware) starts executing, the first stage of execution 106a is modified and configured to check the designated or agreed location for storing any newly received signed first stage key update request 188b stored in memory 108. For example, when the initial bootloader of the first execution stage 106a executes, the initial bootloader is configured to check the designated/agreed location of the signed first stage key update request 188b in memory 108 to see if there is a newly received signed first stage key update request 188b, which indicates a new shared key refresh has been requested by the service 104. The first stage of execution 106a may also validate the Service Public Key 182a as stored or received. In step 8, if the initial bootloader finds a new signed first stage key update request 188b at the agreed location in memory 108, then the new signed first stage key update request 188b may be authenticated using signature validation 189, where the device 102 may use the Service Public Key 182a for validating the newly received signed first stage key update request 188b.

For example, the signature validation 189 may be based on, by way of example only but not limited to, Elliptic Curve Digital Signature Algorithm (ECDSA) and/or any other suitable signature/cryptographic algorithm for validating a signed first stage key update request 188b. This may signal and/or verify to the initial bootloader of the first stage of execution 106a that the service 104 has requested a new secret key refresh.

[00192] In step 9, the first stage of execution 106a of device 102 may be configured to perform a first stage generation counter check 190a for checking that the received first stage generation counter value 184b is in the future compared to the stored value of the first stage generation counter 184a. For example, if the first stage generation counter 184a is configured to be monotonically increasing (or monotonically decreasing), then the first stage generation counter check 190a determines whether the received first stage generation counter value 184b is greater than the first stage generation counter 184a. In another example, if the first stage generation counter 184a is configured to be monotonically decreasing, then the first stage generation counter check 190a determines whether the received first stage generation counter value 184b is less than the first stage generation counter 184a.

[00193] If the first stage generation counter check 190a confirms the received first stage generation counter value 184b is in the future (e.g. OK), then in step 10, the first stage of execution 106a computes a DPrKX data 187b (e.g. new device secret). For example, the device 102 may compute the DPrKX data 187b, which is used to form the device/client half of the key exchange algorithm with the service 104 to form a so-called SPbKX data 187d (e.g. Client Key eXchange value (CKX)). This key exchange operation may use, by way of example only but is not limited to, a ECDH key exchange algorithm for generating the device/client half of the key exchange algorithm with service 104 from the DPrKX data 187b.

It is to be appreciated that any other key exchange algorithm may be used to derive key exchange values from the device and service secrets as the application demands. In step 10a, the DPrKX data 187b is used to generate the DPbKX data, which is sent to the server hosting the service 104. In step 11, the first stage of execution 106a of the device 102 is configured to use the new DPrKX data (e.g. new device secret) 187b and the newly received SPbKX data (e.g. SKX), which was received in the signed first stage key update request 188b, to compute a new first stage key 191a. For example, the device 102 may use the new DPbKX data 187b and newly received SPbKX data to create a new first stage key 191a according to the key exchange protocol and/or cryptographic protocol that is chosen or used for performing the secret key refresh. In step 12, the first stage of execution 106a of the device 102 is further configured to update the first stage key generation counter 184a by replacing it with the newly received first stage key generation counter value 184b. Note, the value of the first stage key generation counter 184a on the device 102 should now be the same as the value of the first stage key generation counter 184b on the service 104 hosted by one or more server(s).

[00194] In step 13, the first stage of execution 106a generates a signed first stage key update response 192, which includes data derived from the new DPbKX data 187c (e.g. CKX) and the new first stage key generation counter 184a of the device 102. The device 102 signs or encrypts the first stage key update response 192 with the Device Private Key 185b. For example, the signing/encrypting of the first stage key update response 192 with the Device Private Key 185b may be based on, by way of example only but not limited to, Elliptic Curve Digital Signature Algorithm (ECDSA) and/or any other suitable signature/cryptographic algorithm for signing the first stage key update response 192.

[00195] In step 14, the first stage of execution 106a on the device encrypts the new first stage key 191a using the hardware stored secret 112 and then replaces the previous encrypted first stage key 172 with the encrypted new first stage key 191a. Thus, the encrypted first stage key 172 has been updated on the device 102 with the encrypted new first stage key 191a. The first stage of execution 106a may be further configured to clean the agreed, designated and/or common location in memory 108 for storing the newly received first stage update request 188b. Additionally or alternatively, the first stage of execution 106a may be further configured to clean or remove any plaintext data related to the first stage key update request 188b and/or first stage key update response 192 from memory 108. Additionally or alternatively, the first stage of execution 106a may be further configured to remove any other plaintext data from memory 108 that is representative of the generated updated first stage key 191a, newly received SPbKX data, new DPrKX data 187b, new DPbKX data 187d and/or newly received first stage key generation counter value 184b and/or any other sensitive data, values, information or calculations used in the secret key refresh. This is to avoid any subsequent execution stages of the device 102 from being able to duplicate or generate the new updated first stage key 172. The new encrypted first stage key 172 may be made accessible to the initial bootloader of the first execution stage 106a by decrypting it using the hardware stored secret 112 prior to or during execution of the first execution stage 106a.

[00196] In step 15, the first stage of execution 106a places the signed first stage update response 192 in a designated, agreed or common location in memory 108 that may be checked for sending, once communications have been established, the newly signed first stage update response 192 to the one or more server(s) hosting the service 104. Since the first stage of execution 106a typically does not establish communications with the one or more server(s) hosting the service 104, one of the subsequent execution stage(s) 106b is further configured to send any newly signed first stage update response 192 to the server(s) hosting the service 104. In step 16, after placing the newly signed first stage update response 192 in the designated or agreed location in memory 108 in step 15, but prior to booting the second stage of execution 106b, the first stage of execution 106a may optionally be further configured to initiate a reboot of the device 102 in which, after the reboot, the device 102 boots normally and the initial bootloader of the first stage of execution 106a executes and is configured to use the new first stage key 172. This reboot to ensure that the first execution stage 106a is using the updated new first stage key 272 and that the service 104 can update its copy of the first stage key 127 prior to or when receiving attestation data 122a-122c generated using the newly updated first stage key 172 and the like from device 102. Regardless of whether the optional reboot is performed, prior to or during execution of the bootloader of the first stage of execution 106a, the encrypted new first stage key 172 is decrypted using the hardware stored secret 112 for use by the first stage of execution 106a. The new first stage key 172 is used by the initial bootloader of the first stage of execution 106a for generating second stage key(s) 174 and also for generating attestation data 122a- 122c in the usual manner as described with reference to figures la to 2d and/or as described herein. Once the initial bootloader of the first execution stage 106a has completed, the hardware stored secret 112, Service Public Key 182a, Device Private Key 185b and the first stage key 172 are made inaccessible to the second execution stage 106b and any subsequent execution stages. For example, this may be achieved by removing any data representative of the hardware stored secret 112, Device Private key 185b, Service Public Key 182a and first stage key 172 from the memory 108 of the device 102 and securing access to the non-volatile memory that these data items are stored in. The data related to the hardware stored secret 112, Device Private key 185b, Service Public Key 182a and first stage key 172 may include plaintext of the Device Private Key 185b, Service Public Key 182a and/or first stage key 172 and the like.

[00197] In step 17, after the first execution stage 106a boots 178 the second execution stage 106b. In this example, the second execution stage 106b is configured to establish communications with the server hosting the service 104. Given this, the second execution stage 106b is further configured to check the designated or agreed location in memory 108 for storing any new first stage key update response 192. For example, when the application firmware of the second execution stage 106b, the application firmware may be configured to initially check the designated/agreed location in memory 108 storing any new signed first stage key update response 192 to see if there is a new signed first stage key update response 192 that needs to be sent to the server hosting the service 104. This also indicates that a new shared key refresh has been implemented by device 102 and data derived from the device secret 187b within the new signed first stage key update response 192 is required by the service 104 to update its copy of the first stage key 127. If a new first stage key update response 192 is found at the agreed location in memory 108, the second execution stage 106b, after establishing communications with the server hosting the service 104, sends the new first stage key update response 192 to the server hosting the service 104. As an option, once the new first stage key update response 192 has been sent to the server hosting the service 104, the second execution stage 106b may be configured to delete or remove data representative of the new first stage key update response 192 from memory 108.

[00198] It is noted, that if the device 102 has more than two execution stages, i.e. the device 102 has multiple stages of execution or a plurality of stages of execution, and the second execution stage 106b is not configured to establish communications with the server of the service 104, then a subsequent execution stage that is configured to establish communications with server hosting the service 104 may be further configured to perform step 17 for sending the new signed first stage key update response 192 to the server hosting the service 104.

[00199] In step 18, the service 104 receives the new signed first stage key update response 192 from the device 102 during execution of the second execution stage 106b and/or any other subsequent execution stage of the device 102 as newly received signed first stage key update response 193. The service 104 is configured to check or validate the signature of the received new signed first stage key update response 193 using the Device Public Key 185a stored on the server(s) hosting the service 104. The received new signed first stage key update response 193 may be authenticated using signature validation, where the service 104 may use the Device Public Key 185a for validating/decrypting the newly received signed first stage key update response 193. For example, the signature validation may be based on, by way of example only but not limited to, Elliptic Curve Digital Signature Algorithm (ECDSA) and/or any other suitable signature/cryptographic algorithm for validating and/or decrypting the signed first stage key update response 193. This may signal and/or verify to the service 104 that the device 102 has performed the new secret key refresh and has a new first stage key 172. The service 104 may retrieve the DPbKX data 187d (e.g. CKX), which is derived from the DPrKX data 187b, and the first key generation counter value 184a of the device 102 from the received new first stage key update response 193.

[00200] In step 19, the service 104 checks that the first key generation counter value 184a of the device 102 matches the first key generation counter value 184b controlled by the service 104. If there is a mismatch, then the service 104 may initiate another public key mode refresh and return to step 1, and/or perform trust management in relation to the device 102. If the counter values 184a and 184b match, then the service 104 may proceed to step 20 for generating a new first stage key. In step 20, the service 104 is configured to use the SPrKX data 187a and the newly received DPbKX data 187d (e.g. CKX), which was received in the signed first stage key update response 193, to compute a new first stage key 191b. For example, the service 104 may use the newly received DPbKX data (e.g. MC) and SPrKX data 187a in an algorithm for creating the new first stage key 191b, which is an equivalent algorithm to that which used the SPbKX data 187c (e.g. SKX) and DPrKX data 187b to create the first stage key 191a on the device 102 in step 11. Thus, the newly received DPbKX data (e.g. CKX) and SPrKX data 187a is used to create a new first stage key 191b for the service 104 that is the same as the new first stage key 191a of device 102.

[00201] In step 21, once the service 104 has generated the new first stage key 191b, the service 104 may securely store a copy of the new first stage key 191b by replacing the previously stored first stage key 127 of the service 104 with the new first stage key 191b. Thus, the first stage key 127 in relation to the device 102 has been updated on the server hosting the service 104 with the new first stage key 191b. The updated copy of the first stage key 127 may be used to validate attestation data received from device 102 including attestation codes/tags and other values as described with reference to figures la-4, combinations thereof, modifications thereto and/or as described herein. It can also be used to generate next stage keys for use in encrypted communications with device 102 and the like and/or as described herein. The service 104 stores the new first stage key 127 for use in the iterative key generation, attestation and/or authentication protocols and the like as described with reference to figures la-4, combinations thereof, modifications thereto and/or as described herein. In some examples of figures la-4 and/or as described herein, the hardware stored secret 112 (or hardware stored secret 110) may be used by the first execution stage 106a (or first execution stage 106a) as the first stage key 172 (or first stage key 210a), but may be replaced with the first stage key 127 of the service 104 as described herein. The new secret key refresh (or key update) does not significantly increase the resources required on the device 102, but it enhances the security of the device 102 as new second stage keys 174 and/or subsequent stage keys and new attestation data 122a-122c may be generated based on the new first stage key 172, where it is unlikely an attacker can derive the new first stage key 172.

[00202] Although the signature operations of steps 4-5,8, and/or 13 are described using ECDSA, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the signature operations of steps 4-5, 8, and/or 13 may be performed by any suitable cryptographic/signature algorithm and the like as the application demands. Although the key exchange operations of steps 2, 2a, 10-11, and/or 20 are described using ECDH, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the key exchange operations of steps 2, 2a, 10-II, and/or 20 may be performed by any suitable cryptographic/signature key exchange algorithm and/or the like as the application demands. Although it is described that the device 102 stores the Service Public Key 182a in non-volatile memory, which may be protected by a Service Public Key integrity protection mechanism 183, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that any other suitable mechanism or process may be used by device 102 and/or service 104 to ensure the device 102 has a trusted copy of the Service Public Key 182a and/or as the application demand. For example, the device 102 may simply securely store a trusted hash of the Service Public Key 182a in non-volatile memory and/or in encrypted form in memory 108, where said Service Public Key 182a is sent in the signed first stage key update request 188b and stored, by the device 102, in memory 108 or permanent storage on device 102. The trusted hash may be used to verify that the received Service Public Key 182a is valid. Alternatively or additionally, the system 180 may use, without limitation, for example, signature chaining such that the trusted copies of the Service Public Key and Device Public Keys 182a and 185a are infrequently or indirectly used. For example, in this case, the Service Private Key 182b is not used to sign the key update request. Instead, it is used to sign an intermediate private signing key. That intermediate key is used to sign the key update request. The device 102 may retain a trusted copy of the Service Public Key 182a or just a digest of the Service Public Key 182a.

This approach allows the Service Private Key 182b to be infrequently used, which is much safer. The recipient verifies the Service Public Key 182a against the stored hash if necessary, then uses the Service Public Key 182a to verify the signature of Intermediate Public Key, and then uses Intermediate Public Key to verify the signature of the key update request. Additionally or alternatively, two or more intermediaries could be chained into a single long chain.

[00203]As a further example of securely storing the Device Private Key 185b, Service Public Key 182a, and first stage key 172, the hardware stored secret 112 that is in secret storage may be used for encrypting or securing NVM storage that stores the Device Private Key 185b, Service Public Key 182a, and first stage key 172. When access to the hardware stored secret 112 is, for example, turned off, then the NVM storage can no longer be decrypted.

Given it is encrypted, the NVM storage storing the Device Private Key 185b, Service Public Key 182a and first stage key 172 still has the same properties as the secret storage memory storing the hardware stored secret 112. The device 102 is configured to make these only accessible to the initial bootloader of the first execution stage 106a when required. This may be achieved by using the hardware stored secret to decrypt the NVM storage storing the encrypted Device Private Key 185b, Service Public Key 182a, and encrypted first stage key 172. When the hardware stored secret 112 is turned off and on, then this turns off and on the access to the encrypted NVM storage and hence the access to Device Private Key 185b, Service Public Key 182a, and first stage key 172. Given that these are decrypted, there is also a decrypted version of the Device Private Key, Service Public Key and first stage key in memory 108 and/or any volatile memory RAM of device 102. When access is removed to the encrypted NVM storage, then any data representing the plaintext versions of the Device Private Key, Service Public Key, and first stage key are removed from memory 108 and/or volatile RAM. Although the hardware stored secret 112 may be used for encrypting NVM storage that stores the Device Private Key 185b, Service Public Key 182a and first stage key 172, it is to be appreciated by the skilled person that the hardware stored secret 112 may be used for simply encrypting the Device Private Key 185b, Service Public Key 182a and/or first stage key 172 and which may be stored in memory 108 in encrypted form. It is to be appreciated by the skilled person that any other form of secure storage of the Device Private Key 185b, Service Public Key 182a and first stage key 172 may be applied or used based on the hardware stored secret 112 and/or as the application demands.

[00204]Although the shared mode of operation process(es) and/or public key mode of operation process(es) of figure le has been described, by way of example only but is not limited to, with reference to figure le and/or the attestation systems 100, 160 and 180 of figures la-le, it is to be appreciated by the skilled person that the shared or public key mode of operation as described with reference to figure le may be combined, modified, applied and/or used by the iterative key generation and attestation system 200 and process(es) 220 and/or 230 as described with reference to figures 2a-2d and/or the attestation and iterative key generation process(es) 300 and 330 as described with reference to figures 3a-3d, combinations thereof, modifications thereof, and/or as the application demands.

[00205] Figure 2a is a schematic diagram illustrating an example of iterative key and/or attestation data generation system 200 according to the invention. The system 200 includes a constrained device 202 and a remote service 104 (i.e. a trusted device) hosted by one or more servers. The one or more servers may be distributed and/or networked to form, by way of example only but is not limited to, a cloud platform 103. The device 202 includes a processing unit (not shown), a memory 208, and a communication interface (not shown), where the processing unit connects with the memory 208 and communication interface. The communication interface may be used for communicating 219 with the service 104 hosted by the one or more servers or cloud platform 103. The device 202 is configured to have multiple execution stages 206a-206m that sequentially execute on the device 202 some of which may communicate with service 104 hosted by one or more servers. In the iterative key and/or attestation data generation system 200, the device 202 is configured to iteratively generate execution stage keys 210a-210m and attestation data 212a-212m. The device 202 may be based on device 102 as described with reference to figures la-1e and is configured to iteratively generate attestation data 212a-212I and execution stage keys 210b-210m in relation to one or more subsequent execution stages 206b-206m after the first execution stage 206a. For example, during execution of a current stage of execution 206b, a set of execution stage key(s) 210c and/or attestation data 212b for the next execution stage 206c are generated. Each of the set(s) of execution stage keys 210a-210m may be used by the corresponding execution stage 206a-206m as, by way of example only but is not limited to, cryptographic keys for encryption/decryption and/or cryptographic communications, authentication, cryptographic signatures, or secure data storage, and/or for use in an attestation protocol with service 104 hosted by one or more servers as described with reference to figures la-le and/or as herein described.

[00206] As described, each execution stage consecutively or sequentially executes on the device 202 after the previous execution stage is completed execution. In this example, there are M execution stages 206a-206m, which are configured to sequentially execute one after the other. For example, the first execution stage 206a (e.g. Stage 1) is associated with an initial bootloader (e.g. Boot loader 0), which is considered to be trusted code, where the device 202 executes the first execution stage 206a (e.g. the initial bootloader stored in ROM or NVM) when it reboots or starts up. The second execution stage 206b (e.g. Stage 2) may be associated, by way of example only but is not limited to, a second bootloader (e.g. boot loader 1) and/or application firmware and the like (e.g. OEM/flash bootloader, application(s) and/or other software), where the device 202 is configured to execute the code associated with the second stage of execution 206b once the first stage of execution 206a has completed or terminated its execution and booted the second stage of execution 206b. Once the second stage of execution 206b completes or terminates executing, the device 202 is configured to execute the code associated with the third stage of execution 206c (e.g. Stage 3), which may include, by way of example only but is not limited to, a further boot loader (e.g. boot loader 2) and/or further application firmware the like (e.g. Net-boot, recover and/or applications or any other software and the like). This continues sequentially for the subsequent execution stages 206I-206m until the execution of the code associated with the M-th execution stage 106m, which may be associated with bootloader M+1 and/or application firmware or other software and the like. Thus, each execution stage of the plurality of execution stages 206b-206m is configured to sequentially execute after the immediately preceding execution stage 206a-2061 has completed execution or has terminated execution of its corresponding code on the device 202. The device 202 is further configured to not require different levels of privileges and does not provide runtime separation of privileges.

[00207] Initially, when the device 202 is booted, the device 202 is configured to execute the first stage of execution 206a. The first stage of execution 206a may use a first set of one or more execution stage keys (e.g. Key(s) 1), which may be derived from a hardware stored secret 210. In this example, a first execution stage key or first stage key 210a is originally derived from the hardware stored secret 210. The hardware stored secret 210 is accessible via hardware/registers and/or memory 208 of the device 202 during execution of a first execution stage 206a of device 202. The device 202 is configured to control access to the hardware stored secret 210, which is controlled to be accessible during execution of the first stage of execution 206a and controlled to be inaccessible to all subsequent stages of execution 206b-206m prior to execution of these stages of execution 206b-206m. The memory 208 may be non-volatile memory that is read/writeable and accessible by all execution stages 206a-206m. In this example, the device 202 has M execution stages 206a-206m (i.e. a first stage of execution 206a and M-1 subsequent stages of execution 206b- 206m), where itc.insM, where each execution stage is associated with a corresponding set of computer code or instructions stored on the accessible memory 208 and/or ROM/NVM (not shown) of the device 202 and that is configured to execute on the device 202 during execution of said execution stage. The execution stages 206a-206m consecutively or sequentially execute on the device 202.

[00208] In this example, the device 202 is configured to have one or more bootloader(s) and/or multiple bootloaders and one or more application firmware(s) stored thereon. The multiple bootloaders and application firmware(s) are executed in a staged manner on a corresponding one of the multiple execution stages 206a-206m. For example, the first execution stage 206a (e.g. Stage 1) includes, by way of example but is not limited to, an initial bootloader (e.g. Bootloader 0) that may be stored on ROM of the device 202, which may be considered to be trusted code; the second execution stage 206b (e.g. Stage 2) includes, by way of example but is not limited to, a second bootloader (e.g. Bootloader 1) that may be, by way of example but is not limited to, an original equipment manufacturer (OEM) bootloader stored in memory 208; the third execution stage 206c (e.g. Stage 3) includes, by way of example but is not limited to, a third bootloader (e.g. Bootloader 2) that may be, by way of example but is not limited to, a network bootloader for recovery; a fourth execution stage (not shown) may include, by way of example but is not limited to, another boot loader and/or application firmware and the like; and subsequent execution stages up to execution stage 206m may include either further bootloaders and/or application firmware and the like. Although the first to third execution stages 206a-206c are shown to include various bootloader(s), this is by way of example only and the device 202 is not so limited, it is to be appreciated by the skilled person that any arrangement of bootloader(s) and/or application firmware or other software may be placed/used in relation to each execution stage 206a-206m as the application demands.

[00209] Initially, the first execution stage 206a (e.g. Stage 1) is enabled to have access to a first stage key 210a on the device 202. The first stage key 210a (e.g. Key(s) 1) may be derived from a hardware stored secret or key 210. The device 202 is configured to generate the first stage key 210a from the hardware stored secret 210 and also configured to allow the hardware stored secret 210 and the first stage key 210a to be accessible only to the first execution stage 206a during execution of the first execution stage 206a and inaccessible thereafter to all subsequent execution stages 206b-206m. During execution of the first execution stage 206a, a second stage key 210b (e.g. Key(s) 2) is generated for use by the second execution stage 206b (e.g. Stage 2) based on the first stage key 210a, which is only accessible by the first execution stage 206a, and, by way of example only but not limited to, a device counter 214 and/or key usage parameter (not shown). The second stage key 210b may be generated in a similar fashion as described in relation to the first stage key(s) 172 and/or second stage key(s) 174 with respect to figure la to le and/or as described herein. The generated second stage key 210b is stored in accessible memory storage 208 on the device 202 for access and use by the second execution stage 206b. The first stage key 210a is accessible for use by the first execution stage 206a during execution of the first execution stage 206a on the device 202 and is inaccessible thereafter to all subsequent execution stages 206b-206m.

[00210] Additionally or alternatively, during execution of the first execution stage 206a (e.g. Stage 1) the first execution stage 206a is configured to generate attestation data 212a (e.g. Attest S2) for the second execution stage 206b (e.g. Stage 2). The attestation data 212a for the second stage of execution 206b may be generated based on data representative of the first stage key 210a, the device counter 214, and a measurement 218b (e.g. a digest) associated with the data comprising the second execution stage 206b. The measurement 218b of the second execution stage 206b may include generating data representative of a digest in relation to the data comprising the second execution stage 206b. The attestation data 212a in relation to the second stage of execution 210b may be generated in the same or similar fashion or manner as the attestation data for the second and/or subsequent stages 106b of device 100 as described with reference to figures la to le.

[00211] The attestation data 212a is stored in memory 208 and may be used, once a network session or communication session 219 has been established with one or more server(s) hosting a service 104, in an attestation protocol in which the device 202 sends the attestation data 212a to the service 104 to prove the device 202 is what it says it is and for the service 104 to determine an indication of trustworthiness of the device 202. This will allow the service 104 and/or other services to trust the data produced by the device 202 and/or communications 219 and the like with device 202. The attestation data 212a for the second execution stage 206b may be sent to a service 104 for attesting at least the second execution stage 206b of the device 202. The attestation data 212a may be sent during execution of the second execution stage 206b should network communications 219 be established with one or more server(s) hosting the service 104 during execution of the second execution stage 206b.

[00212] Alternatively, the attestation data 212a may be sent to the service 104 during execution of the first execution stage 206a, should there be functionality for this in the first execution stage 206a. Alternatively or additionally, the attestation data 212a may be stored in memory 208 in an attestation object or container 212, which may aggregate attestation data 212a-2121 in relation to one or more subsequent stage(s) 206b-206m until such time that network communications 219 is established with a server hosting the service 104, whereby the attestation object or container 212 is sent to the service 104 in relation to the attestation protocol between device 202 and service 104. The attestation object or container 212 may comprise data representative of one or more attestation data 212a-2121 (e.g. Attest S2 to Attest SM) associated with corresponding one or more subsequent stages of execution 206b-206m (e.g. Stages 2 to M). Once network communications 219 have been established, each subsequent stage of execution that is executed thereafter may send attestation data for that subsequent execution stage individually as opposed to aggregating all attestation data into one attestation object or container 212.

[00213] As described, the attestation data 212a (e.g. Attest S2) may be generated in a similar fashion as described in relation to the attestation data 122a-122c as described with respect to figures 1a to le. The access to the first stage key 210a is disabled for all execution stages 206b-206m during or after execution of the first execution stage 206a on the device 202, but prior to execution on the device 202 of any subsequent execution stages 206b-206m. This may be achieved by, by way of example only but is not limited to, overwriting the first stage key 210a in the accessible memory 208 with zeros or a new key and the like, and/or encrypting the first stage key 210a and removing any plaintext data representative of the first stage key 210a, and/or any other mechanism or method as the application demands. For example, the first stage key 210a may be made inaccessible based on the same or similar manner, fashion or approach as described in relation to the device 102 as described with respect to figures la to le and/or as described herein. The second execution stage 206b (e.g. Stage 2) has access to the second stage key 210b stored in memory 208.

[00214] This process of key generation of the next execution stage key 210c (e.g. Key(s) 3) and generation of attestation data 212b (e.g. Attest 33) for the next subsequent execution stage 206c is repeated during execution of the second execution stage 206b. For example, during execution of the second execution stage 206b, a third stage key 210c (e.g. Key(s) 3) is generated for use by the third execution stage 206c (e.g. Stage 3) based on the second stage key 210b that is accessible by the second execution stage 206b (e.g. Stage 2) and, by way of example only but not limited to, the device counter 214 and/or a key usage parameter (not shown) and the like. The third stage key 210c may be generated in the same or a similar fashion as described in relation to the first stage key(s) and/or second stage key(s) 174 with respect to figure 1a to le and/or as herein described. The generated third stage key 210c (e.g. Key(s) 3) is stored in accessible memory storage 208 on the device 202 for access and use by the third execution stage 206c (e.g. Stage 3). The second stage key 210b is accessible for use by the second execution stage 206b (e.g. Stage 2) during execution of the second execution stage 206b on the device 202 and inaccessible thereafter to all subsequent execution stages 206c-206m (e.g. Stages 3 to M).

[00215] Additionally or alternatively, during execution of the second execution stage 206b, attestation data 212b (Attest S3) in relation to the third execution stage 206c may be generated based on data representative of the second stage key 210b (e.g. Key(s) 2), the device counter 214, and, by way of example only but not limited to, a digest 218c associated with the third execution stage 206c. Should network communications 219 not yet be established with the server hosting the service 104, the attestation data 210b (e.g. Attest S3) for the third stage of execution 206c may be stored in the attestation object/container 212 to form an aggregate of the attestation data 212a-212b for the execution stages 206b and 206c, respectively. The attestation data 212b associated with the third execution stage 206c may be sent to the service 104, once communication 219 with the server hosting the service 104 has been established, for use in an attestation protocol attesting at least the third execution stage 206c of the device 202. The attestation data 212b (e.g. Attest S3) may be sent during execution of the third execution stage 206e. Alternatively and/or additionally, the attestation data 212b (e.g. Attest 33) may be sent to the service 104 during execution of one of the subsequent execution stage(s) 2061, which may be configured to send the aggregated attestation data 212 comprising one or more of the attestation data 212a-2121 for one or more (or all) previous stages of execution 210a-210Iand/or the current stage of execution 2101 by sending the attestation object/container 212 to the server hosting the service 104.

Alternatively, the attestation data 212b (e.g. Attest S3) may be sent to the service 104 during execution of the second execution stage 206b, should there be functionality for this and/or the second execution stage 206b has established network communications 219 with the server hosting the service 104 and the like. The attestation data 212b (e.g. Attest S3) may be generated in a similar fashion as described in relation to the attestation data 122a-122c with respect to figures la to le and/or as described herein. The access to the second stage key 210b (e.g. Key(s) 2) in memory 208 may be disabled for all execution stages 206c-206m during or after execution of the second execution stage 206b on the device 202, but prior to execution on the device 202 of any subsequent execution stages 206c-206m. This may be achieved by overwriting the second stage key 210b in the accessible memory 208 with zeros or a new key and the like, and/or encrypting the second stage key 210b and removing any plaintext data representative of the second stage key 210b, and/or any other mechanism or method as the application demands. For example, the second stage key 210b may be made inaccessible based on the same or similar manner, fashion or approach as described in relation to the first stage key and/or hardware stored secret of device 102 as described with respect to figures la to le and/or as described herein. The third execution stage 206c (e.g. Stage 3) has access to the third stage key 210c (e.g. Key(s) 3) stored in memory 208.

[00216] This process is repeated for subsequent stages after the third execution stage 206c through to the M-th execution stage 206m, where the M-th execution stage 206m does not perform key generation or attestation data generation but rather executes the M-th execution stage 206m and, if necessary, uses the (M)-th stage key 210m (e.g. Key(s) M) generated by the previous execution stage 2061 for cryptographic operations with the service 104 and the like. Furthermore, if the M-th execution stage 206m is the only one that establishes communication 219 with server of the service 104, then the M-th execution stage 206m may send the aggregated attestation data object/container 212 that includes data representative of the attestation data 212a-2121(e.g. Attest 82 to Attest SM) for the second stage of execution 206b through to the M-th stage of execution 206m. Alternatively or additionally, the M-th stage of execution 206m may be configured to send only the attestation data 2121 (e.g. Attest SM) of the M-th stage of execution 206m to the server hosting the service 104.

[00217] Each of the attestation data 212a-2121(e.g. Attest S2 to Attest SM) of the corresponding stages of execution 206b-206m may be retained/aggregated in memory 208 and sent as a batch of attestation data by, by way of example only but not limited to, appending to or including the attestation data 212a-2121 in an attestation object or container 212. The attestation object or container 212 may include or comprise data representative of the previous and current attestation data 212a-2121 (e.g. Attest S2 to Attest SM) of the previous and current stages of execution 206b-206m apart from the first execution stage 206a. This produces a chain of attestation data 212a-212I, derived with different key derivation functions. The aggregated attestation object or container 212 may be sent, once communications 219 have been established, to the server hosting a service 104 executing an attestation protocol as described herein with reference to figures la-4 in relation to device 202. Additionally or alternatively, after a certain number of stages of execution 206a-206b have executed in which network communications 219 have been established between device 202 and server hosting the service 104, the service 104 may prompt the sending of a batch of attestation data 212 including attestation data 212a-212b (e.g. Attest S2 to Attest S3) for the certain number of execution stages 206a-206b to the server, any subsequent or new attestation data 212c-2121(e.g. Attest S4 to Attest SM) that is generated for subsequent stages of execution may be sent individually and/or one at a time to the server of the service 104, which will enable the service 104 to execute the attestation protocol on each subsequent stage of execution prior to execution of said subsequent stage of execution.

[00218] Figure 2b is a flow diagram illustrating an example iterative key generation process 220 for device 202 as described with reference to figure 2a having at least a first execution stage 206a and at least a next execution stage 206b of a set of execution stage(s) 206a-206m, where each of the execution stage(s) 206a-206m is associated with a corresponding set of computer code or instructions stored on the device 202 and that is configured to execute on the device 202 during execution of said execution stage 206a-206m, and where each execution stage 206a-206m consecutively or sequentially executes on the device 202.

The iterative key generation process may include the following steps of: In step 222, enabling the first execution stage 206a to have access to a first stage key 210a on the device 202. In step 224, generating, during execution of the first execution stage 206a (e.g. Stage 1), a next stage key 210b (e.g. Key(s) 2) for use by a next execution stage 206b based on the first stage key 210a accessible by the first execution stage 206a and a device counter 214. In step 226, storing the generated next stage key 210b (e.g. Key(s) 2) in accessible storage 208 on the device 202 for access and use by the next execution stage 206b (e.g. Stage 2). In step 228, disabling access to the first stage key 210a prior to execution of the next execution stage 206b and/or any subsequent execution stages 206c-206m. The first stage key 210a is accessible for use by the first execution stage 206a during execution of the first execution stage 206a on the device 202 and inaccessible thereafter.

[00219] In addition, the process 220 may further include, during execution of the first execution stage 206a, generating an attestation data 212a (e.g. Attest S2) for the next execution stage 206b (e.g. Stage 2) in which the attestation data 212a includes data representative of an attestation code generated from the first stage key 210a, a device counter 214, and/or a digest 218b associated with the next execution stage 206b. The attestation data 212a may further include data representative of the device counter 214 and/or digest 218b of the next execution stage 206b (e.g. Stage 2). The attestation data 212a (e.g. Attest S2) of the next execution stage may be stored in memory 208 of the device 202 for sending to the server hosting the service 104, where the attestation data 210a (e.g. Attest S2) of said next execution stage 206b is used by the server for determining an indication of trust in relation to the device 202 and/or said next execution stage 206b (e.g. Stage 2). The next execution stage 206b (e.g. Stage 2), during execution, may send the attestation data 210a (e.g. Attest 52) of said next execution stage 206b to the service 104 for use in attestation of the device 202 and/or said next execution stage 206b. Alternatively or additionally, the attestation data 210a (e.g. Attest S2) of said next execution stage 206b may be stored and aggregated in memory 208 in an attestation object or container 212 along with one or more further attestation data 212c-212I in relation to one or more subsequent stages of execution 206c-206m, and once communications 219 have been established with the server, the attestation object or container 212 is sent to the server for determining an indication of trust in relation to the received attestation data 212a-2121 of each stage of execution 206b- 206m of the device 202.

[00220] Figure 2c is a flow diagram illustrating another example iterative key generation process 230 for use with a device 202 and a service 104 hosted by one or more servers as described with reference to figures 2a-2b in which the device 202 has M executable stages, where M>1. In this example, the device 202 includes a number of M consecutive execution stages 206a-206m that sequentially execute on the device 202, where 1 S m S M. During execution of the m-th execution stage, where m=/, the process 230 may include the following steps of: In step 232, when setting m=/, executing the m-th execution stage (e.g. first execution stage 206a) and generating an (m+1)-th stage key for the (m+1)-th execution stage (e.g. second execution stage 206b), during execution of an m-th execution stage, based on an m-th stage key accessible to the m-th execution stage and the device counter 214 (or a nonce/changing value). In step 234, storing the (m+V-th stage key in accessible storage for use by the (m+1)-th execution stage. During execution of the m-th execution stage (e.g. the first execution stage 206a or Stage 1), the m-th stage key may be used for cryptographic operations/activities such as, without limitation, for example, attestation, encryption/decryption and/or authentication and the like and/or as the application demands. For example, for attestation, step 234 may include generating and storing an attestation data for the (m+/)-th execution stage (e.g. the second execution stage 206b), during execution of the m-th execution stage, based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage. Furthermore, access to the m-th key for all execution stages during or after execution of the m-th execution stage on the device 202 is disabled prior to execution on the device 202 of any subsequent execution stage (e.g. prior to execution of the (m+1)-th execution stage). In step 236, when execution of the m-th execution stage is, without limitation, for example completed (or nearing completion or after completion) and prior to the (m+1)-th execution stage needs to be booted or executed, m is incremented, where m=m+i and proceeding to step 238.

[00221] In step 238, it is determined whether m<M, if m<M, then proceeding to step 240, otherwise proceeding to step 250. In step 240, executing the m-th execution stage and generating an (m+1)-th stage key for the (m+1)-th execution stage, during execution of an mth execution stage, based on an m-th stage key accessible to the m-th execution stage (and generated by the (m-1)-th execution stage). Generation of the (m+1)-th stage key may be based on using a KDF with the m-th stage key as input. Further inputs may include one or more key usage parameters, any other input data and the like or as the application demands. For example, the device counter 214 may be used as an input to the KDF. In step 242, storing the generated (m+1)-th stage key in accessible storage for use by the (m+1)-th execution stage. In step 244, performing during execution of the m-th execution stage cryptographic operafion(s)/activity(ies), if any, requiring use of the m-th stage key (generated during execution of the (m-V-th execution stage). For example, without limitation, for attestation this may include generating an attestation data for the (m+V-th execution stage, during execution of the m-th execution stage, based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage. In step 246, disabling access to the m-th key for all execution stages during or after execution of the m-th execution stage on the device 202, but prior to execution on the device 202 of any subsequent execution stage (e.g. prior to execution of the (m+1)-th execution stage). For example, the m-th stage key being accessible to the m-th execution stage during execution and inaccessible to any n-th execution stage, where m<n, after execution of the m-th execution stage and prior to execution of said any other n-th execution stage. The execution of the m-th execution stage may be completed or terminated. In step 248, incrementing m (e.g. m=m+i) (e.g. on completion, prior to completion or after completion of the m-th execution stage) and proceeding to step 238. In step 250, this is the final M-th execution stage, thus once m=M, the M-th execution stage is executed and may access and use the M-th stage key generated by the (M-/)-th execution stage where applicable during execution of the M-th execution stage. For example, the M-th execution stage may perform during execution of the M-th execution stage cryptographic operation(s)/activity(ies), if any, requiring use of the M-th stage key (generated during execution of the (M-1)-th execution stage).

[00222] When m=1, the 1-th stage key corresponds to the first stage key 110a, which may be derived from a hardware stored secret 110 in secure storage on the device 102. The first stage key 11Oa may be the hardware stored secret 110. The 1-th execution stage 106a corresponds to the first execution stage 106a, where the first stage key 110a is being accessible to the first execution stage 106a during execution and inaccessible to /<m<=M subsequent execution stages 106b-106m after execution of the first execution stage 106a and prior to execution of any other /<m<=M of the subsequent execution stages 106b-106m.

[00223] Steps 232, 240, 244 and/or 250 may further include, for m>1, where applicable and when communications 219 have been established with the server hosting the service, performing cryptographic operations and/or activities with the service or server hosting the service. For example, sending attestation data of the m-th or previous execution stages to the service 104 for use in attesting and/or determining an indication of trust in relation to the device 202 and/or said at least the m-th execution stage of the device. When m=1, there is no attestation data for the first execution stage 206a because the first execution stage 206a may be assumed to be trusted.

[00224] Alternatively, step 232 may be modified along the following lines in which the first stage key is derived from a hardware stored secret. Step 232 may be changed to include, when m=1, generating the 1-stage key (e.g. first stage key 210a) based on a key derivation function with a stored secret 210 (or hardware stored secret) and the device counter 214, and generating an (m+1)-th stage key for the (m+1)-th execution stage, during execution of the 1-th execution stage, based on an 1-th stage key accessible to the 1-th execution stage, where the 1-stage key (e.g. first stage key) and the stored secret is accessible to the 1-th execution stage during execution and inaccessible to i<m<=M subsequent execution stages after execution of the 1-th execution stage and prior to execution of any other i<m<=M subsequent execution stages. Generating the (m+1)-th stage key for the (m+1)-th execution stage may include using a key derivation function to generate said (m+1)-th stage key based at least on the 1-th stage key.

[00225] The service 104 hosted by the one or more servers may be configured to perform the same or a similar manner of operations, or reciprocal operations, of deriving the next stage keys for use in cryptographic operations and/or activities with the device 202, where the device 202 includes a number of M sequential execution stages, where i<=m<=M. The service 104 may have data representative of a copy of the 1-th stage key (e.g. first stage key) of the device, which may be derived from a manifest and/or key exchange protocol with the device 202 (e.g. see for example key exchange and/or secret refresh process(es) of figures 2e to 3d). The service 104 may be configured to perform a process based on the following steps of: generating an (m+1)-th stage key for the (m+1)-th execution stage based on an m-th stage key generated for the m-th execution stage: storing the (m+1)-th stage key in accessible storage for use in cryptographic operations including encryption/decryption or attestation operations with the device 202 in relation to the (m+1)-th execution stage, where when m=/, the generated 1-th stage key corresponds to data representative of the copy of the first stage key and the 1-th execution stage corresponds to the first execution stage of the device.

[00226] The step of generating the (m+/)-th stage key in relation to the (m+1)-th execution stage may further include using a key derivation function to generate said (m+i)-th stage key based at least on the m-th stage key. Alternatively of additionally, the step of generating the (m+/)-th stage key in relation to the (m+1)-th execution stage may further include using a key derivation function to generate said (m+i)-th stage key based at least on the m-th stage key and a trusted counter such as a server counter 122c of figures Id or le and/or a received device counter of the device.

[00227] The data representative of the copy of the first stage key is a stored secret shared between the service 104 and the device 202, when m=/, generating the (m+/)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+i)-th stage key based at least on the 1-th stage key and the service counter (or trusted counter tracking the device counter), or a received device counter, wherein 1-th stage key is data representative of the copy of the first stage key. Additionally or alternatively, the 1-th stage key may be generated based on generating data representative of the copy of the first stage key or 1-th stage key based on a key derivation function with a stored secret and the service counter (or trusted counter tracking the device counter, or received device counter), wherein the stored secret is shared between device and server hosting the service 104.

[00228] Although some key generation steps performed by the server hosting the service have been described, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the server hosting the service may perform the same or similar manner of steps, or a reciprocal set of steps, as outlined in figure 2c at the server hosting the service in which the 1-th stage key is a copy of the 1-th stage key of the device, the device counter used the process 230 of figure 2c may be replaced with a server counter or trusted counter that tracks the device counter and/or a received device counter value may be used, and/or the 1-th stage key is a secret key that has been exchanged between server and the device based on a secret key refresh and/or key exchange protocol as outlined, without limitation, for example with reference to figures 1e and/or 3a-3d and/or as the application demands.

[00229] Figure 2d is a flow diagram illustrating another example iterative key generation and attestation process 260 for use with a device 202 and a service 104 hosted by one or more servers as described with reference to figure 2a in which the device 202 has M executable stages, where M>1. The device 202 includes a number of M consecutive execution stages 206a-206m that sequentially execute on the device 202, where 1<=m<=M. During execution of the m-/h execution stage, where m=1, the process 260 may include the following steps of: In step 262, determining whether m<M, if m<M, then proceeding to step 264, otherwise proceeding to step 274. In step 264, executing the m-th execution stage and generating an (m+1)41i stage key for the (m+1)-th execution stage, during execution of an m-/h execution stage, based on an m-/h stage key accessible to the m-th execution stage and the device counter 214. In step 266, storing the (m+1)-th stage key in accessible storage for use by the (m+1)-th execution stage. In step 268, generating, without limitation, for example an attestation data for the (m+i)-th execution stage, during execution of the m-/h execution stage, based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage. In step 270, disabling access to the m-/h key for all execution stages during or after execution of the m-/h execution stage on the device 202, but prior to execution on the device 202 of any subsequent execution stage (e.g. prior to execution of the (m+1)4h execution stage). In step 272, incrementing m (e.g. m=m+i) and proceeding to step 232. In step 274, executing the M-th execution stage using the M-th stage key generated by the M-=1-th execution stage where applicable during execution of the M-th execution stage.

[00230] When m=1, the 1-th stage key corresponds to the first stage key 210a, which may be derived from a hardware stored secret 210 in secure storage on the device 202, and the 1-th execution stage 206a corresponds to the first execution stage 206a, where the first stage key 210a is being accessible to the first execution stage 206a during execution and inaccessible to 1<rn<=M subsequent execution stages 206b-206m after execution of the first execution stage 206a and prior to execution of any other i<m<=M of the subsequent execution stages 206b-206m.

[00231] The step of 264 for generating the (m+1)-th stage key for the (m+1)-th execution stage may further include using a key derivation function to generate said (m+1)-th stage key based at least on the m-th stage key and the device counter. Step 268 may further include, for m>1, where applicable and when communications 219 have been established with the server hosting the service, sending the attestation data of the m-th execution stage to the service 104 for attesting and/or determining an indication of trust in relation to the device 202 and/or said at least the m-th execution stage of the device. When m=1, there is no attestation data for the first execution stage 206a because the first execution stage 206a is assumed to be trusted.

[00232]Although some key generation steps performed by the server hosting the service have been described, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the server hosting the service may perform the same or similar set of steps, or a reciprocal set of steps, as outlined in figure 2d at the server hosting the service in which the 1-th stage key is a copy of the 1-th stage key of the device, the device counter used the process 260 of figure 2d may be replaced with a server counter that tracks the device counter and/or a received device counter value may be used, and/or the 1-th stage key is a secret key that has been exchanged between server and the device based on a secret key refresh and/or key exchange protocol as outlined, without limitation, for example with reference to figures le and/or figures 3a-3d and/or as the application demands.

[00233] Figures 3a and 3b are a flow diagram illustrating an example attestation process 300 for an loT device (or any other constrained device) and corresponding service hosted by one or more server(s) that is based on, by way of example only but is not limited to, using a hash-based key derivation function (HKDF) to create a key to use for proving software identity of one or more stages of execution of an loT device with a refreshable secret in accordance with the invention. As an option, the attestation process 300 may further include proving the loT device identity using a mechanism based on another key created using a hash-based key derivation function (HKDF). The attestation systems 100, 160, 180, and devices 102, 200, services 104, process(es) 140, 150, 220, 230 as described with reference to figures la to 2c may be further modified to include the corresponding features of the example attestation process 300, where the same and/or similar features of figures 1a-2c are shown, by way of example only but is not limited to, in parentheses with the same or similar features describing the attestation process 300. In essence, the attestation process 300 is configured to create two or more key(s) for each execution stage of the loT device. One key for an execution stage is used for attestation as the key to the HMAC of the digest of the code for a subsequent execution stage to produce an attestation code/tag (e.g. attestation code/tag 122a of figures la-1e), this is the software identity. The other keys for each stage can be used for any form of authentication of the device (e.g. the device identity) and/or cryptographic communications between loT device and service and the like. Examples would be to use it as a Pre Shared Key for TLS or as the key in a challenge-response protocol etc. [00234] In this example, the loT device's bootloader (e.g. bootloader of the first execution stage 106a of figures 1a-le) has a secret (e.g. hardware stored secret 112 or first stage key 172 of figures la-1e) that it shares with the service. At boot time, the bootloader hashes the target memory sections (e.g. application firmware or second executable stage 106b of figures 1a-1e), creates a document that describes the target memory sections, consisting of a list of hashes. It adds a generation counter (EpochCounter or i) and a monotonic counter (CohortCounter or j) to the document, then MACs the document with its secret key that is shared with the service by publishing the document and the MAC of the document in an area that the service client can load. The generation counter is updated every time the key is refreshed. The monotonic counter is updated with every boot (or attestation). The bootloader 0 must hide its secret key from the next execution stage, which may include application firmware and/or a next-stage bootloader (e.g. bootloader 1 etc.) [00235] The loT device has multiple stages of execution that execute sequentially. For example, the loT device may execute bootloader 0 in the first stage of execution, once the first stage of execution has completed, the next stage of execution (e.g. second stage of execution) may be booted and execute a bootloader 1 and/or application firmware 1 and the like, once the second stage of execution has completed, a subsequent stage of execution, if any, may be booted and execute a further bootloader 2 and/or application firmware 2 and the like, this proceeds until all execution stages of the loT device have executed. The execution stages of the loT device may be executed sequentially in a particular order. Referring to figures 3a and 3b, the attestation process 300 may further include the following steps of: [00236] In step 302, the device is booted, in which bootloader 0 is executed in a first execution stage (e.g. 0-th execution stage).

[00237] In step 304, bootloader 0 may increment the cohort count (e.g. Bootloader_O increments CohortCount (now equal to 0).

[00238] In step 306, bootloader 0 generates a fresh attestation integrity key (e.g. AttestationK_O_i_j = HKDF(MasterAttestation_i, (CohortCount, "Attestation")), where MasterAttestation_i may be a hardware stored secret that is inaccessible to all subsequent execution stages apart from the first execution stage executing bootloader 0. The attestation integrity key (e.g. AttestationK_O_L) may be considered to be the first stage key that may be used by bootloader 0 for generating attestation data associated with the next execution stage.

[00239] In step 308, bootloader 0 computes the hashes of the next execution stage (e.g. Bootloader 1 and/or application firmware) and generates its attestation MAC (e.g. MAC = HMAC(AttestationK_O_i_j, ("Attestation", NextStage_Chash))) [00240] In step 310, bootloader 0 computes a next stage key (e.g. 1-th execution stage key) for the next execution stage (e.g. 1-th execution stage such as boot loader and/or application firmware) and generates the next stage key (e.g. AttestationK_l_i_j = HKDF(AttestationK_O_i_j, "NextStage_1"). A different or one or more extra key(s) may be derived in a similar manner as the application demands. These may be used by the next execution stage for authentication and/or encryption/decryption operations on the device and/or with the service and/or as the application demands.

[00241] In step 312, bootloader 0 wipes the first stage key, i.e. attestation integrity key (e.g. AttestationK_O_i_j) from memory and puts the next stage key (e.g. AttestationK_l_i_j) in an agreed location in memory of the device for next execution stage (e.g. Bootloader_ts perusal, or application firmware perusal and the like).

[00242] In step 314, the bootloader 0 starts the next execution stage (e.g. 1-th execution stage) or n-th execution stage, where n=1 (e.g. Bootloader 1, or application firmware perusal and the like).

[00243] In step 316, n-th execution stage computes the digest (e.g. hashes) of the (n+1)-th execution stage (e.g. digest of Bootloader n+1 and/or application firmware n+1, which may be denoted NextStage_(n+1)_hash) and generates its attestation MAC (e.g. MAC_n_i_j = HMAC(AttestationK_n_i_j, ("Attestation", NextStage_(n+1)_hash))). The attestation MAC for the (n+1)-th execution stage may be stored in memory on the loT device until loT device establishes communications with the service, after which the attestation MACs of the (n+1)-th execution stage and/or the MACs of previous execution stages may be sent to the service as aggregated attestation data (e.g. [MAC_1_i_j,.. MAC_n_i_j]) and/or separately.

[00244] In step 318, n-th execution stage computes a (n+/)-th stage key for the (n+1)-th execution stage (e.g. (n+1)-th stage boot loader and/or application firmware and the like) and generates the (n+1)-th stage key (e.g. AttestafionK_(n+1)_i_j = HKDF(AttestationK_n_i_j, "NextStage_(n+1)"). A different or one or more extra key(s) may be derived in a similar manner as the application demands. These may be used by the (n+1)-th execution stage for authentication and/or encryption/decryption operations on the device and/or with the service and/or as the application demands.

[00245] In step 320 of process 300 in figure 3b, the n-th execution stage wipes the n-th stage key (e.g. AttestationK_n_i_j) from memory.

[00246] In step 321, the n-th execution stage puts/stores the (n+1)-th stage key (e.g. AttestationK_(n+1)_i_j) in an agreed location in memory of the device for (n+1)-th execution stage perusal (e.g. Bootloader_n+1's perusal, or application firmware n+1 perusal and the like).

[00247] In step 322, the n-th execution stage starts the (n+1)-th execution stage (e.g. Bootloader (n+1), or application firmware (n+1) and the like). The n-th execution stage then terminates as it is completed and the loT device may be constrained and not be able to execute execution stages in parallel. The parameter n is incremented to n+1. The process proceeds to step 324.

[00248] In step 324, the parameter n is compared to the number of execution stages M, and if n<M, then the process 300 proceeds to step 316. Otherwise, n=M and the process 300 proceeds to step 326.

[00249] In step 326, the M-th execution stage is executing and may use the M-th stage key and the M-th MAC and the like or as appropriate. The M-th execution stage is the last execution stage and so may terminate accordingly or as appropriate.

[00250] During the process 300, the n-th execution stage may send attestation data based on data representative of the digest of the n-th execution stage, attestation MAC of the n-th execution stage, and/or the epoch and cohort counters, to a service, which uses the attestation data in attesting whether the loT device is to be trusted or not. These further steps may be modified and/or supplemented based on the attestation systems and/or processes as described herein with reference to figures la-2d and/or as described herein.

[00251] The process 300 is configured to return aggregated attestation data such as a list of attestation values to the service once communications have been established by the n+/-th execution stage (e.g. attestation values [MAC_1_i_j,.. MAC_n+l_i_j]). Instead, the generation/calculation by the n-th execution stage of the (n+1)-th MAC (e.g. MAC_n+1_i_j) in the process 300 may be further modified to include the value of the preceding MAC (e.g. MAC_n_i_j) in the calculation of the n+1-th MAC. For example, step 316 may be modified such that the n-th execution stage computes the digest of the (n+1) execution stage and generates the n+1 attestation MAC (e.g. MAC_n+1_i_j) by incorporating the n-th attestation MAC (e.g. MAC_n_i_j) into the calculation (e.g. = HMAC(AttestationK_n+1_i ("Attestation", MAC_n_i_j, NextStage_(n+1)_hash))). By including the previous attestation MAC in the generation of the n+1 attestation MAC provides the advantage of cryptographically enforcing the sequencing of the generation of MACs such that they cannot be reordered. This may be used by the service for further trust management and/or verification of the attestation MACs received from loT device. Furthermore, rather than sending the n-th attestation MAC at every execution stage separately or as an aggregation of attestation data or attestation MACs, only the last generated MAC for the last execution stage needs to be returned to the service, which further minimises communication resource usage and/or bandwidth by the loT device. Additionally or alternatively, another security improvement to the attestation process 300 may be to explicitly state which for which execution stage of the attestation data is being computed for. This may be achieved by changing the static string "Attestation" used in the HMAC function in steps 308 and/or step 316 of process 300 to instead use the static string for the n-th stage "Attestation n", or some other identifier for the n-th stage.

[00252] Figures 3c and 3d are a flow diagram illustrating an example secret key refresh process 330 for refreshing a key, e.g. a secret, MasterAttestation_i key, and subsequently the first stage key, where normal provisioning mechanisms can be used, but one additional mechanism is possible: the bootloader 0 can have a public key pair and can use this key pair to perform an offline ECDH key exchange with a service. The shared secret that is derived from this process is then used to form the shared secret such as MasterAttestation_i used by the bootloader 0 to perform HKDF operations as described in steps 306 and/or 310 of process 300. The secret key refresh process 330 may include the following steps of: In step 332, the service hosted on at least one server increments the EpochCount (e.g. Server: EpochCount += 1); In step 333, the service creates a new service secret and derives from it a service key exchange value (SKX). For example, the service creates, by way of example only but it not limited to, a new service ECDH private key (e.g. new service secret) and key exchange value (e.g. SKX). In step 334, the service signs the new key exchange value (e.g. SKX value) as well as the new EpochCount and signs both using its service private key (e.g. an ECDSA private key). For example, the service signs the service key exchange value (SKX) and EpochCount using a previously stored long-term keypair (e.g. an ECDSA keypair) for the service (e.g. a long-term service private key and service public key), in which the device has the long-term service public key for the service. In another example, the service may sign a new service ECDH key exchange value (SKX) (e.g. derived from the new service secret) and EpochCount using its ECDSA private key (e.g. the long-term service private key), where the device has a corresponding ECDSA public key of the service (e.g. the long-term service public key). In step 335, the service sends the signed new service key exchange value (e.g. KX value) and EpochCount data to the device. For example, when signing using, by way of example only but not limited to, ECDSA, the service sends to the device the service signed ECDH KX value and EpochCount. It is noted, that the server(s) hosting the service also has stored thereon a long-term device ECDSA public key, which may have been exchanged previously. The device has stored thereon a device ECDSA private key corresponding to the device ECDSA public key.

[00253] In step 336, the device receives data representative of the signed new service key exchange value (e.g. signed new ECDH KX value) and any additional signed data such as, by way of example only but not limited to, the signed EpochCount. The signed new service key exchange value and EpochCount may be transmitted to the device once communications have been established by an n-th execution stage of the device (e.g. bootloader n, and/or application firmware n for n>=1), which may be untrusted code. For example, the device may, by way of example only but is not limited to, receive a signed new ECDH KX value (e.g. new service key exchange value or SKX) and EpochCount data from the service. The device stores the signed new service key exchange value (e.g. ECDH KX value) and EpochCount data in an agreed memory location and recognises that a secret key refresh is required and prepares to reboot the device.

[00254] In step 338, the device is rebooted and once rebooted the initial bootloader (e.g. bootloader 0) of the first execution stage (e.g. 0-th stage) of the device is invoked. The initial bootloader 0 is configured to check the agreed memory location and determine whether a signed new service key exchange value (e.g. SK)() and EpochCount has been received. In this case, it has received a signed new service la value (e.g. SKX) and EpochCount) from the service. In step 339, the bootloader or other module on device may be configured to check, using the service public key, that the signature of the signed new service ECDH KX value and EpochCount is valid. In step 340, the bootloader or other module on the device may be configured to check whether the EpochCount is, by way of example only but not limited to, "in the future", e.g. higher than the EpochCount stored by the device counter on the device. Alternatively, the device is configured to check whether the EpochCount matches an expected count pattern or count in relation to the EpochCount stored by the device counter on the device. For example, if the EpochCount is monotonically increasing, then the expected count pattern is that the received EpochCount is higher than the Epoch Count stored by the device counter on the device. For example, if the EpochCount monotonically decreasing, then the expected count pattern is that the received EpochCount is lower than the EpochCount stored by the device counter on the device.

[00255] In step 341, it is determined whether the signature is valid and/or the EpochCount is in the future the device, if this is the case (e.g. Y) then the process 330 continues on with the key refresh in step 342; otherwise (e.g. N), the process 330 may terminate or restart in step 332. For example, the device may notify the service of the error and the service may restart the key refresh process 330 again. In step 342, the boot loader (e.g. first stage of execution) may compute or generate a new device secret and derive from it client key exchange value (CKX). For example, the device creates, by way of example only but it not limited to, a new client ECDH secret and derives from it a device ECDH key exchange value (CKX). In step 343, the device computes a new master attestation key (MasterAttestation_i) based on the new device secret and the new service key exchange value (e.g. SKX). For example, a KDF may be used based on at least the new device secret and new service key exchange value. The KDF may also use any other data or key usage parameters and the like for generating the new master attestation key (MasterAttestation_i). The boot loader 0 may save the new master attestation key in memory (e.g. non-volatile memory) of the device that is inaccessible for use by any n-th execution stage, where n>=1. The new master attestation key is only made available to the 0-th execution stage of the device that executes bootloader 0 and is made inaccessible to all execution stages.

[00256] In step 344, the device updates the EpochCount of the device counter with the received EpochCount from the service. In step 345, the device signs the new device key exchange value (e.g. CKX value) as well as the updated EpochCount of the device counter using its device secret or private key (e.g. an ECDSA private key). For example, the device signs the device key exchange value (CKX) and updated EpochCount using a previously stored long-term keypair (e.g. an ECDSA keypair) for the device (e.g. a long-term device private key and device public key), in which the service has the long-term device public key for the device. In another example, the device may sign a new client ECDH key exchange value (CKX) (e.g. new device secret) and updated EpochCount using its ECDSA private key (e.g. the long-term device private key), where the service has a corresponding ECDSA public key of the device (e.g. the long-term device public key). The device stores the signed new device key exchange value and updated EpochCount data in an agreed memory location and recognises that the secret key refresh has been completed by the device and prepares to reboot the device.

[00257] In step 346, the device is rebooted and once rebooted the initial bootloader (e.g. bootloader 0) of the first execution stage (e.g. 0-th stage) of the device is invoked. The initial bootloader 0 performs the normal checks, generation of next stage keys and/or attestation data for the next stage based on the new master attestation key. Once completed, the initial bootloader 0 boots the next execution stage (e.g. 1-th execution stage), where the device is configured to make the new master attestation key inaccessible to subsequent execution stages. In step 347, the n-th execution stage of the device, where n>=1, may be configured to establish communications with a server hosting the service. This n-th execution stage is also configured to check the agreed memory location in which the signed new device secret and updated EpochCount are stored and determine whether a signed new device key exchange value (e.g. CKX) and updated EpochCount has been generated. In this case, a signed new device key exchange value (e.g. CKX) and updated EpochCount has been generated, so once the n-th execution stage has established communications with the server hosting the service, the n-th execution stage transmits the signed new device key exchange value and updated EpochCount to the server hosting the service.

[00258] In step 348, the service receives the signed new device key exchange value (e.g. CKX) and updated EpochCount of the device counter. In step 349, the service may be configured to check, using the device public key (e.g. long-term device public key) stored on the server hosting the service, that the signature of the signed new device key exchange value and updated EpochCount is valid. In step 350, the service may be configured to check whether the updated EpochCount matches the EpochCount of the service. This is because the device should have replaced its EpochCount with the EpochCount received from the service when it performs its steps of the secret key refresh process 300. In step 351, it is determined whether the signature is valid and/or the updated EpochCount matches the service EpochCount. If this is the case (e.g. Y) then the process 330 continues on with the secret key refresh on the service side in step 352: otherwise (e.g. N), the process 330 may terminate or restart in step 332. For example, the service may restart the key refresh process 330 again and/or the service may perform trust management as described herein in relation to the device (e.g. lower the level of trust of the device, resynchronise the counters of the device, request the device is replaced or reinstall the firmware and the like).

[00259] In step 352, the service computes a new master attestation key (MasterAttestation_i) based on the received new device key exchange value (e.g. CKX) and the new service secret generated in step 333. For example, a KDF may be used based on at least the received new device key exchange value and the new service secret. The KDF may also use any other data or key usage parameters and the like for generating the new master attestation key (MasterAttestafion_i) for the service. The KDF and/or its parameters are configured to be the same as those used by the device in step 343. The service may replace or update the current master attestation key with the new master attestation key and store in memory (e.g. non-volatile memory) of the server hosting the service. In step 353, the service uses the new master attestation key in process 300 for generating corresponding n-th stage keys and attestation codes/tags (e.g. MACs) for the n-th stage and the like. The service may invoke process 300 for receiving attestation data (e.g. MACs etc.) once the n-th execution stage, n>=1, of the device establishes communications with the server hosting the service. Process 300 may be used or invoked by service with the new master attestation key for generating next stage keys and attestation codes/MACs for each n-th execution stage and comparing the computed attestation codes/MACs with the received attestation codes/MACs from the n-th execution stage of the device. The processes 300 and/or 330 may be further modified and/or combined with the steps of the methods/processes and attestation systems/apparatus as described with reference to figures la-3c and/or as described herein.

[00260] The key generation process 300 and/or the key refresh process 330 may require two elements from the target device hardware, which include: a) a mechanism to prevent a key (e.g. the MasterAttestation_i) from being read after the initial boot loader or after the boot sequence of the first execution stage (e.g. 0-th execution stage) has finished, but before other n-th execution stages, for n>0, (e.g. application firmware) begin executing; and b) a mechanism to increment a monotonic device counter on each boot of the device, which is not manipulable by the any untrusted code in subsequent n-th execution stages, e.g. running application firmware and/or other bootloaders from memory that is accessible to all execution stages and the like.

[00261] The following elements of processes 300 and/or 330 may be implemented primarily using secure storage: Master key age counter (EpochCount); Boot counter since last Epoch change (CohortCount); ECDSA signature key; Attestation RoT (i.e. hash of server ECDSA signing key). However the secure storage does not need to be complex. Instead, it may be implemented using a sticky-bit system, where an area of flash memory is accessible after reboot, but once a bit is written to a lock register, the area of flash memory becomes inaccessibly until the next reboot. Other mechanisms for providing secure storage of the hardware stored secrets and/or other elements of processes 300 and/or 330 requiring secure storage are described with reference to figures la to 2c. This enables the initial bootloader (e.g. bootloader 0) and any remaining components of the first execution stage executing the initial bootloader secure access to a boot-time-only area of flash, ROM and/or memory for key storage and device counters and the like.

[00262] The present invention has significant advantages over the state of the art in that by using a symmetric algorithm, the start-up attestation is much less expensive than conventional approaches. The attestation, iterative key generation and/or key refresh processes as described herein, and/or with reference to figures 1a to 3b potentially allow for many low-cost boots between key rotation. By deploying offline ECDH key agreement, the key agreement between the loT device and the service hosted on at least one server is much simpler than with pure symmetric key arrangements. Each party can authenticate the other through the use of ECDSA signatures from one or more mutually trusted authorities.

[00263] Further modifications and/or additional features may be included into the invention as described herein with reference to figures 1a to 3b, such as, by way of example only but not limited to, the bootloader receiving encrypted data from the service using a key derived from its shared secret during the offline ECDH process. This allows the service to join epoch increment to encrypted information. For malware to operate undetected, it must allow an epoch increment to happen transparently. This allows the service to hide instructions to the bootloader inside the epoch increment protocol. This lets the service send certificate revocation information, and other information that malware might want to block transparently, in a way that makes it obvious if it is intercepted.

[00264] Figure 4 is a schematic diagram illustrating an example computing system 400 with a computing device 402 that may be used to implement one or more aspects of the device, loT device, service, attestation system, attestation process(es) and/or iterative generation process(es), cloud-based platform and the like according to the invention and/or based on the process(es), method(s), system(s), and/or apparatus, combinations thereof, modifications thereof, and/or as described with reference to figures la-3d and/or as described herein. Computing device 402 includes one or more processor unit(s) 404, memory unit 406 and communication interface 408 in which the one or more processor unit(s) 404 are connected to the memory unit 406 and the communication interface 408. In some embodiments, the computing device 402 may be a server, or one or more servers networked together. In some embodiments, the computing device 402 may be a mobile device, constrained device, device and/or loT device. The communications interface 408 may connect the computing device 402, via a communication network 410, with one or more services, devices, other processing system(s) or computing device(s) for implementing the invention as described herein. The memory unit 406 may store one or more program instructions, code or components such as, by way of example only but not limited to, an operating system and/or initial boot loader 406a for booting and/or operating computing device 402 and a data store 406b for storing additional data, applications, application firmware/software and/or further program instructions, code and/or components associated with implementing the functionality and/or one or more function(s) or functionality associated with one or more of the method(s) and/or process(es) of the device, service, apparatus, mechanisms and/or system(s)/platforms/architectures as described herein, combinations thereof, modifications thereof, and/or as described with reference to at least one of figure(s) la to 3d.

[00265] In the embodiments, examples, of the invention as described above may comprise a cloud platform, a server or computing system or device, where a server may comprise a single server or network of servers, the cloud platform may include a plurality of servers or network of servers. In some examples the functionality of the server and/or cloud platform may be provided by a network of servers distributed across a geographical area, such as a worldwide distributed network of servers, and a user may be connected to an appropriate one of the network of servers based upon a user location.

[00266] The above description discusses embodiments of the invention with reference to a single user for clarity. It will be understood that in practice the system may be shared by a plurality of users, and possibly by a very large number of users simultaneously.

[00267] The embodiments described above are fully automatic. In some examples a user or operator of the system may manually instruct some steps of the method to be carried out.

[00268] In the described embodiments of the invention the device, service, attestation system, attestation processes and/or iterative key generation processes according to the invention and/or as herein described may be implemented as any form of a computing and/or electronic device. Such a device may comprise one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to gather and record routing information. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[00269] Various functions described herein can be implemented in hardware, software, or any combination thereof If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media may include, for example, computer-readable storage media. Computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. A computer-readable storage media can be any available storage media that may be accessed by a computer. By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, flash memory or other memory devices, CD-ROM or other optical disc storage, magnetic disc storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu- ray disc (BD). Further, a propagated signal is not included within the scope of computer-readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.

[00270] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Application Program-specific Integrated Circuits (ASICs), Application Program-Specific Standard Products (ASSPs), System-on-a-chip systems (SOCs). Complex Programmable Logic Devices (CPLDs), etc. [00271] Although illustrated as a single system, it is to be understood that the computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device.

[00272] Although illustrated as a local device it will be appreciated that the computing device may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[00273] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

[00274] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[00275] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.

[00276] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method steps or elements identified, but that such steps or elements do not comprise an exclusive list and a method or apparatus may contain additional steps or elements.

[00277] As used herein, the terms "component" and "system" are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computer-executable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices.

[00278] Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something". Further, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

[00279] The figures illustrate exemplary methods. While the methods are shown and described as being a series of acts that are performed in a particular sequence, it is to be understood and appreciated that the methods are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a method described herein.

[00280] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and/or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and/or the like. Still further, results of acts of the methods can be stored in a computer-readable medium, displayed on a display device, and/or the like [00281] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[00282] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

Claims 1. A computer-implemented method of device attestation with a server hosting a service, the device including a first execution stage and at least a second execution stage, wherein each execution stage is associated with a corresponding set of computer code or instructions stored on the device and that is configured to execute on the device during execution of said execution stage, and wherein each execution stage sequentially executes on the device, the method comprising: enabling the first execution stage to have access to a first stage key on the device; generating attestation data for the second execution stage, during execution of the first execution stage, based on data representative of the first stage key, a device counter, and a digest associated with the second execution stage; storing the attestation data for the second execution stage for sending to the server, wherein the attestation data is used by the server as an indication of trust of at least the second execution stage of the device; and wherein the first stage key is accessible for use by the first execution stage during execution of the first execution stage on the device and inaccessible to the second execution stage thereafter.
2. The computer-implemented method as claimed in claim 1, wherein the device includes a first execution stage, a second execution stage and one or more subsequent execution stages, each execution stage sequentially executes on the device, wherein for each execution stage of the second and one or more subsequent execution stage(s), the method further comprising: generating, during execution of a next execution stage, attestation data for the next execution stage comprising data representative of a current stage key, a device counter, and a digest associated with the next execution stage, wherein the current stage key is generated during execution of the previous execution stage of the device based on the previous stage key; storing the attestation data in relation to the current execution stage for sending to the server, wherein the attestation data for the next execution stage is used by the server as an indication of trust of at least the next execution stage of the device; and wherein the first stage key is accessible for use by the first execution stage during execution of the first execution stage on the device and inaccessible to the second execution stage and subsequent execution stage(s) thereafter.
3. The computer-implemented method as claimed in any of claims 1 or 2, the method further comprising, during execution of the first execution stage: generating a digest of data representative of the second execution stage on the device generating an attestation code using a message authentication code, MAC, algorithm based on the generated digest, the device counter, and the first stage key; creating the attestation data associated with the second execution stage comprising data representative of the attestation code and the device counter; the method further comprising, during execution of the second or any subsequent execution stage apart from the last execution stage of the device: generating a digest of data representative of the next execution stage on the device; generating an attestation code using a message authentication code, MAC, algorithm based on the generated digest, the device counter, and the current stage key; creating the attestation data associated with the current execution stage comprising data representative of the attestation code and the device counter.
4. The computer-implemented method as claimed in claim 3, further comprising sending stored attestation data from the device to the server, wherein the server has access to a trusted copy of the first stage key and a service counter corresponding to and/or following the count of the device counter, the server configured to use a MAC algorithm to generate an attestation code based on the trusted copy of the first stage key, the service counter and/or a trusted copy of the digest of at least the second execution stage and comparing the generated attestation code with the received attestation code, wherein the server is configured to perform trust management in relation to the second execution stage and/or the device based on at least the comparison between attestation codes.
5. The computer-implemented method as claimed in any preceding claim, wherein the device counter comprises a first device counter and a second device counter, the first device counter for counting the number of times the server requests an update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device.
6. The computer-implemented method as claimed in claim 5, the method further comprising: receiving an internal trigger or signal for rebooting the device; rebooting the device; and adjusting the second device counter.
7. The computer-implemented method as claimed in any of claims 5 or 6, the method further comprising: receiving, from the server hosting a service associated with the device, a message for requesting performing a change on the device; adjusting the first device counter of the device to indicate a change occurring on the device; rebooting the device; adjusting the second device counter of the device after reboot; and performing the requested change on the device, wherein performing the change on the device comprises one or more from the group of: performing an update on the device; performing a secret key refresh on the device; performing a key update on the device; performing an increment of the first counter of the device; performing a challenge response protocol on the device; and any other operation or function for changing the device that the server hosting the service is authorised to request in relation to the device.
8. The computer-implemented method as claimed in any preceding claim, wherein either: the device counter is a monotonically increasing counter and adjusting the device counter comprises incrementing the device counter, wherein the server is configured to determine whether the device counter is monotonically increasing in relation to the service counter and performs trust management in relation to the next execution stage of the device or the device; or the device counter is a monotonically decreasing counter and adjusting the device counter comprises decremenfing the device counter, wherein the server is configured to determine whether the device counter is monotonically decreasing in relation to the service counter and performs trust management in relation to the second execution stage of the device.
9. The computer-implemented method as claimed in any preceding claim, wherein adjustments to the device counter are based on a known behaviour or pattern of increasing and/or decreasing the device counter, wherein adjusting the device counter comprises incrementing and/or decremenfing the device counter based on the known behaviour or pattern, wherein the server is configured to determine whether the device counter is being adjusted in accordance with the known behaviour or pattern in relation to corresponding adjustments to the service counter and performs trust management in relation to the second or subsequent execution stage(s) of the device.
10. The computer-implemented method as claimed in any preceding claim, wherein the server performs trust management based on the attestation data and/or device counter, wherein trust management is configured to perform at least one from the group of: indicating to the server that each execution stage of the device is trusted based on the comparison matching and/or frequency of matches of previous comparisons in relation to received attestation data associated with the execution stage(s); indicating to the server that a number of execution stages of the device is trusted based on comparison matching or frequency of matches in relation to received aggregated attestation data associated with said number of execution stage(s); indicate to the server a trust level associated with the next execution stage or the device is increased to a higher level of trust based on the comparison matching and/or frequency of matches of previous comparisons based at least on the data representative of the attestation data; indicate to the server a trust level associated with the next execution stage or the device has decreased to a lower level of trust based on a mismatch in the comparison and/or frequency of mismatches of previous comparisons based at least on the data representative of the attestation data; and any other rule or threshold indicating a level of trust associated with the next execution stage or the device based at least on the data representative of the attestation data.
11. The computer-implemented method as claimed in any preceding claim, wherein the device includes a number of M consecutive execution stages, where /<=m<=/14, the method further comprising: generating an (m+V-th stage key for the (m+1)-th execution stage, during execution of an M-th execution stage, based on an m-th stage key accessible to the M-th execution stage; storing the (m+1)-th stage key in accessible storage for use by the (m+1)-th execution stage.wherein, when m=1, the 1-th stage key corresponds to the first stage key and the 1-th execution stage corresponds to the first execution stage of the device, the first stage key being accessible to the first execution stage during execution and inaccessible to /<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other /<=m<=Msubsequent execution stages.
12. The computer-implemented method as claimed in claim 11, wherein generating the (m+/)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+1)-th stage key based at least on the m-th stage key.
13. The computer-implemented method as claimed in claims 11 or 12, wherein the first stage key is a stored secret and, when m=1, generating the (m+1)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+1)-th stage key based at least on the 1-th stage key and the device counter, wherein 1-th stage key is the first stage key, wherein the stored secret and first stage key is accessible to the first execution stage during execution and inaccessible to 1<m<=Msubsequent execution stages after execution of the first execution stage and prior to execution of any other1<m<=M subsequent execution stages.
14. The computer-implemented method as claimed in any of claims 11 or 12, further comprising: generating the first stage key based on a key derivation function with a stored secret and the device counter, wherein the first stage key and the stored secret is accessible to the first execution stage during execution and inaccessible to /<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other /<m<=M subsequent execution stages.
15. The computer-implemented method as claimed in any of claims 11 to 14, the method further comprising: generating attestation data for the (m+1)-th execution stage, during execution of the m-th execution stage, based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage; and storing the attestation data for the (m+/)-th execution stage for sending to the service for determining an indication of trust associated with at least the (m+1)-th execution stage of the device and/or the device.
16. The computer-implemented method as claimed in claim 15, the method further comprising: aggregating the attestation data for each (m+1)-th execution stage of the device; and sending the aggregated attestation data to the server once the device has established communications with the server during execution of an n-th execution stage of the device, where m<=n.
17. The computer-implemented method as claimed in any preceding claim, wherein the first execution stage is stored on a non-volatile memory, NVM, of the device, and the first stage key is derived from a hardware stored secret stored on the device and is initially inaccessible, the method comprising: initiating execution of only the first execution stage when the device is booted; enabling, prior to or during execution of the first execution stage, access to the first stage key; and disabling access to the first stage key for all execution stages prior to execution of any other execution stage on the device, wherein the first stage key is inaccessible to all execution stages thereafter.
18. The computer-implemented method as claimed in any preceding claim, wherein the first stage key is encrypted using the hardware stored secret and stored in accessible memory of the device, wherein: enabling access to the first stage key comprises decrypting the encrypted first stage key using the hardware stored secret; and disabling access to the first stage key comprises removing or clearing any data representative of the plaintext first stage key from the accessible memory.
19. The computer-implemented method as claimed in any preceding claim, wherein the device has stored thereon: a hardware stored secret; and the first stage key encrypted by the hardware stored secret; the hardware stored secret has been shared with the service hosted by one or more servers; the hardware stored secret is inaccessible to all execution stages; and the first stage key being inaccessible to all execution stages other than the first execution stage, wherein the first stage of execution is executed after a reboot of the device, the method further comprising: receiving, during execution of a subsequent execution stage on the device after establishing communications with a server hosting the service, a secret key refresh request from the server hosting the service, the secret key refresh request comprising a new first stage key encrypted by the hardware stored secret of the service and an indication of a first device counter adjustment; storing the secret key refresh request; initiating reboot of the device; in response to detecting a newly received secret key refresh request from the service, performing a secret key refresh on the device based on the steps of: adjusting the first device counter in line with the indication of the first device counter adjustment; replacing the encrypted first stage key with the encrypted new first stage key; decrypting the encrypted first stage key using the hardware stored secret for use by the first stage of execution; and disabling access to the first stage key prior to execution of any subsequent execution stage on the device.
20. The computer-implemented method as claimed in any preceding claim, wherein the device has stored thereon: a device private key and a first stage key, wherein the device is configured to remove access to the first stage key and device private key for all execution stages, when executed on the device, except the first execution stage, the method further 25 comprising: receiving a key update request from the server hosting the service for updating the first stage key of the device, wherein the key update request comprises data representative of a service public key exchange data; storing data representative of the key update request on the device; initiating reboot of the device; in response to detecting a newly stored key update request, performing an update of the first stage key based on the steps of: generating a new first stage key based on a device private key exchange data and the received service public key exchange data; replacing the first stage key with the newly generated first stage key; generating a key update response including data representative of a device public key exchange data derived from the device private key exchange data; and executing the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first execution stage is executed prior to all execution stages of the device; disabling access to the first stage key and device private key for all other execution stages during or after execution of the first execution stage; and when a subsequent execution stage establishes a communication connection with the server hosting the service, sending the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service.
21. A computer-implemented method of operating a server hosting a service, the service associated with a device operating according to the computer-implemented method as claimed in any of claims 1 to 20, wherein the service including access to storage comprising data representative of a copy of the first stage key associated with the device and a service counter for tracking the device counter of the device, the method comprising: receiving attestation data from the device associated with at least the second execution stage of the device, wherein the received attestation data is generated by the device based on data representative of the first stage key of the device, a device counter and a digest associated with the second execution stage; generating second attestation data for the second execution stage based on data representative of the copy of the first stage key, the service counter and a trusted copy of the digest associated with the second execution stage; performing trust management in relation to the second execution stage and/or the device based on the received attestation data and the generated second attestation data.
22. The computer-implemented method as claimed in claim 21, wherein the device includes a first execution stage, a second execution stage and one or more subsequent execution stage(s), the method further comprising: receiving attestation data from the device associated with one or more of the subsequent execution stage(s), wherein the attestation data for each execution stage of the subsequent execution stage(s) is based on data representative of a previous stage key of the immediately preceding execution stage to said each execution stage, a device counter, and a digest associated with said each execution stage, wherein the previous stage key is generated by the device during execution of the immediately preceding execution stage; generating, for each execution stage of the one or more subsequent execution stages, attestation data for said each execution stage based on a derived previous stage key, the received device counter or service counter and a trusted copy of the digest associated with said each execution stage; and performing trust management in relation to said each execution stage and/or the device based on the received attestation data for said each execution stage and the generated attestation data for said each execution stage; wherein the second stage key is derived from the copy of the first stage key.
23. The computer-implemented method as claimed in claims 21 or 22, the method further comprising: establishing communications with the device during execution of a current execution stage of the device, wherein the current execution stage is one of the second execution stage or any subsequent execution stage(s); receiving aggregated attestation data associated with multiple execution stages of the device including the current execution stage; and performing trust management in relation to each execution stage of the multiple execution stages based on the received attestation data for said each execution stage of the multiple execution stages and generated attestation data for said each execution stage of the multiple execution stages.
24. The computer-implemented method as claimed in any of claims 21 to 23, further comprising: monitoring the device counter based on the corresponding service counter associated with the device and the received device counter; and performing trust management in relation to received attestation data for each execution stage based on an expected behaviour of the device counter in relation to the service counter and/or the received attestation data.
25. The computer-implemented method as claimed in any of claims 21 to 24, wherein the received attestation data for each execution stage comprises data representative of an attestation code and the device counter associated with said each execution stage, wherein the received attestation code is generated by the device using a message authentication code, MAC, algorithm based on a generated digest associated with said each execution stage, the device counter, and a previous stage key of the immediately preceding execution stage to said each execution stage of the device, the method further comprising for said each execution stage: generating a second attestation code using a MAC algorithm based on a trusted copy of the digest associated with said each execution stage, the received device counter or the service counter, and a derived previous stage key of the immediately preceding execution stage to said each execution stage; comparing the second attestation code with the received attestation code; and performing trust management in relation to said each execution stage of the device based on the comparison of attestation codes.
26. The computer-implemented method as claimed in any preceding claim, wherein the device counter comprises a first device counter and a second device counter, the first device counter for counting the number of times the service requests an update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device, wherein the service counter comprises a first service counter and a second service counter, the first service counter for counting the number of times the service requests an update or shared secret refresh of the device and the second service counter for tracking the number of reboots of the device, the method further comprising: tracking the device counter of the device based on received attestation data for at least one execution stage of the device, the received attestation data for at least one execution stage including data representative of the current device counter of the device; comparing the first device count of the received current device counter with the first service count of the service counter; performing trust management in relation to the at least one execution stage of the device based on the comparison of the first device count and the first service count; comparing the second device count of the received current device counter with the second service count of the service counter; performing trust management in relation to the at least one execution stage of the device based on the comparison between the second device count and the second service count; and adjusting the service counter by replacing the second service count with the second device count when the second device count value is determined to be following an expected behaviour or trend in relation to the second service count.
27. The computer-implemented method as claimed in claim 26, wherein performing trust management further includes one or more from the group of: indicating to the service hosted by one or more servers that the second or any other subsequent execution stage of the device is trusted based on the comparison of the received device counter matching the service counter and/or frequency of matches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device is increased to a higher level of trust based on the comparison of the received device counter matching the service counter and/or frequency of matches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device has decreased to a lower level of trust based on a mismatch in the comparison of the received first device counter and the first service counter and/or frequency of mismatches of previous comparisons; indicating to the service a trust level associated with the second or any other subsequent execution stage of the device has decreased to a lower level of trust based on a mismatch in the comparison of the received second device counter and the second service counter, when the second service counter is greater than the received second device counter, and/or frequency of mismatches of previous comparisons; and any other rule or threshold indicating a level of trust associated with the second or any other subsequent execution stage or the device based on the received device counter and service counter.
28. The computer-implemented method as claimed in any of claims 21 to 27, wherein the device counter comprises a first device counter and a second device counter, the first device counter for counting the number of times the service requests an update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device, wherein the service counter comprises a first service counter and a second service counter, the first service counter for counting the number of times the service requests an update or shared secret refresh of the device and the second service counter for tracking the number of reboots of the device, the method further comprising: receiving, from the device, attestation data comprising data representative of a second device counter value; and replacing the second service counter value of the service counter with the received second device counter value when the received second device counter value is determined to be following an expected behaviour or trend in relation to the second service counter value.
29. The computer-implemented method as claimed in any of claims 21 to 28, wherein either: the device counter is a monotonically increasing counter and the method further comprising: determining whether the device counter is monotonically increasing in relation to the service counter; and performing trust management in relation to the at least one execution stage of the device or the device based on the determination of whether the device counter is monotonically increasing or the device counter is a monotonically decreasing counter and the device counter is decremented rather than incremented, the method further comprising: determining whether the device counter is monotonically decreasing in relation to the service counter; and performing trust management in relation to the at least one execution stage or the device based on the determination of whether the device counter is monotonically increasing.
30. The computer-implemented method as claimed in any of claims 21 to 29, wherein the device includes a number of M sequential execution stages, where /<=m<=M, the method further comprising: generating an (m+1)-th stage key for the (m+1)-th execution stage based on an m-th stage key generated for the m-th execution stage; storing the (m+1)-th stage key in accessible storage for use in cryptographic operations including encryption/decryption or attestation operations with the device in relation to the (m+1)-th execution stage.wherein, when m=/, the generated 1-th stage key corresponds to data representative of the copy of the first stage key and the 1-th execution stage corresponds to the first execution stage of the device.
31. The computer-implemented method as claimed in claim 30, wherein generating the (m+/)-th stage key in relation to the (m+V-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the m-th stage key.
32. The computer-implemented method as claimed in claims 30 or 31, wherein data representative of the copy of the first stage key is a stored secret shared with the device, when m=/, generating the (m+i)-th stage key for the (m+1)-th execution stage further comprises using a key derivation function to generate said (m+/)-th stage key based at least on the 1-th stage key and the service counter, wherein 1-th stage key is data representative of the copy of the first stage key.
33. The computer-implemented method as claimed in any of claims 30 to 32, the method further comprising: receiving, from the device, (m+1)-th attestation data for the (m+/)-th execution stage, the attestation data for the (m+/)-th execution stage based on data representative of the m-th stage key, a device counter, and a digest associated with the (m+1)-th execution stage; generating second (m+1)-th attestation data based on the generated m-th stage key, the received device counter or service counter and a trusted copy of the digest associated with the (m+1)-th execution stage; and performing trust management in relation to the (m+1)-th execution stage of the device based on the received (m+1)-th attestation data and the second (m+V-th attestation data.
34. The computer-implemented method as claimed in any of claims 21 to 33, wherein the server hosting the service has stored thereon: a hardware stored secret, wherein the hardware stored secret has been shared with the device; and a copy of the first stage key of the device; the method further comprising: generating a new first stage key; transmitting, during execution of a subsequent execution stage on the device after communications has been established between the device and the server hosting the service, a secret key refresh request to the device, the secret key refresh request comprising a new first stage key encrypted by the hardware stored secret of the service and an indication of a first device counter adjustment; and updating the copy of the first stage key with the new first stage key.
35. The computer-implemented method as claimed in any of claims 21 to 34, wherein the device has stored thereon: a hardware stored secret; a private key encrypted by the hardware stored secret; and a first stage key encrypted by the hardware stored secret, wherein the service has a public key and a corresponding private key, the device has a public key and a corresponding private key, the service has a copy of the public key of the device and the device has a copy of the public key of the service, the method further comprising: generating a new service private key exchange data, a new service public key exchange data based on the service private key exchange data, and a key update counter 25 value; transmitting a signed key update request to the device, the signed key update request comprising data representative of the new service public key exchange data and the key update counter value, wherein the signed key update request is signed by the private key of the service, wherein the device is configured to receive the key update request, validate the received signed key update request with the public key of the service, confirm the received key update counter value has been adjusted as expected in relation to the key update counter of the device, use the new service public key exchange data and a new device private key exchange data to generate a new first stage key, update a key update counter on the device with the received key update counter value; receiving a signed key update response from the device, the key update response comprising the new device public key exchange data derived from the new device private key exchange data, and a key counter update value of the key update counter of the device, the signed key update response signed by the private key of the device, wherein the device computed a new first stage key based on the new device private key exchange data and the new service public key exchange data; in response to validating the signed key update response with the public key of the device and determining that the received key update counter value matches the key update counter value of the service, performing the steps of: generating a new first stage key based on the received new device public key exchange data and the new service private key exchange data; and replacing the copy of the first stage key with the new first stage key.
36. An apparatus comprising a processor unit, a memory unit and a communication interface, the processor unit connected to the memory unit and communication interface, wherein the apparatus is adapted or configured to implement the computer-implemented method according to any of claims 1 to 20.
37. An apparatus associated with hosting a service comprising a processor unit, a memory unit and a communication interface, the processor connected to the memory and communication interface, wherein the apparatus is adapted or configured to implement the computer-implemented method according to any of claims 21 to 35.
38. A system comprising: one or more devices according to the apparatus as claimed in claim 36; one or more servers hosting a service according to the apparatus as claimed in claim 37; wherein the one or more devices are configured to perform one or more cryptographic operation(s) or activity(ies) and/or are configured to communicate with the service hosted by one or more servers and perform one or more cryptographic operation(s) or activity(s) therebetween.
39. A computer-readable medium comprising computer readable code or instructions stored thereon, which when executed on a processor, causes the processor to implement the computer-implemented method according to any of claims 1 to 20.ao. A computer-readable medium comprising computer readable code or instructions stored thereon, which when executed on a processor, causes the processor to implement the computer-implemented method according to any of claims 21 to 35.