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

Background

[0002] Cryptographic keys are used by devices for applications such as, without limitation, for example in authentication, digital signature, attestation, encryption and/or decryption of communication sessions between a device in communication with another device such as, by way of example only but not limited to, a server hosting a service, one or more servers, one or more remote devices, one or more client devices and/or any other device as the application demands. It is imperative that the set of cryptographic keys enabling these operations is kept secret and that only the device and the other device (e.g. a server) knows the necessary parts that enable these operations. This becomes increasingly difficult for remote devices, especially remote devices that may be constrained by their computing resources and/or, in particular, constrained by the trustworthiness of their computing environments. Constrained remote devices may not have the necessary resources for implementing trusted computing environments. This may yield vulnerabilities on the constrained remote device that could be exploited by an attacker to yield the cryptographic keys used by the constrained device in a communication session with another device (e.g. a server hosting a service) and the like.

[0003] 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 EL0-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, let alone, multiple trusted or sandboxed environments, or privilege separation features like an unconstrained device has. 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. However, typically later stages of execution may be configured to initiate a communication session with another device (e.g. a server hosting a service). Although the constrained device may have a set of cryptographic keys securely stored for use in various cryptographic operations such as, by way of example only but is not limited to, authentication, digital signature, attestation, encryption and/or decryption, the constrained device may have vulnerabilities in one or more latter stages of execution that may be exploited by an attacker to yield the set cryptographic keys used by the constrained device. Once at least one of the cryptographic keys in the set of cryptographic keys are known, the device data and/or communication session(s) of the constrained device are vulnerable to malicious attack such as, by way of example only but is not limited to, cloning, eavesdropping, spoofing, man-in-the middle attacks, further hacking attacks and the like.

[0007] There is a desire for a lightweight methodology or apparatus for efficiently and securely generating cryptographic keys (also known as keys) for use by constrained devices without sacrificing security and the like, but which enable the keys to be used for, by way of example only but not limited to, authentication, digital signatures, attestation, encryption and/or decryption and the like.

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

Summary

[0009] 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.

[0010] The present disclosure provides an iterative key generation mechanism for constrained devices configured to operate with, by way of example only but is not limited to, one or more servers hosting a service and/or any other device(s) and the like. The constrained device has multiple sequential or consecutive execution stages in which there is no separation of privilege. The first execution stage, which may include an initial bootloader, is trusted and is configured to perform, among other tasks, the generation of a set of one or more next stage keys in relation to the next execution stage based on at least one or more first stage key(s) and a nonce or changing value. As an option, the nonce or changing value may be, without limitation, for example a device counter of the constrained device. The first stage key(s) is configured to be only accessible to the first execution stage during execution and inaccessible thereafter. When the next execution stage executes, after the first execution stage has completed execution and disabled access to the first stage key(s), the next execution stage is configured to perform, among other tasks, the generation of a set of one or more subsequent execution stage key(s) in relation to the subsequent execution stage, if any, based on at least one of the next stage key(s) (also referred to as next execution stage key(s)). During execution, the next execution stage may use the next stage key(s) for one or more cryptographic operations such as, by way of example only but is not limited to, authentication, digital signature, attestation, encryption/decryption and the like or as the application demands. The iterative generation of further stage keys for each further execution stage proceeds in a similar manner.

[0011] In a first aspect, the present disclosure provides a computer-implemented method of iterative key generation for a device with at least a first execution stage and 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: generating, during execution of the first execution stage, a second stage key for use by the second execution stage based on a first stage key accessible by the first execution stage; and storing the generated second stage key in accessible storage on the device for access and use by the second execution stage; 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 thereafter.

[0012] Preferably, the first stage key is based on a stored secret, the stored secret accessible to the first execution stage during execution of the first execution stage on the device and inaccessible thereafter.

[0013] Preferably, generating the second stage key further comprises generating the second stage key for use by the second execution stage based on the first stage key and data representative of a nonce or changing value of the device.

[0014] Preferably, generating the second stage key for the second execution stage further comprises using a key derivation function to generate said second stage key based on the first stage key and the data representative of the nonce or changing value.

[0015] Preferably, generating the first stage key, during execution of the first execution stage, using a key derivation function, a stored secret, and data representative of a nonce or changing value of the device, wherein the stored secret is accessible during execution of the first execution stage and is inaccessible thereafter. [0016] Preferably, the data representative of the nonce or changing value is a device counter of the device.

[0017] Preferably, generating the second stage key for the second execution stage further comprises generating a set of second stage keys using a key derivation function to generate said set of second stage keys based on the first stage key, the data representative of the nonce, changing value or device counter, and/or a corresponding set of key usage parameters.

[0018] Preferably, generating the second stage key for the second execution stage further comprises generating a set of second stage keys using a key derivation function to generate said set of second stage keys based on the first stage key and a corresponding set of key usage parameters.

[0019] Preferably, during execution of the first execution stage, a single second stage key is generated and stored in accessible memory, and during execution of the second execution stage, a further set of second stage key(s) are generated by the second execution stage using a key derivation function with the single second stage key and one or more key usage parameters.

[0020] Preferably, enabling the first execution stage access to a stored secret on the device; generating the first stage key based on the stored secret and data representative of the nonce, changing value or device counter using a key derivation function; and disabling access to the stored secret, wherein the stored secret is inaccessible to all execution stages of the device.

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

[0022] Preferably, the second stage key is accessible, during execution of the second execution stage on the device, for use by the second execution stage and inaccessible thereafter.

[0023] Preferably, the stored secret is a hardware stored secret.

[0024] 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 hardware stored secret comprising triggering hardware associated with the hardware stored secret to provide the first execution stage with access via accessible storage to the hardware stored secret; and disabling any subsequent execution stage(s), prior to execution of said subsequent execution stage(s), access to the hardware stored secret by triggering removal of any data representative of the hardware stored secret from the accessible storage, wherein the hardware stored secret is inaccessible by all the subsequent execution stages.

[0025] Preferably, the method further comprising disabling the first execution stage access to the hardware stored secret by triggering removal of any data representative of the hardware stored secret from the accessible storage, wherein the hardware stored secret is inaccessible by all the execution stages.

[0026] Preferably, the method further comprising 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 execution on the device of any subsequent execution stage.

[0027] Preferably, the first execution stage comprises an initial bootloader stored on a non volatile memory, NVM, of the device, and a hardware stored secret is stored on the device and is initially inaccessible, the method comprising: executing only the first execution stage when the device is booted; enabling, during execution of the first execution stage, access to the hardware stored secret; generating a first stage key based on the hardware stored secret; and disabling access to the hardware stored secret and the first stage key for all execution stages prior to execution of any other execution stage on the device.

[0028] Preferably, the second stage key is stored in accessible storage on the device, and the method further comprising disabling access to the second stage key by triggering deletion of data representative of the second stage key stored in accessible storage after execution of the second execution stage, wherein the second stage key is inaccessible by all the execution stages thereafter.

[0029] Preferably, the first execution stage comprises an initial bootloader stored in a read only memory, ROM, of the device and the second execution stage comprises application firmware stored in the accessible memory of the device.

[0030] Preferably, the device includes a number of M sequential execution stages, where 1 <=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=1 , the 1 -th stage key corresponds to the first stage key and the 1 -th execution stage corresponds to the first execution stage, the first stage key being accessible to the first execution stage during execution and inaccessible to l<=m<=M execution stages after execution of the first execution stage and prior to execution of the any other 1 <m<=M execution stages.

[0031] Preferably, 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 m-th stage.

[0032] Preferably, 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 data representative of a nonce, changing value or 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<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other 1 <m<=M subsequent execution stages.

[0033] Preferably, generating the first stage key based on a key derivation function with a stored secret and data representative of a nonce, changing value or the device counter, wherein the first stage key and the stored secret is accessible to the first execution stage during execution and inaccessible to 1<m<=M subsequent execution stages after execution of the first execution stage and prior to execution of any other 1 <m<=M subsequent execution stages.

[0034] Preferably, 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 m-th stage key and data representative of a nonce, changing value or the device counter.

[0035] Preferably, 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.

[0036] Preferably, for the subsequent M-1 execution stages, where 1<=m<M, the method further comprising: generating a set of (m+1)-th stage keys 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; and storing the set of (m+1)-th stage keys in accessible storage for use by the (m+1)-th execution stage. [0037] Preferably, generating the second stage key for the second execution stage further comprises generating the set of (m+1 )-th stage keys for the (m+1 )-th execution stage further comprises generating the set of (m+1 )-th stage keys for the (m+1 )-th execution stage using a key derivation function to generate said set of (m+1 )-th stage keys based on at least the m-th stage key and a corresponding set of key usage parameters.

[0038] Preferably, the set of (m+1 )-th stage keys for the (m+1 )-th execution stage are used by the (m+1 )-th execution stage, during execution of the (m+1 )-th execution stage, for one or more cryptographic operation(s) or activity(ies) based on one or more from the group of: authentication, attestation, encryption, decryption, encryption authentication, transport layer security, and/or any other one or more cryptographic operations or tasks.

[0039] Preferably, 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 of the device, and a digest associated with the (m+1 )-th execution stage; and storing the attestation data for the (m+1 )-th execution stage for sending to a server, wherein the attestation data for the (m+1 )-th execution stage is used by the server for determining an indication of trust of the (m+1 )-th execution stage of the device.

[0040] Preferably, aggregating the stored attestation data for multiple execution stages; and sending the aggregated attestation data to the server, wherein the aggregated attestation data is used by the server for determining an indication of trust of the multiple execution stages.

[0041] Preferably, aggregating the attestation data associated with each m-th execution stage of the device; and sending the aggregated attestation data to the server once the device has established communications with the server in an n-th execution stage of the device, where m<=n.

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

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

[0044] Preferably, the first execution stage comprises an initial bootloader and each subsequent execution stage comprises a further bootloader and/or further application firmware. [0045] Preferably, generating each stage key for each execution stage further comprises using a key derivation function to generate said each stage key based on a previous stage key accessible during execution of a previous execution stage; and storing each generated stage key in accessible storage for access by said each execution stage during execution of said each execution stage.

[0046] Preferably, each of the generated stage keys may be used by the corresponding execution stage, during execution of the corresponding execution stage, for cryptographic operation(s) or activity(ies) based on one or more from the group of: authentication, attestation, authenticated encryption, Transport Layer Security operations, encryption and/or decryption operations.

[0047] Preferably, the cryptographic operations or activity(ies) are performed during a communication session between the device and another device, apparatus, or server hosting a service.

[0048] Preferably, generating, during execution of a current execution stage, attestation data for a next execution stage based on data representative of the current stage key that is accessible during execution of said current execution stage and inaccessible thereafter, the device counter, and a digest associated with said next execution stage; and storing the attestation data for the next or a subsequent execution stage for sending to a server associated with the device, wherein the attestation data for the next execution stage is used by the server for determining an indication of trust of the next execution stage of the device.

[0049] Preferably, generating the attestation data further comprises: 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 that is accessible during execution of said current execution stage and inaccessible thereafter; and storing the attestation data comprising data representative of the attestation code and the device counter.

[0050] Preferably, generating the attestation code further comprises generating the attestation code using the message authentication code, MAC, algorithm based on the generated digest, the device counter, attestation data associated with the current stage, and the current stage key that is accessible during execution of said current execution stage and inaccessible thereafter.

[0051] Preferably, the server hosting the service has access to data representative of a copy of the first stage key, a trusted copy of the digest, and a service counter corresponding to the count of the device counter of the device, the server configured to use a MAC algorithm to generate a second attestation code based on the data representative of the first stage key, the service counter and/or trusted copy of the digest and comparing the generated second authentication code with the received authentication code, wherein the server is configured to perform trust management in relation to the next execution stage and/or the device based on the comparison.

[0052] Preferably, creating the attestation data further comprises data representative of the attestation code, the counter, and the generated digest.

[0053] Preferably, the received generated digest is used for generation of the attestation code or used in the comparison.

[0054] Preferably, the trust management is configured to perform at least one from the group of: indicating to the server that the next execution stage of the device is trusted based on an expected behaviour of the device counter in relation to the service counter; 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); indicating to the server that the next 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 said next execution stage; indicating 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 in relation to received attestation data associated with said next execution stage; indicating the 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 if previous comparisons based at least on received attestation data associated with said next execution stage; and indicating a level of trust associated with the next execution stage or the device based on any other rule or threshold or process.

[0055] Preferably, a 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, a key update or shared secret refresh of the device and the second device counter for counting the number of reboots of the device.

[0056] Preferably, receiving an internal trigger or signal for rebooting the device; adjusting the second device counter; and rebooting the device. [0057] Preferably, receiving an internal trigger or signal for rebooting the device; rebooting the device; and adjusting, during reboot or execution of the first execution stage, the second device counter.

[0058] Preferably, receiving, from a server associated with the device, a message for requesting performing a change on the device; adjusting the first device counter to indicate a change occurring on the device; rebooting the device; and adjusting the second device counter of the device after reboot or during execution of the first execution stage. Preferably, performing the requested change on the device.

[0059] Preferably, performing a 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.

[0060] Preferably, receiving, from a server hosting a service associated with the device, a message for requesting an adjustment of the first counter of the device; adjusting the first device counter according to the requested adjustment; rebooting the device; and adjusting the second device counter of the device upon reboot of the device.

[0061] Preferably, receiving, from a server hosting the service associated with the device, a message for requesting adjustment of the first counter of the device; adjusting the first device counter and second counter of the device; and rebooting the device.

[0062] Preferably, receiving, from a server associated with the device, a message comprising a first count value; replacing the current count value of the first device counter with the received first count value; adjusting the second device counter; and rebooting the device.

[0063] Preferably, receiving, from a server associated with the device, a message comprising a first count value; 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.

[0064] 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 key in accessible storage; and disabling subsequent execution stages access to the first 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.

[0065] 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 data representative of the secret key refresh request on the device; 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; executing the first execution stage on the device, wherein the first stage key is accessible to the first execution stage; and disabling access to the first stage key prior to execution of any subsequent execution stage on the device.

[0066] 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 generated device public key exchange data based on the device private key exchange data; 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 stage is executed prior to all execution stages on 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 on the device; 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.

[0067] Preferably, the device has further 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, 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, 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 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 private key and first stage key based on the hardware stored secret; generating a new device private key exchange data; 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 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 generated 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.

[0068] Preferably, the device has further 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, 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, 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 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 private key and first stage key based on the hardware stored secret; generating a new device private key exchange data; 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 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 generated 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.

[0069] Preferably, adjusting, after initiating reboot of the device, the first device counter to indicate the key update of the first stage key. [0070] Preferably, the second counter is adjusted to indicate the reboot of the device.

[0071] Preferably, the device counter is a monotonically increasing counter and adjusting the device counter comprises incrementing the device counter.

[0072] Preferably, the device counter is a monotonically decreasing counter and adjusting the device counter comprises decrementing the device counter.

[0073] 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.

[0074] 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 a service counter and performs trust management in relation to the second or subsequent execution stage(s) of the device.

[0075] Preferably, sending stored attestation data associated with one or more stages of execution to the server for use in determining an indication of trust of the device when the device is configured for communicating with the server.

[0076] 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.

[0077] Preferably, storing each generated next stage key 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.

[0078] 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 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, wherein the device has at least a first execution stage and a second execution stage, wherein the first execution stage executes on the device prior to the second execution stage, the server configured for accessing data representative of a first stage key associated with the device and further configured for generating a server nonce or changing value that tracks the nonce or changing value of the device, the method comprising: generating a key associated with the second execution stage of the device based on the data representative of the first stage key and the server nonce or changing value; and storing the generated key for use with cryptographic operations or activities with the device.

[0079] Preferably, the cryptographic operations or activities comprise one or more cryptographic operations or activities from the group of: attestation, digital signature, digital verification, authentication, encryption and/or decryption, authenticated encryption operations with the device.

[0080] Preferably, using the generated key for use with cryptographic operations in relation to the second execution stage of the device.

[0081] Preferably, generating a server nonce or changing value that tracks a corresponding nonce or changing value of the device, the server nonce or changing value for use in generating the key associated with the second execution stage or the first stage key.

[0082] Preferably, the device nonce or changing value comprises data representative of a device counter of the device and the server nonce or changing value comprises data representative of a service counter associated with the service configured for tracking the device counter of the device.

[0083] Preferably, generating the key associated with the second execution stage further comprises using a key derivation function to generate said key based on the data representative of the first stage key and the server nonce, changing value or device counter.

[0084] Preferably, the cryptographic operations or activities are performed during a communication session between the device and the server during execution of the second or other subsequent execution stage on the device.

[0085] Preferably, receiving, from the device, attestation data associated with at least one execution stage of the device during execution of an execution stage other than the first execution stage, the attestation data comprising data representative of an attestation code associated with said at least one execution stage and the nonce, changing value or device counter of the device; generating, for said at least one execution stage, a second attestation code using a MAC algorithm based on a trusted copy of the digest associated with said at least one execution stage, the server nonce, changing value or counter in relation to the device, and the data representative of the first stage key; comparing the second attestation code with the received attestation code; and performing trust management in relation to the at least one execution stage and/or the device based on the comparison.

[0086] Preferably, the received attestation code associated with the at least one execution stage is generated by the device using a message authentication code, MAC, algorithm based on a generated digest of the at least one execution stage of the device, the nonce, changing value or device counter of the device, and the execution stage key immediately preceding the at least one execution stage of the device, wherein when the at least one execution stage is the second execution stage, then the execution stage key immediately preceding the second execution stage is the first stage key.

[0087] Preferably, performing trust management further comprises at least one from the group of: indicating to the server that the at least one execution stage of the device is trusted based on an expected behaviour of the device counter in relation to the service counter; 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); indicating to the server that the at least one 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 said at least one execution stage; indicating to the server a trust level associated with the at least one 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 in relation to received attestation data associated with said at least one execution stage; indicating to the server a trust level associated with the at least one execution stage of 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 in relation to received attestation data associated with said at least one execution stage; and indicating, based on any other rule, process or threshold, a level of trust associated with the at least one execution stage of the device.

[0088] Preferably, the server nonce, changing value or counter in relation to the device is a service counter, wherein 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 server requests an update, a key update, or shared secret refresh of the device, the server adjusting the first service counter before requesting the update, key update or shared secret refresh of the device, and wherein the second service counter is for counting the number of reboots of the device. [0089] Preferably, the device nonce, changing value or counter is a device counter, the method further comprising: tracking the device counter of the device based on received messages from the device, the received messages including data representative of the current device counter of the device, the current device counter including a first device counter and second device counter, wherein the first device counter corresponds to the number of times the service hosted by the server has requested a update, key update or shared secret refresh, and the second device counter corresponding to the number of times the device is rebooted; comparing the first device counter of the received current device counter with the first service counter of the service counter; performing trust management in relation to the next execution stage and/or the device based on the comparison of the first device counter and the first service counter; comparing the second device counter of the received current device counter with the second service counter of the service counter; performing trust management in relation to the next execution stage and/or the device based on the comparison between the second device counter and the second service counter; and adjusting the service counter by replacing the second service counter with the second device counter when the second device count value is determined to be following an expected behaviour, pattern or trend in relation to the second service counter.

[0090] Preferably, performing trust management further comprises one or more from the group of: indicating to the server that the next 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 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 of the received device counter matching the service counter and/or frequency of matches of previous comparisons; indicating 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 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 next execution stage or 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 indicating, based on any other rule or threshold, a level of trust associated with the next execution stage or the device based on the received device counter and service counter.

[0091] 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 first stage key, the method further comprising: generating a new first stage key; adjusting the first service counter in relation to a secret key refresh; transmitting, during execution of a subsequent execution stage on the device after communications have been established between the device and the server hosting the service, a secret key refresh request to the device, wherein the secret key refresh request includes data representative of the generated new first stage key encrypted by the hardware stored secret and an indication of a first service counter value for adjusting the first device counter; and updating the data representative of the copy of the first stage key with the new first stage key.

[0092] Preferably, receiving, from the device, a message comprising data representative of a second device counter value; and adjusting the second service counter value of the second service counter based on 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.

[0093] Preferably, the copy of the first stage key is retrieved from a key manifest or list from the manufacturer of the device.

[0094] Preferably, a private or public key of the device is retrieved from a key manifest or list from the manufacturer of the device.

[0095] Preferably, the device includes a number of M sequential execution stages, where 1<m<M, the method further comprising: generating, by the server hosting the service, 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 for use in cryptographic operations including attestation, authentication, encryption and/or decryption operations with the device in relation to the (m+1 )-th execution stage, wherein, when m=1 , the 1 -th stage key corresponds to data representative of the copy of the first stage key stored by the server hosting the service and the 1 -th execution stage corresponds to the first execution stage of the device.

[0096] Preferably, 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+1 )-th stage key based at least on the m-th stage key.

[0097] Preferably, data representative of the copy of the first stage key is a stored secret shared with the device, 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 server nonce, server changing value or service counter, wherein 1 -th stage key is data representative of the copy of the first stage key.

[0098] Preferably, generating data representative of the copy of the first stage key based on a key derivation function with a stored secret and the server nonce, server changing value or service counter, wherein the stored secret is shared between device and server.

[0099] Preferably, 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 m-th stage key and the server nonce, server changing value or service counter.

[00100] Preferably, the device includes a number of M sequential execution stages, where 1 <=m<M, the method further comprising: generating, when m=1 , 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 and the server nonce, changing value or service counter, wherein the m-th stage key corresponds to the first stage key, and the 1 -th execution stage corresponds to the first execution stage when m=1 , wherein the first stage key is a stored secret of the device or is derived from the stored secret of the device, the stored secret being accessible to the first execution stage during execution and inaccessible to l<=m<=M execution stages after execution of the first execution stage and prior to execution of the any other 1 <m<=M execution stages; and for the subsequent 2<=m<M execution stages, 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; and storing the (m+1)-th stage key in accessible storage for use by the (m+1)-th execution stage.

[00101] Preferably, 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 m-th stage key.

[00102] Preferably, the server/service nonce, changing value or service counter is a service counter, the method further comprising: receiving, from the device, attestation data associated with 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 stage attestation data based on the generated m-th stage key, the service counter and a trusted copy of the digest or firmware associated with the (m+1)-th execution stage of the device; 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+1)-th attestation data. [00103] 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 method further comprising: generating a new first stage key by the server hosting the service; and transmitting, during a communications session between the device and a server hosting the service, a secret key refresh request comprising the new first stage key encrypted by the hardware stored secret of the service and an indication of a first service counter adjustment for use by the device in adjusting the first device counter.

[00104] Preferably, the server of the service has stored thereon a service private key and device has stored thereon a service public key corresponding to the service private key, the method further comprising: transmitting a key update request to the device for updating the first stage key of the device, wherein the key update request comprises data representative of service public key exchange data, wherein the device is configured to: store data representative of the key update request on the device; initiate reboot of the device; detect a newly stored key update request in response to rebooting, wherein the device is configured to perform an update of the first stage key to: generate a new first stage key based on a device private key exchange data and the received service public key exchange data; replace the first stage key with the newly generated first stage key; generate a key update response including data representative of a generated device public key exchange data based on the device private key exchange data; execute the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first stage is executed prior to all execution stages on the device; disable access to the first stage key and device private key for all other execution stages during or after execution of the first execution stage on the device; and when a subsequent execution stage establishes a communication connection with the server hosting the service, send the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service; receiving the generated key update response from the device; generate a new first stage key based on the service private key exchange data and the received device public key exchange data; and replace the copy of the first stage key of the server with the new first stage key.

[00105] Preferably, the server of the service has stored thereon a service private key and device has stored thereon a service public key corresponding to the service private key, the method further comprising: transmitting a key update request to the device for updating the first stage key of the device, wherein the key update request comprises data representative of service public key exchange data, wherein the device is configured to: store data representative of the key update request on the device; initiate reboot of the device; detect a newly stored key update request in response to rebooting, wherein the device is configured to perform an update of the first stage key to: generate a new first stage key based on a device private key exchange data and the received service public key exchange data; replace the first stage key with the newly generated first stage key; generate a key update response including data representative of a generated device public key exchange data based on the device private key exchange data; initiate reboot of the device; execute the first execution stage on the device, wherein the first stage key is accessible to the first execution stage and the first stage is executed prior to all execution stages on the device; disable access to the first stage key and device private key for all other execution stages during or after execution of the first execution stage on the device; and when a subsequent execution stage establishes a communication connection with the server hosting the service, send the generated key update response to the server for updating the copy of the first stage key stored on the server hosting the service; receiving the generated key update response from the device; generate a new first stage key based on the service private key exchange data and the received device public key exchange data; and replace the copy of the first stage key of the server with the new first stage key.

[00106] In a third aspect, the present disclosure provides an apparatus comprising a processor, a memory 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 first aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[00107] In a fourth aspect, the present disclosure provides an apparatus associated with hosting a service, the apparatus comprising a processor, a memory 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.

[00108] In a fifth aspect, the present disclosure provides a system comprising: one or more devices according to the third aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein; one or more servers hosting a service according to the fourth aspect, one or more features thereof, combinations thereof, 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. [00109] In a sixth aspect, there is provided a system comprising: one or more devices configured 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 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 corresponding server hosting the service.

[00110] In a seventh aspect, the present disclosure provides a computer-implemented method of iterative key generation for a device with at least a first execution stage and 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: generating, during execution of the first execution stage, a second stage key for use by the second execution stage based on a first stage key accessible by the first execution stage and a device counter; and storing the generated second stage key in accessible storage on the device for access and use by the second execution stage; 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 thereafter.

[00111] 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 first aspect, one or more features thereof, combinations thereof, modifications thereto and/or as described herein.

[00112] In a ninth 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.

[00113] 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.

[00114] 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.

[00115] 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

[00116] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[00117] Figure 1a is a schematic diagram illustrating iterative generation of keys on a constrained device with multiple execution stages according to the invention;

[00118] Figure 1b is a schematic diagram illustrating iterative generation of keys for use in attestation of a constrained device with multiple execution stages according to the invention;

[00119] Figure 1c is a flow diagram illustrating an example iterative key generation process for a constrained device according to the invention;

[00120] Figure 1d is a flow diagram illustrating another example iterative key generation process for use with a constrained device with M executable stages;

[00121] Figure 1e is a flow diagram illustrating a further example iterative key generation process for use with a constrained device with M executable stages;

[00122] Figure 2a is a schematic diagram illustrating an example iterative generation system according to the invention;

[00123] Figure 2b is a flow diagram illustrating an example device iterative key generation process according to the invention; [00124] Figure 2c is a flow diagram illustrating an example service process corresponding to the device iterative key generation process of figure 2b according to the invention;

[00125] Fig. 2d is another schematic diagram illustrating another example iterative key generation system according to the invention;

[00126] Fig. 2e is another schematic diagram illustrating another example iterative key generation configured for performing a first stage key update according to the invention;

[00127] Figures 3a and 3b are a flow diagram illustrating an example iterative key generation process for an loT device and corresponding service according to the invention;

[00128] Figures 3c and 3d are a flow diagram illustrating a key update process for updating one or more keys according to the invention; and

[00129] Figure 4 is a schematic diagram illustrating an example computing system for a device and/or service according to the invention.

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

Detailed Description

[00131] 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. Flowever, the same or equivalent functions and sequences may be accomplished by different examples.

[00132] The inventors propose an iterative key generation mechanism for a constrained devices configured to operate with, by way of example only but is not limited to, one or more servers hosting a service and/or any other device(s) and the like. The constrained device has multiple sequential or consecutive execution stages in which there is no separation of privilege. The first execution stage, which may include an initial bootloader, is trusted and is configured to perform, among other tasks, the generation of a set of one or more next stage keys in relation to the next execution stage based on at least one or more first stage key(s) (e.g. derived from a hardware stored secret and/or key usage parameter and the like) and a nonce or changing value. As an option, the nonce or changing value may be, without limitation, for example a device counter. The first stage key(s) is configured to be only accessible to the first execution stage during execution and inaccessible thereafter. When the next execution stage executes, after the first execution stage has completed execution and disabled access to the first stage key(s) (also referred to as first execution stage key(s)), the next execution stage is configured to perform, among other tasks, the generation of a set of one or more subsequent execution stage key(s) in relation to the subsequent execution stage, if any, based on at least one of the next stage key(s) (also referred to as next execution stage key(s)). During execution, the next execution stage may use the next stage key(s) for one or more cryptographic operations such as, by way of example only but is not limited to, authentication, digital signature, attestation, encryption/decryption and the like or as the application demands.

[00133] The nonce, changing value or device counter is used by the first execution stage to ensure that each subsequent execution stage gets a unique execution stage key when those stages start to execute. Once the nonce, changing value or device counter has been mixed into the key material one time, by the first execution stage, this is adequate to ensure each subsequent execution stage gets a unique key generated by the immediately preceding execution stage each time said each subsequent stage executes. As an option, the nonce, changing value, or the device counter and/or other key generation data may be applied when generating each execution stage key during execution of a preceding execution stage using one or more of the preceding execution stage key(s).

[00134] When the subsequent stage executes, after the next execution stage has completed execution and disabled access to the next stage key(s), the subsequent execution stage is configured to generate, if required, further execution stage keys in relation to a further execution stage. The subsequent execution stage, during execution, may use the subsequent stage key(s) for one or more cryptographic operations such as, by way of example only but is not limited to, authentication, digital signature, attestation, encryption/decryption and the like or as the application demands. The iterative key generation process continues until the final execution stage of the device. The iterative key generation process results in an efficient and secure process for generating and distributing cryptographic keys to each execution stage of the constrained device.

[00135] The generation of each set of execution stage key(s) for each execution stage by the immediately preceding execution stage may be based on, by way of example only but is not limited to, using a key derivation function with the immediately preceding next stage key(s) and/or key usage parameter(s) and the like as input to the key derivation function. The first execution stage generates one or more second execution stage key(s) (or next execution stage key(s)) using a key derivation function with a hardware stored secret and a nonce, changing value, or device counter as input. Based on the teachings herein a skilled person will appreciate that embodiments of the invention be used in applications, without limitation, in for example authentication, attestation, digital signature, encryption/decryption, and/or any other cryptographic operation or process in which each set of execution stage key(s) and the like may be used as the application demands.

[00136] The constrained device may use a set of execution stage keys generated for an execution stage of the device for cryptographic operations and/or communication session with a trusted device such as, by way of example only but not limited to, a server hosting a service or trusted computing device. The trusted device may have a copy of the hardware stored secret or first execution stage key(s) of the constrained device. This highly sensitive information may have been previously and securely shared with the trusted device, e.g. via a manufacturer manifest or via a key exchange algorithm or process and the like. Thus, the constrained device may be configured to send the device counter used by the first execution stage to generate the next execution stage key(s) or an encrypted version of the device counter (e.g. encrypted using the hardware stored secret or first execution stage key) to the trusted device enabling the trusted device to use the copy of the hardware stored secret securely stored thereon and/or first execution stage key(s) to iteratively generate each subsequent set of execution stage key(s) for each subsequent execution stage. For example, the trusted device may be configured to generate each set of execution stage key(s) for each execution stage when executing the immediately preceding execution stage based on, by way of example only but is not limited to, using the key derivation function used by the constrained device with at least the immediately preceding next execution stage key(s) as input, but also including, without limitation, for example the received device counter or a trusted device counter (e.g. a server/service counter) tracking the constrained device counter, and/or key usage parameter(s) and the like as input. This enables the constrained device and trusted device to perform tasks, cryptographic operations and/or communication sessions with each other using the same set of execution stage key(s) when required during operation of one or more execution stages of the constrained device.

[00137] The invention provides an iterative key generation methodology/process for a constrained device based on using, by way of example only but is not limited to, a hash- based key derivation function (HKDF) on keys or passwords in which a secret (e.g. a key) plus a device counter (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 keys may be based on a 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.

[00138] With a device with multiple stages of execution, the initial execution stage has access to an initial secret (or 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 all execution stages prior to or once the first execution stage has completed execution, but before the next execution stage begins execution. 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 a subsequent derived key (e.g. a subsequent stage key) for a subsequent execution stage after the next execution stage whilst making its derived key (e.g. the next stage key) inaccessible to all subsequent execution stages. This process may be iterated for subsequent execution stages.

[00139] 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. This allows each execution stage to get a unique execution stage key or unique set of execution stage key(s) at runtime of 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.

[00140] Although a single execution stage key may be described as being generated for each execution stage, this is for simplicity and by way of example only but the invention is not so limited, it is to be appreciated by the skilled person that the iterative key generation mechanism for each execution stage may have a set of stage key(s) (e.g. a set of one or more key(s)) generated for it by the immediately preceding execution stage, where, without limitation, for example a key usage parameter may be used for generating each different stage key in the set of stage key(s). This allows a different stage key from the set of stage key(s) to be used for a plurality or a multitude of cryptography operations such as, by way of example only but not limited to, authentication, attestation, digital signatures, encryption and/or decryption operations and the like. This also can avoid reuse of the next stage key for other cryptographic operations. As an option, should only a single execution stage key (or a "root" stage key) be generated for each execution stage, when said each execution stage executes, this execution stage may use a KDF with its execution stage key (e.g. "root" stage key) and/or a set of key usage parameters to generate a set of stage keys for cryptography operations such as, without limitation, for example, authentication, attestation, digital signatures, encryption, and/or decryption operations and the like. Essentially, a set of additional current stage keys may be derived from the current stage key for using in the cryptographic operations/activities of the current execution stage whilst the current stage key is generated/derived with the execution stage key of the immediately preceding execution stage.

[00141] Although the constrained device has different stages of execution of decreasing trust, the iterative key generation mechanism enables each execution stage to have access to a unique secret and use that secret for generating a new secret for a subsequent execution stage. This enhances security and integrity of data and/or communication sessions of the constrained device with another device, without limitation, for example a server hosting a service.

[00142] It is noted that the first execution stage is assumed to be a trusted execution stage, which is typically stored in non-volatile memory (NVM) such as, by way of example only but is not limited to, ROM and the like. 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 is configured to adjust (e.g. increments/decrements) the device counter and thus generate a new set of next stage key(s). Thus, each time the device is rebooted, a new set of next stage key(s) are iteratively generated for each execution stage for securing the device and/or communication sessions of the device. 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. derived from a hardware stored secret) 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. Thus, the key generation process can generate a new next stage key based on a new set of variables such as, by way of example only but not limited to, a new device counter (or nonce or changing value) and/or key usage parameters and the like.

[00143] For example, the hardware stored secret may be a number which is securely stored in the constrained device, e.g. burnt in device on manufacture, and configured to be accessible only to the first execution stage. 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 a trusted device, a service or server hosting the service and/or another device in communication with the constrained device). Data representative of the second and/or one or more subsequent execution stage(s) is stored on the accessible read/writeable device memory. The second stage key(s) are generated using the device counter and hardware stored secret or a first execution stage key by the first execution stage and are stored by the first execution stage in the accessible memory of the device for use by the second execution stage when it executes. The second execution stage retrieves the second stage key(s) and uses this to compute a next stage key for the immediate next execution stage. The second execution stage key(s) may also be used, by the second execution stage, for any task or cryptographic operation/activity requiring a second stage key such as, by way of example only but not limited to, authentication, attestation, encryption/decryption operations based on the second stage keys and/or keys derived therefrom. The next stage key(s) (or set of next stage key(s)) are stored in accessible memory and used by the next execution stage, during execution, for any task or cryptographic operation requiring a next stage key such as, by way of example only but not limited to, authentication, attestation, encryption/decryption operations based on the next stage keys when the device communicates with another device such as, by way of example only but not limited to, a server or service and/or with other devices.

[00144] The 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.

[00145] 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.

[00146] Figure 1 a is a schematic diagram illustrating an example of iterative key generation system 100 according to the invention. The 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, by way of example only but is not limited to, a cloud platform 103. The device 102 includes a processing unit (not shown), a memory 108, and a communication interface (not shown), where the processing unit connects with the memory 108 and communication interface. The communication interface may be used for communicating 119 with the service 104 hosted by the one or more servers or cloud platform 103. The device 102 is configured to have multiple execution stages 106a-106m that sequentially execute on the device 102 some of which may communicate with service 104 hosted by one or more servers. In the iterative key generation system 100, the device 102 is configured to iteratively generate execution stage keys 110a-110m, each of which are used in a corresponding execution stage 106a-106m. The device 102 is configured to iteratively generate execution stage keys 110b-110m in relation to one or more subsequent execution stages 106b-106m after the first execution stage 106a. Further modifications and/or features of the device 102 are described herein in more detail with reference to figures 1b to 1e and the devices 202 and the like with reference to figures 2a to 4.

[00147] For example, during execution of a current stage of execution 106b, a set of execution stage key(s) 110c for the next execution stage 106c are generated. Each of the set(s) of execution stage keys 110a-110m may be used by the corresponding execution stage 106a-106m as, by way of example only but is not limited to, cryptographic keys for attestation, authentication, encryption/decryption and/or cryptographic communications, cryptographic signatures, or secure data storage, and/or for use in an attestation protocol with service 104 hosted by one or more servers. Further details, modifications and/or features for iteratively generating the next stage keys that may be used by device 102 and/or service 104 hosted by one or more servers are described with reference to figures 2a-2e, 3a-3d and/or 4 and/or as herein described.

[00148] As described, each execution stage consecutively or sequentially executes on the device 102 after the previous execution stage is completed execution. In this example, there are M execution stages 106a-106m, which are configured to sequentially execute one after the other. For example, the first execution stage 106a (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 102 executes the first execution stage 106a (e.g. the initial bootloader stored in ROM or NVM) when it reboots or starts up. The second execution stage 106b (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 102 is configured to execute the code associated with the second stage of execution 106b once the first stage of execution 106a has completed or terminated its execution and booted the second stage of execution 106b. Once the second stage of execution 106b completes or terminates executing, the device 102 is configured to execute the code associated with the third stage of execution 106c (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 1061-106m 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 106b-106m is configured to sequentially execute after the immediately preceding execution stage 106a-106I has completed execution or has terminated execution of its corresponding code on the device 102. The device 102 is further configured to not require different levels of privileges and does not provide runtime separation of privileges. [00149] Initially, when the device 102 is booted, the device 102 is configured to execute the first stage of execution 106a. The first stage of execution 106a may use a first set of one or more execution stage keys (e.g. Key(s) 110a), which may be derived from a hardware stored secret 110. In this example, a first execution stage key or first stage key 110a is originally derived from the hardware stored secret 110. The hardware stored secret 110 is accessible via hardware/registers and/or memory 108 of the device 102 during execution of a first execution stage 106a of device 102. The device 102 is configured to control access to the hardware stored secret 110, which is controlled to be accessible during execution of the first stage of execution 106a and controlled to be inaccessible to all subsequent stages of execution 106b-106m prior to execution of these stages of execution 106b-106m. The memory 108 may be non-volatile memory that is read/writeable and accessible by all execution stages 106a-106m. In this example, the device 102 has M execution stages 106a- 106m (i.e. a first stage of execution 106a and M-1 subsequent stages of execution 106b- 106m), where 1 <m<M, where each of the execution stages 106a-106m is associated with a corresponding set of computer code or instructions stored on the accessible memory 108 and/or ROM/NVM (not shown) of the device 102 and that is configured to execute on the device 102 during execution of said each execution stage. The execution stages 106a-106m consecutively or sequentially execute on the device 102.

[00150] In this example, the device 102 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 106a-106m. For example, the first execution stage 106a (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 102, which may be considered to be trusted code; the second execution stage 106b (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 108; the third execution stage 106c (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 106m may include either further bootloaders and/or application firmware and the like.

Although the first to third execution stages 106a-106c are shown to include various bootloader(s), this is by way of example only and the device 102 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 106a- 106m as the application demands.

[00151] Initially, the first execution stage 106a (e.g. Stage 1 ) is enabled to have access to a first stage key 110a on the device 102. The first stage key 110a (e.g. Key(s) 1 ) may be derived from a hardware stored secret or key 110 or be based on the hardware stored secret or key 110. The device 102 is configured to generate the first stage key 110a from the hardware stored secret 110 and also configured to allow the hardware stored secret 110 and the first stage key 110a to be accessible only to the first execution stage 106a during execution of the first execution stage 106a and inaccessible thereafter to all subsequent execution stages 106b-106m. During execution of the first execution stage 106a, a second stage key 110b (e.g. Key(s) 2) is generated for use by the second execution stage 106b (e.g. Stage 2) based on the first stage key 110a, which is only accessible by the first execution stage 106a, and, by way of example only but not limited to, a device counter 114 (or nonce or changing value) and/or key usage parameter (not shown). The second stage key 110b may be generated in a same and/or a similar fashion as described in further detail with reference to figures 1 b to 1 e and/or the first stage key(s) 272 and/or second stage key(s) 274 and the like as described with reference to figures 2a-2e, 3a-3d and/or 4 and/or as herein described. The generated second stage key 110b is stored in accessible memory storage 108 on the device 102 for access and use by the second execution stage 106b. The first stage key 110a is accessible for use by the first execution stage 106a during execution of the first execution stage 106a on the device 102 and is inaccessible thereafter to all subsequent execution stages 106b-106m.

[00152] The access to the first stage key 110a is disabled for all execution stages 106b-106m during or after execution of the first execution stage 106a on the device 102, but prior to execution on the device 102 of any subsequent execution stages 106b-106m. This may be achieved by, by way of example only but is not limited to, overwriting the first stage key 110a in the accessible memory 108 with zeros or a new key and the like, and/or encrypting the first stage key 110a and removing any plaintext data representative of the first stage key 110a, and/or any other mechanism or method as the application demands. For example, the first stage key 110a may be made inaccessible based on the same or similar manner, fashion or approach as described in further details in relation to the device 202 as described with respect to figures 2a to 2e and/or as described herein with reference to figures 3a-3d and/or 4 and/or as described herein. The second execution stage 106b (e.g. Stage 2) has access to the second stage key 110b stored in memory 108. [00153] This process of key generation of the next execution stage key 110c (e.g. Key(s) 3) for the next subsequent execution stage 106c is repeated during execution of the second execution stage 106b. For example, during execution of the second execution stage 106b, a third stage key 110c (e.g. Key(s) 3) is generated for use by the third execution stage 106c (e.g. Stage 3) based on the second stage key 110b that is accessible by the second execution stage 106b (e.g. Stage 2) and may further include, by way of example only but not limited to, a key usage parameter (not shown) and the like. Optionally, the generation of the third stage key 110c by the second execution stage 106b may be based on the second stage key 110b and device counter 114 and/or key usage parameters and the like. The third stage key 110c may be generated in the same or a similar fashion as described in relation to the first stage key(s) 272 and/or second stage key(s) 274 with respect to figures 2a to 2e and/or as herein described with reference to figures 3a-3d and/or 4. The generated third stage key 110c (e.g. Key(s) 3) is stored in accessible memory storage 108 on the device 102 for access and use by the third execution stage 106c (e.g. Stage 3). The second stage key 110b is accessible for use by the second execution stage 106b (e.g. Stage 2) during execution of the second execution stage 106b on the device 102 and inaccessible thereafter to all subsequent execution stages 106c-106m (e.g. Stages 3 to M).

[00154] This iterative key generation process is repeated for subsequent stages after the third execution stage 106c through until the M-th execution stage 106m, where the M-th execution stage 106m does not perform key generation but rather executes the M-th execution stage 106m and, if necessary, uses the (M)-th stage key 110m (e.g. Key(s) M) generated by the previous (M-1 )-th execution stage 1061 for cryptographic operations/activities with, by way of example only but not limited to, the service 104 and the like. Preferably, the device counter 114 is used by the first execution stage 106a during derivation/generation of the second stage key 110b and is not required to be used during derivation/generation of any of the subsequent keys by the subsequent execution stages 106b-106m. However, as an option, the device counter 114 may be used by each of the execution stages 106a-106I for deriving/generating the corresponding execution stage key 110b-110m corresponding to the next execution stage 106b-106m.

[00155] Figure 1 b is a schematic diagram illustrating the example iterative key generation system 100 of figure 1 a being applied to the cryptographic operation of attestation of the constrained device 102. In this example of the iterative key generation system 100, the device 102 is configured to iteratively generate execution stage keys 110a-110m and attestation data 112a-1121. The device 102 is configured to iteratively generate execution stage keys 110b-110m and/or iteratively generate attestation data 112a-112I (which is based on the first stage key 110a and the generated stage keys 110b-110m) in relation to one or more subsequent execution stages 106b-106m after the first execution stage 106a. For example, during execution of a current stage of execution 106b, a set of execution stage key(s) 110c and/or attestation data 112b for the next execution stage 106c are generated. Each of the set(s) of execution stage keys 110a-110m may be used by the corresponding execution stage 106a-106m as, by way of example only but is not limited to, cryptographic keys for attestation, authentication, encryption/decryption and/or cryptographic communications, cryptographic signatures, or secure data storage, and/or for use in an attestation protocol with service 104 hosted by one or more servers. Further details, modifications and/or features for iteratively generating the next stage keys and/or attestation data that may be used in device 102 and/or service 104 hosted by one or more servers are described with reference to figures 2a-2e, 3a-3d and/or 4 and/or as herein described.

[00156] Referring to figures 1 a and 1 b, as was described in relation to figure 1 a, in figure 1 b each execution stage consecutively or sequentially executes on the device 102 after the previous execution stage is completed execution. During execution of the first execution stage 106a (e.g. Stage 1 ) the first execution stage 106a is configured to generate attestation data 112a (e.g. Attest S2) for the second execution stage 106b (e.g. Stage 2). The attestation data 112a for the second stage of execution 106b may be generated based on data representative of the first stage key 110a, the device counter 114, and a measurement 118b (e.g. a digest) associated with the data comprising the second execution stage 106b. The measurement 118b of the second execution stage 106b may include generating data representative of a digest in relation to the data comprising the second execution stage 106b. The attestation data 112a in relation to the second stage of execution 106b may be generated in the same or similar fashion or manner as described in further detail with reference to attestation data 222a-222c and the like as described with reference to figures 2a-2e, 3a-3d and/or 4 and/or as herein described.

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

[00158] Alternatively, the attestation data 112a may be sent to the service 104 during execution of the first execution stage 106a, should there be functionality for this in the first execution stage 106a. Alternatively or additionally, the attestation data 112a may be stored in memory 108 in an attestation object or container 112, which may aggregate attestation data 112a-1121 in relation to one or more subsequent stage(s) 106b-106m until such time that network communications 119 is established with a server hosting the service 104, whereby the attestation object or container 112 is sent to the service 104 in relation to the attestation protocol between device 102 and service 104. The attestation object or container 112 may comprise data representative of one or more attestation data 112a-1121 (e.g. Attest S2 to Attest SM) associated with corresponding one or more subsequent stages of execution 106b- 106m (e.g. Stages 2 to M). Once network communications 119 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 112.

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

[00160] Additionally or alternatively, during execution of the second execution stage 106b, attestation data 112b (Attest S3) in relation to the third execution stage 106c may be generated based on data representative of the second stage key 110b (e.g. Key(s) 2), the device counter 114, and, by way of example only but not limited to, a digest 118c associated with the third execution stage 106c. Should network communications 119 not yet be established with the server hosting the service 104, the attestation data 110b (e.g. Attest S3) for the third stage of execution 106c may be stored in the attestation object/container 112 to form an aggregate of the attestation data 112a-112b for the execution stages 106b and 106c, respectively. The attestation data 112b associated with the third execution stage 106c may be sent to the service 104, once communication 119 with the server hosting the service 104 has been established, for use in an attestation protocol attesting at least the third execution stage 106c of the device 102. The attestation data 112b (e.g. Attest S3) may be sent during execution of the third execution stage 106c. Alternatively and/or additionally, the attestation data 112b (e.g. Attest S3) may be sent to the service 104 during execution of one of the subsequent execution stage(s) 1061, which may be configured to send the aggregated attestation data 112 comprising one or more of the attestation data 112a-1121 for one or more (or all) previous stages of execution 110a-110I and/or the current stage of execution 1101 by sending the attestation object/container 112 to the server hosting the service 104. Alternatively, the attestation data 112b (e.g. Attest S3) may be sent to the service 104 during execution of the second execution stage 106b, should there be functionality for this and/or the second execution stage 106b has established network communications 119 with the server hosting the service 104 and the like.

[00161] The attestation data 112b (e.g. Attest S3) may be generated in a same or similar fashion or manner as described in further details in relation to the attestation data 222a-222c with respect to figures 2a to 2e and/or as herein described with reference to figures 3a-3d and/or 4. The access to the second stage key 110b (e.g. Key(s) 2) in memory 108 may be disabled for all execution stages 106c-106m during or after execution of the second execution stage 106b on the device 102, but prior to execution on the device 102 of any subsequent execution stages 106c-106m. This may be achieved by overwriting the second stage key 110b in the accessible memory 108 with zeros or a new key and the like, and/or encrypting the second stage key 110b and removing any plaintext data representative of the second stage key 110b, and/or any other mechanism or method as the application demands. For example, the second stage key 110b may be made inaccessible based on the same or similar manner, fashion or approach as described in relation to the first stage key 272 and/or hardware stored secret 211 of device 202 as described with respect to figures 2a to 2e and/or as herein described with reference to figures 3a-3d and/or 4. The third execution stage 106c (e.g. Stage 3) has access to the third stage key 110c (e.g. Key(s) 3) stored in memory 108.

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

[00163] Each of the attestation data 112a-1121 (e.g. Attest S2 to Attest SM) of the corresponding stages of execution 106b-106m may be retained/aggregated in memory 108 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 112a-1121 in an attestation object or container 112. The attestation object or container 112 may include or comprise data representative of the previous and current attestation data 112a-1121 (e.g. Attest S2 to Attest SM) of the previous and current stages of execution 106b-106m apart from the first execution stage 106a. This produces a chain of attestation data 112a-112I, each portion of attestation data 112a-1121 being derived with different execution stage key that is dependent on the previous stage key(s). The aggregated attestation object or container 112 may be sent, once communications 119 have been established, to the server hosting a service 104 executing an attestation protocol as described herein with reference to figures 1 a-4 in relation to similar or same components, devices, servers and/or features as device 102 and/or service 104 hosted by one or more servers. For example, the server hosting the server 104 may be configured to iteratively generate the first stage key and subsequent execution stage keys, whilst also tracking the device counter, and is configured to use this information to perform attestation of the constrained device 102. Additionally or alternatively, after a certain number of stages of execution 106a-106b have executed in which network communications 119 have been established between device 102 and server hosting the service 104, the service 104 may prompt the sending of a batch of attestation data 112 including attestation data 112a-112b (e.g. Attest S2 to Attest S3) for the certain number of execution stages 106a-106b to the server, any subsequent or new attestation data 112c-1121 (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. [00164] Figure 1c is a flow diagram illustrating an example iterative key generation process 120 for device 102 as described with reference to figure 1 a and/or 1 b having at least a first execution stage 106a and at least a next execution stage 106b (e.g. second execution stage) of a set of execution stage(s) 106a-106m, where each of the execution stage(s) 106a-106m 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-106m, and where each execution stage 106a-106m consecutively or sequentially executes on the device 102. The iterative key generation process 120 may include the following steps of: In step 122, enabling the first execution stage 106a to have access to a first stage key 110a on the device 102. In step 124, generating, during execution of the first execution stage 106a (e.g. Stage 1 ), a next stage key 110b (e.g. Key(s) 2) for use by a next execution stage 106b (e.g. second execution stage) based on the first stage key 110a accessible by the first execution stage 106a and a nonce or changing value such as, without limitation, for example device counter 114. In step 126, storing the generated next stage key 110b (e.g. Key(s) 2 of Stage 2) in accessible storage 108 on the device 102 for access and use by the next execution stage 106b (e.g. Stage 2). In step 128, disabling access to the first stage key 110a prior to execution of the next execution stage 106b (e.g. Stage 2) and/or any subsequent execution stages 106c-106m. The first stage key 110a is accessible for use by the first execution stage 106a during execution of the first execution stage 106a on the device 102 and inaccessible thereafter.

[00165] In addition, the process 120 may further include, during execution of the first execution stage 106a, using the first stage key 110a for cryptographic operations/activities such as, without limitation, for example attestation, encryption/decryption, authentication and/or any other cryptographic operation as the application demands. For example, with reference to figure 1 b the first execution stage 106a may generate attestation data 112a (e.g. Attest S2) for the next execution stage 106b (e.g. Stage 2) in which the attestation data 112a includes data representative of an attestation code generated from the first stage key 110a, a device counter 114, and/or a digest 118b associated with the next execution stage 106b. The attestation data 112a may further include data representative of the device counter 114 and/or digest 118b of the next execution stage 106b (e.g. Stage 2). The attestation data 112a (e.g. Attest S2) of the next execution stage may be stored in memory 108 of the device 102 for sending to the server hosting the service 104, where the attestation data 110a (e.g. Attest S2) of said next execution stage 106b is used by the server for determining an indication of trust in relation to the device 102 and/or said next execution stage 106b (e.g. Stage 2). The next execution stage 106b (e.g. Stage 2), during execution, may send the attestation data 110a (e.g. Attest S2) of said next execution stage 106b to the service 104 for use in attestation of the device 102 and/or said next execution stage 106b. Alternatively or additionally, the attestation data 110a (e.g. Attest S2) of said next execution stage 106b may be stored and aggregated in memory 108 in an attestation object or container 112 along with one or more further attestation data 112c-1121 in relation to one or more subsequent stages of execution 106c-106m, and once communications 119 have been established with the server, the attestation object or container 112 is sent to the server for determining an indication of trust in relation to the received attestation data 112a-1121 of each stage of execution 106b- 106m of the device 102.

[00166] As described, the next execution stage key, or second execution stage key is generated based on the first execution stage key 110a and a nonce or changing value. This nonce or changing value may be configured to change each time the device 102 is rebooted or as instructed by a server hosting a service 104. The nonce or changing value is a device counter 114 of the device 102. The second execution stage key 110b may be generated, during execution of the first execution stage, using a key derivation function (KDF) based on the first execution stage key 110a and the nonce or device counter. The first execution stage key 110a may be based on the hardware stored secret 110 and is inaccessible thereafter.

The first execution stage key 110a may be the hardware stored secret 110 and is only accessible to the first stage of execution 106a during execution and inaccessible thereafter.

[00167] Similarly, the second stage key 110b is accessible, during execution of the second execution stage 106b on the device 102, for use by the second execution stage 106b and inaccessible thereafter. Generating the second stage key 110b for the second execution stage 106b further comprises using a KDF to generate said second stage key based on the first stage key 110a and the nonce or device counter 114. Should multiple second stage keys 110b be required, generation of the second stage key 110b for the second execution stage 106b may further include, during execution of the first execution stage 106a, generating a set of second stage keys using a KDF to generate said set of second stage keys based on the first stage key, the nonce or device counter, and/or a corresponding set of key usage parameters. Alternatively or additionally, a single second stage key of the set of second stage key(s) 110b, may be generated by the first execution stage 106a using a KDF with the first stage key 110a and the device counter 114 (or nonce/changing value), whereas the remainder of the second stage key(s) of the set of second stage key(s) 110b may be generated, during execution of the second execution stage 106b, based on a KDF with the single second stage key 110a generated by the first execution stage 106a and a set of key usage parameters and the like, and/or as the application demands. The set of second stage key(s) 110b may be used by the second execution stage, during execution of the second execution stage, for one or more cryptographic operations or activities from the group of: authentication, attestation, encryption, decryption, transport layer security, and/or any other one or more cryptographic operations or tasks.

[00168] The first stage key 110a may be based on the stored secret or a hardware stored secret on the device 102. For example, the first stage key 110a may be the stored secret or hardware stored secret, where access to the first stage key 110a (or hardware stored secret) is enabled during execution of the first execution stage 106a, in which the first execution stage 106a is configured to generate the second stage key 110a using a KDF with the first stage key 110a (or stored secret, hardware stored secret) and the device counter 114 (or nonce or changing value). The process 120 includes disabling access to the first stage key or stored secret/hardware stored secret, where the first stage key, the stored secret/hardware stored secret is inaccessible to all execution stages 106a-106m of the device 102. Alternatively or additionally, the first execution stage 106a may generate the first stage key, during execution of the first execution stage, using a KDF, the stored secret/hardware stored secret, and the nonce or device counter, where the stored secret/hardware stored secret is inaccessible thereafter. In this case, it may not be necessary to use the device counter, nonce or changing value when the first execution stage 106a generates the second stage key 110b using a KDF with the first stage key 110a and further input data such as key usage parameters. Alternatively or additionally, the device counter 114 (or nonce/changing value) may be used when generating the second stage key 110b and/or for subsequent execution stage keys 110c-110m.

[00169] Figure 1d is a flow diagram illustrating another example iterative key generation process 130 for use with a device 102 and a service 104 hosted by one or more servers as described with reference to figures 1 a-1 b in which the device 102 has M executable stages, where M>1 . In this example, the device 102 includes a number of M consecutive execution stages 106a-106m that sequentially execute on the device 102, where 1 < m £ M. During execution of the m-th execution stage, where m=1 , the process 130 may include the following steps of: In step 132, when setting m=1 , 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 m-th execution stage, based on an m-th stage key accessible to the m-th execution stage and the device counter 114 (or nonce/changing value). In step 134, storing the (m+1 )-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 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, generating and storing an 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.

Furthermore, access to the m-th key for all execution stages during or after execution of the m-th execution stage on the device 102 is disabled prior to execution on the device 102 of any subsequent execution stage (e.g. prior to execution of the (m+1 )-th execution stage). In step 136, 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+1 and proceeding to step 138.

[00170] In step 138, it is determined whether m<M, if m<M, then proceeding to step 140, otherwise proceeding to step 150. In step 140, 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 m- th 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. In step 142, storing the generated (m+1 )-th stage key in accessible storage for use by the (m+1 )-th execution stage. In step 144, performing 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). For example, without limitation, generating an 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. In step 146, disabling access to the m-th key for all execution stages during or after execution of the m-th execution stage on the device 102, but prior to execution on the device 102 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 148, incrementing m (e.g. m=m+1 ) (e.g. on completion, prior to completion or after completion of the m-th execution stage) and proceeding to step 138. In step 150, 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-1 )-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). [00171] 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 110a 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 1 <m<=M subsequent execution stages 106b-106m after execution of the first execution stage 106a and prior to execution of any other 1 <m<=M of the subsequent execution stages 106b-106m.

[00172] Steps 132, 140, 144 and/or 150 may further include, for m>1 , where applicable and when communications 119 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 102 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 106a because the first execution stage 106a may be assumed to be trusted.

[00173] The service 104 hosted by the one or more servers may be configured to perform similar or the same manner of steps or operations for deriving the next stage keys for use in cryptographic operations and/or activities with the device 102, where the device 102 includes a number of M sequential execution stages, where 1 <=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 102 (e.g. see for example key exchange and/or secret refresh process(es) of figures 2e and/or figures 3a to 3d). In order for the service 104 to derive the corresponding stage keys, 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=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.

[00174] The step of generating the (m+1 )-th stage key in relation to 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. Alternatively of additionally, the step of generating the (m+1 )-th stage key in relation to 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 a trusted counter such as server counter 222c (e.g. of figures 2d or 2e) for tracking the device counter, and/or a received device counter of the device and the like.

[00175] The data representative of the copy of the first stage key is a stored secret shared between the service 104 and the device 102, 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 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.

[00176] 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 1d at the server 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 130 of figure 1 d 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 2e and/or 3a-3d and/or as the application demands.

[00177] Figure 1 e is a flow diagram illustrating another example iterative key generation and attestation process 160 for use with a device 102 and a service 104 hosted by one or more servers as described with reference to figure 2a in which the device 102 has M executable stages, where M>1 . The device 102 includes a number of M consecutive execution stages 106a-106m that sequentially execute on the device 102, where 1 <=m<=M. During execution of the m-th execution stage, where m=1 , the process 160 may include the following steps of: In step 162, determining whether m<M, if m<M, then proceeding to step 164, otherwise proceeding to step 176. In step 164, 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 m-th execution stage, based on an m-th stage key accessible to the m-th execution stage and the device counter 114 (or nonce/changing value). In step 166, storing the (m+1 )-th stage key in accessible storage for use by the (m+1 )-th execution stage. In step 168, performing 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). For example, without limitation, generating an 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. In step 170, disabling access to the m-th key for all execution stages during or after execution of the m-th execution stage on the device 102, but prior to execution on the device 102 of any subsequent execution stage (e.g. prior to execution of the (m+1 )-th execution stage). In step 172, incrementing m (e.g. m=m+1 ) and proceeding to step 162. In step 164, 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. 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).

[00178] 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, and 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 1 <m<=M subsequent execution stages 106b-106m after execution of the first execution stage 106a and prior to execution of any other 1 <m<=M of the subsequent execution stages 106b-106m.

[00179] The step of 164 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. Steps 164, 168 or 170 may further include, for m>1 , where applicable and when communications 119 have been established with the server hosting the service 104, performing cryptographic operations and/or activities with the service or server hosting the service. For example, sending the attestation data of the m-th execution stage or previous execution stages to the service 104 for attesting and/or determining an indication of trust in relation to the device 102 and/or said at least the m-th execution stage of the device. When m=1 , there may be no attestation data for the first execution stage 106a because the first execution stage 106a is assumed to be trusted.

[00180] 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 operations or steps, or a reciprocal set of steps, as outlined in figure 1 e at the server 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 160 of figure 1 e 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 2e and/or figures 3a-3d and/or as the application demands.

[00181] Figure 2a is a schematic diagram illustrating an example iterative key generation system 200 according to the invention. In this example, the iterative key generation system 200 is configured to also perform the cryptographic operation/activity known as attestation with a remote service 204 hosted by one or more servers. Although the cryptographic operation of attestation is 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 iterative key generation system may be applied to 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 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.

[00182] The iterative key generation system 200 includes a constrained device 202 and a remote service 204 hosted by one or more servers. The one or more servers may be distributed and/or networked to form a cloud platform 203. The device 202 may communicate with the service 204 over a communications network. The device 202 and the service 204 hosted by one or more server(s) are configured to perform an attestation protocol in which the service 204 can determine whether the device 202 may be trusted or not. In this example, the attestation protocol uses attestation data that is efficiently and securely generated using iteratively generated execution stage keys. In this example, for simplicity, there are two execution stages, a first execution stage 206a and a second execution stage 206b. The first execution stage 206a includes code or instructions, which when executed on one or more processors of the device 202, causes the device 202 to execute, without limitation, for example an initial bootloader 207a and/or trusted code 207b and the like as the application demands. The second execution stage 206b includes code or instructions, which when executed on one or more processors of the device 202, causes the device to execute, without limitation, for example one or more applications, drivers, network code, and/or other bootloaders and the like for operating the device 202 and/or as the application demands.

Next stage keys and/or attestation data for any subsequent execution stage(s) (not shown) can be similarly generated and/or generated and used as described with reference to figures 1 a-4, combinations thereof, modifications thereto and/or as described herein. The attestation protocol is used for proving to the remote service 204 that the device 202, 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 202 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 204. However, in order for the remote service 204 to trust the uploaded data, the device 202 needs to prove to the service 204 that the device 202 is what it says it is and/or the software and data stored on the device 202 has not been tampered with and the like.

[00183] The device 202 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 207 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 207a and/or other trusted code 207b and the like; a non-secure memory storage 208 (e.g. application and/or data memory) for storing one or more application firmware(s) 210 (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 212 (e.g. a first stage key) and/or a device counter 214. The one or more registers for storing the hardware stored secret 212 and/or device counter 214 may be non-volatile storage based to ensure hardware stored secret 212 and/or device counter 214 values persist across reboots and/or power cycles of the device 202. The device 202 may also include a communication interface (not shown) for connecting to and communicating with the server(s) hosting the service 204. 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 208, and the communication interface. The service 204 may be hosted by a cloud- based system 203 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 204 to operate on data received from device 202. [00184] As described previously, the device 202 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 206a, a second executable stage 206b, a third executable stage (not shown in this example), and so forth. For example, the constrained device 202 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 204 for subsequent processing and/or storage and the like.

[00185] Given this, the device 202 may be configured to be limited to have two or more execution stages or multiple execution stages 206a-206b in which each execution stage consecutively or sequentially executes after a previous execution stage has completed execution. The device 202 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 202 includes at least a first execution stage 206a (e.g. Stage 1 ) that includes execution of the initial bootloader 207a and/or trusted code 207b and a second execution stage 206b that includes execution of at least part or all of the application firmware 210 (e.g. Stage 2) for operating the device 202. The device 202 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 206a-206b may be associated with a corresponding set of computer code, instructions and/or logic stored on the device 202 that is configured to execute on the device 202, 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 202 after the previous execution stage has completed execution. In this example, the first stage of execution 206a executes the initial bootloader 207a and the second execution stage 210 executes at least some or all of the application firmware 210. [00186] The first execution stage 206a comprises executable data in the secure memory storage 207 that is configured to be trusted and includes execution of the initial bootloader 207a or trusted code 207b for starting the device 202 and subsequent execution stage(s) 206b. The instruction code or data representative of the first execution stage 206a (e.g. the initial bootloader) is stored in the secure memory 207 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 202. Thus, the initial bootloader 207a may be trusted code that is booted from ROM as the first stage of execution 206a (or first execution stage), in which the data representative of the initial bootloader 207a cannot be changed. However, the second execution stage 206b 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 210 of the second execution stage 206b is typically stored in non-secure memory 208 such as application/data memory 208. Application memory 208 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 206b includes the application firmware data 210, which may include, by way of example only but is not limited to, drivers, network code and the like.

[00187] For example, the second and any subsequent execution stages 206b are typically considered to be less trusted because they include more complex instructions/code/firmware compared with the initial bootloader 207a of the first execution stage 206a. Essentially, an initial bootloader 207a 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 207a 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 206a 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 206a comprising data representative of the initial bootloader 207a and/or trusted code 207b. This allows the first stage of execution 206a to be considered as having a higher level of trust, i.e. trusted, compared with application firmware 210 and/or other code/instructions and the like stored in application memory 208.

[00188] The second execution stage 210 is considered to be less trusted than the first execution stage 206a. For example, application firmware 210 stored in application memory 208 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 204 hosted by one or more server(s) may not be able to "blindly" trust the operation of constrained device 202 after it has booted from the trusted first execution stage 206a. The attestation protocol according to the invention is used for determining by the service 204 whether the device 202 and/or one or more subsequent execution stages of the device 202 may be trusted by the service 204 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) 208 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 206b that is held in non-secure memory 208 or re-writable memory 208 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 204 hosted by one or more server(s) to establish a level of trust in relation to device 202.

[00189] The device 202 is configured to have a hardware stored secret 212 stored thereon in non-volatile memory (NVM) or within logic on the hardware of the device 202 in which the hardware stored secret 212 may be retrieved even after the device 202 having been power cycled, rebooted and the like. The hardware stored secret 212 may be considered a first stage key that may be made accessible and used by the first execution stage 206a, but is made inaccessible to any other execution stage 206b and the like. For example, the hardware stored secret 212 may be placed or put into a one-time programmable (OTP) ROM or a masked ROM on the device 202 at the time of manufacture of the device 202. The manufacturer may also store a copy of the hardware stored secret 212 in a manifest or list including data representative of a mapping between the device 202 and the hardware stored secret 212. The manifest or list may be made available to the server hosting the service 204 to allow the service 204 access to a trusted copy of the hardware stored secret 212. The hardware stored secret 212 may be data representative of a secret number or value that may be set at the time the device 202 is manufactured and is protected, by hardware/software components of the device 202, from unauthorised access. For example, the hardware stored secret 212 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 212 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 212, it is to be appreciated by the skilled person that the hardware stored secret 212 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 202 and/or as the application demands.

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

[00191] For example, the constrained device 202 may have its memory storage partitioned into secure and non-secure memory, in which the hardware stored secret 212 is stored in the secure memory and the application firmware 210 and/or associated data and the like is stored in non-secure memory 208 such as an application and/or data memory. The first execution stage 206a may have access to the secure memory 207 onto which the hardware stored secret 212 (e.g. first stage key) is stored, whereas all execution stages may have access and/or use the non-secure memory 208 such as application and/or data memory. The first execution stage 206a including bootloader 207a may be configured to have access to everything on the device 202 including the hardware stored secret 212, and then be configured to protect the hardware stored secret 212 and make it non-accessible to subsequent execution stages 210 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 212 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 212 in which the register(s) have a control bit for turning access off to the register(s) holding the hardware stored secret 212, but in which access is turned on based on a reset of the device 202; or any other logic, hardware/software that may be used to enable the first stage of execution 206a access to the hardware stored secret 212, but which is inaccessible thereafter or prior to execution of subsequent execution stages 206b and the like.

[00192] In other examples, the hardware stored secret 212 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 206a. The first execution stage 206a is stored in, by way of example only but is not limited to, a secure memory 207 such as a ROM. So as long as running from the secure memory 207, then the non-volatile memory region or register can be accessed and hence the hardware stored secret 212 accessed. The secure memory 207 may include data representative of the initial bootloader 207a of the first execution stage 206a and also the hardware stored secret 212, when the execution of the initial bootloader 207a finishes or completes execution, then the non-volatile memory storing the hardware stored secret 212 becomes inaccessible. In another example, the hardware stored secret 212 may be stored in non-volatile memory with a register in front of it. On a reboot of the device 202, the device loads the register with the hardware stored secret 212 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 206b. It is made inaccessible to all execution stage(s) during execution of the first execution stage 206a and/or after the first execution stage 206a completes execution. In a further example, a part of the non-volatile memory holding the hardware stored secret 212 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 212 cannot be accessed as the written bit to the control register is configured to not clear unless there is a reboot of the device 202. In another example, some hardware on the device 202 may be configured, as part of the reboot process, to copy the contents of a non-volatile memory storing the hardware stored secret 212 into regular RAM or non-secure memory 208 where the non-volatile memory is not accessible by the processor, and to make the hardware stored secret 212 inaccessible again it may be overwritten in the non-secure memory 208. Although several examples of storing and/or accessing the hardware stored secret 212 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 212 on the device and securely controlling access to the hardware stored secret 212 such that it is accessible for use by the first execution stage 206a during execution but inaccessible to any subsequent execution stage 206b and the like and/or as the application demands. [00193] In this example, the constrained device 202 also includes a trusted component or trusted attestation component or module 214-220 based on logic, hardware and/or software that is configured to perform an attestation protocol with the service 204. 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 204.

[00194] For example, the constrained device 202 is configured to retrieve the hardware stored secret 212 as a first stage key (or a device key) accessible to the initial bootloader of the first execution stage 206a. During execution of the initial bootloader of the first execution stage 206a, the first execution stage 206a performs: 1 ) a measurement of the application firmware 210 of the subsequent execution stage 206b (e.g. generates a digest of the application firmware 210 of the subsequent execution stage 206b). As an option, the first execution stage 206a may verify the signature or message authentication code (MAC) of the subsequent stage 206b; 2) adjustment of the device counter 214 based on a known pattern or expected manner (e.g. increment, decrement of the counter); 3) storing the measurement of the subsequent execution stage 206b, the device counter 214 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; and 5) computes a next-stage key for the subsequent execution stage 206a that will execute after the first execution stage 206a and places the next stage key in memory 208 that is accessible to the subsequent execution stage 210 (e.g. the next stage’s memory); 6) eliminates access to the first stage key and/or hardware stored secret 212 such that these are both inaccessible to any subsequent execution stage; and 7) forwards control or execution to the next subsequent execution stage 206b of the device 202. The subsequent execution stage 206b of the device 202 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 202 has established communications with the server hosting the service 204 (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 204 for performing attestation of the device 202. Thus, the service 204 is able to use the received aggregate attestation measurements to determine an indication of whether the device 202 is trusted or not. No later execution stage can access the first stage key (e.g. hardware stored secret) 212 or counter value of counter 214, 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.

[00195] The trusted attestation component 214-220 includes, by way of example only but is not limited to, a device counter 214, a message authentication code (MAC) function 216, and/or digest generation function 220. The MAC function 216 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 214- 220 is configured to generate attestation data for use by the service 204 in attesting the device 202. In this example, the attestation component takes a measurement of the second stage of execution 206b that includes application firmware 210 by using a digest generation function 220 (e.g. a hash function) to generate a digest of the second stage of execution 206b that includes application firmware 210. The firmware/software 210 prior to execution is simply treated as data in application memory 208, so that a digest may be calculated by passing the data representative of the application firmware/software 210 through the digest generation function 220 (e.g. a hash function) prior to and/or in the initial stages of execution of the second stage of execution 206b. 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 212, the digest of the data representative of the second stage of execution 206b that includes application firmware 210 and the device counter 214.

[00196] The device counter 214 may be configured, adjusted and updated to track the number of reboots of the device 202 and/or device key refreshes of the device 202 and the like. The device counter 214 may be adjusted in a known or expected manner, which allows the service 204 hosted by one or more server(s) to also track the expected behaviour of the device counter 214. For example, the device counter 214 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.

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

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

[00199] The service 204 is configured to receive the attestation data in relation to the second execution stage 206b and determine or attest, based on the received attestation data 222a- 222c (or attestation data 222a and 222c), whether the device 202 and/or the second execution stage 206b of the device 202 is to be trusted or not. In order to do this, the service 204 is configured to have access to a secure copy of the hardware stored secret 212 of the device 202, referred to as hardware stored secret 226 and/or a trusted copy of the digest in relation to the second execution stage 210 and/or each execution stage of the device 202.

The hardware stored secret 212 and/or digest in relation to each execution stage of the device 202, 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 202, derived from a master key known to the service 204. For example, a manufacturer of the device 202 may generate the hardware stored secret 212 for storage on the device 202 during manufacture of the device 202. The hardware stored secret 212 of the device 202 may also be stored within a manifest or database associated with manufactured devices. The service 204 may have registered the device 202 with the service 204, which may involve provisioning the service 204 with a copy of the hardware stored secret 226 of the device 202 from the manifest or database. For example, the hardware stored secret 212 may be derived from a master key known to the service 204, 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 204 has access to and/or is capable of deriving the hardware stored secret 212. In any event, the service 204 is assumed to have a trusted copy of hardware stored secret 226, which is the same as the hardware stored secret 212 that is stored on the device 202, 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 202.

[00200] Given the service 204 knows the hardware stored secret 212, it can then calculate a second tag (or attestation code) 228 associated with the second execution stage 206b by inputting data representative of: a trusted copy of the expected digest associated with the second execution stage 206b, the received device counter (or a service counter used to track the expected behaviour of the device counter 214), and the copy of the hardware stored secret 226 into a MAC function 230, which is the same as the MAC function 216 of device 202. The received tag 222a associated with the second execution stage 206b is compared with the second tag 228 calculated by the service 204. If both the tags 222a and 228 match, then the service 204 may trust the device 202 is what the device 202 says it is and/or trust that the second execution stage 206b of the device 202 is what the device 202 says it is executing or will be executing. Thus, the service 204 may be able to trust the application firmware 210 of the second execution stage 206b of the device 202 if the second tag 228 matches the received tag 222a. If the second tag 228 does not match the received tag 222a, then the service 204 is configured not to trust the device 202 and/or at least the second execution stage 206b of the device 202.

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

[00202] Moreover, the rules and/or policies of the trust management of the service 204 may also be used to monitor the behaviour of the device counter 214, which may be via the service counter 224 that corresponds to the device counter. Thus, when the attacker does not change the attestation data 222a-222c, then the service 204 may be able to detect that the device counter 214 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 224 may be adjusted in the expected manner as the device counter 214 is adjusted in. For example, the trust management of the service 204 may have rules and/or policies that expect that the device 202 to have scheduled reboots (e.g. daily, weekly, monthly etc.), and so expect the device counter 214 to be adjusted according to an expected adjustment pattern/schedule or manner. The device counter 214 may be adjusted, by way of example only but not limited to, by either monotonically increasing the device counter 214 or monotonically decreasing the device counter 214, and/or any other adjustment pattern/schedule (e.g. an increasing and/or decreasing pattern/schedule and the like). Thus, if the device counter 214 were to be maintained at its state or value for longer than expected by the service 204, the trust management of the service 204 may then be configured to determine whether to trust the device 202 or not or the second execution stage of the device 202 based on the expected behaviour of the device counter 214. The service 204 may be configured to request the device 202 reset itself and/or reboot itself and update the device counter 214 by adjusting (e.g. incrementing/decrementing) the device counter 214 in the expected manner according to the rules/policies for when the device counter 214 is to be adjusted. The service counter 224 may be adjusted in a similar fashion in order to track the adjustments to the device counter 214. In which case, the service 204 would then expect a new (e.g. incremented/decremented) device counter value 222c corresponding to the updated device counter 214 in the next set of attestation data compared with the previous value of the device counter 214 the previous set of attestation data. Thus, the service 204 may be able to reasonably detect a replay attack of an attacker by monitoring the device counter 214 in relation to the service counter 224 and/or simply monitoring the received device counter 222c values follow the expected adjustment behaviour of the device counter 214.

[00203] Figure 2b is a flow diagram illustrating an example device attestation process 240 for a device 202 of figure 2a to perform the attestation protocol with service 204. The device 202 includes a first execution stage 206a and at least another execution stage 206b, where each execution stage 206a and 206b 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 or 206b, where each execution stage sequentially executes on the device 202. The device attestation process 240 includes the following steps of: In step 242, enabling the first execution stage 206a to have access to a hardware stored secret on the device 202. In step 244, generating attestation data, during execution of the first execution stage 206a, including data representative of the hardware stored secret 212, the device counter 214, and a digest associated with the next execution stage 206b. In step 245, disabling access to the hardware stored secret 212 during or after execution of the first execution stage on the device 202, but prior to execution of the next execution stage 206b on the device 202, where the hardware stored secret 212 is inaccessible thereafter to all execution stages. In step 246, storing the attestation data for sending to the service 204 for attesting at least the next execution stage 206b of the device 202. 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 208 and after the device 202 has established communication with the server of the service 204 does the device 202 send the aggregated attestation data in relation to each execution stage of the device 202 to the service.

[00204] Additionally or alternatively, step 244 may further include the steps of: generating a digest 222b of data representative of the next execution stage 206b on the device 202; generating an attestation code or tag 222a using a MAC algorithm or function based on the generated digest 222b, the device counter 214, and the hardware stored secret 212 of the device 202; and storing attestation data comprising data representative of the attestation code or tag 222a and the device counter 222c. Alternatively or additionally, the attestation data may include data representative of the attestation code or tag 222a, the generated digest 222b, and the device counter 222c.

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

[00206] Figure 2c is a flow diagram illustrating an example service attestation process 250 for a service 204 hosted by a server of figure 2a to perform the attestation protocol with device 202 in response to the device attestation process 240 of figure 2b. The service attestation process 250 may be performed by the service 204, which may be hosted by a server or one or more server(s), the service 204 associated with the device 202 and/or other device(s), where the service 204 has access to secure storage including a trusted copy of the hardware stored secret 212 of the device 202 and also a trusted copy of each of the execution stage(s) 206b of the device 202. The service attestation process 250 further including the following steps of: In step 252, receiving attestation data from the device 202, when communications are established, the received attestation data associated with the next execution stage 206b of the device 202 and/or aggregated attestation data associated with multiple execution stage(s) of the device 202 (e.g. the device 202 has more than two execution stages). The attestation data for the next execution stage 206b may include data representative of the attestation code or tag 222a and a device counter 222c. Alternatively or additionally, the attestation data for the next execution stage 206b may further include a digest associated with the next execution stage 206b. Although the digest associated with the next execution stage 206b is not required by the service 204 (e.g. it may have a trusted copy of the digest of each execution stage of the device 202), there may be some scenarios in which transmitting the digest is useful. For example, for use in further determining with confidence whether the device 202 has been tampered with and/or for other procedures/protocols and the like. The attestation data may be aggregated on the device 202 prior to the device 202 establishing communications with the server of the service 204, 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 server of the service 204 have been established, the device 202 may send an aggregated attestation data to the service 204 in relation to each of the subsequent stages of execution (apart from the first stage of execution) to the service 204. In step 254, for each execution stage of the device 202 apart from the first execution stage 206a, attestation code or a tag 228 in relation to said each execution stage is generated by the service 204 based on the copy of the hardware stored secret 226, 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 228 may be generated for each subsequent execution stage of the device 202. In step 256, trust management is performed in relation to each execution stage 206b and/or the device 202 based on the comparing the received attestation code or tag 222a in relation to said each execution stage 206b with the generated attestation code or tag 228 in relation to each execution stage 206b.

[00207] The received attestation data may include data representative of an attestation code or tag 222a in relation to the next execution stage 206b and the device counter 222c. The received attestation data may also or optionally include the generated digest 222b associated with the next execution stage 206b. The received attestation code or tag 222a is generated by the device 202 using a MAC algorithm based on the generated digest 220, the device counter 214, and the hardware stored secret 212 of the device 202. Step 254 includes generating a second attestation code or tag 228 using the same MAC algorithm as the device 202 used to generate the corresponding received attestation code or tag 222a. In step 254, generating the second attestation code or tag 228 uses the MAC algorithm based on a trusted copy of the digest, the received device counter 222c, and a copy of the hardware stored secret 226 accessible to the service 204. Step 256 may further include the steps of: comparing the second attestation code or tag 228 with the received attestation code or tag 222a; and performing trust management in relation to the next execution stage 206b and/or the device 202 based on the comparison of attestation code or tags 222a and 228.

[00208] Additionally or alternatively, step 256 may further include the steps of: monitoring the device counter 214 based on the received device counter 222c and the expected behaviour of the received device counter 222c; and performing trust management in relation to the next execution stage 206b and/or device 202 based on an expected behaviour of the device counter 214 in relation to the received device counter and/or the data received in the attestation data from the device 202.

[00209] Although the example iterative generation system, 200 and device 202 are described in relation to attestation with reference to figures 2a-2c, 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 used in place of or in conjunction with, combined with the attestation protocol as described in figures 2a-2c. 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 214 may be sent to and/or used by the service 204 hosted by the server to determine a TLS-PSK key and/or for use in TLS communications between device 202 and service 204 hosted by the one or more server(s) and the like.

[00210] Figure 2d is another schematic diagram illustrating another example iterative key generation system 260 according to the invention based on the iterative key generation system 200 of figures 2a-2c in which device 202 and service 204 hosted by one or more server(s) have been further modified to enhance the attestation protocol. The device 202 of the iterative key generation system 260 is further modified by dividing the device counter 214 into a first device counter 214a (e.g. an epoch counter) and a second device counter 214b (e.g. a cohort counter). The first device counter 214a is configured to count the number of events and/or requests for changes from the service 204 in relation to the device 202. For example, the epoch counter or the first device counter 214a may be adjusted by some event associated with the service 204 such as, by way of example only but not limited to, a request of change by the server of the service 204, a request by the service 204 for rebooting the device 202, a request by the service 204 for refreshing the first stage key of the first execution stage 206a (e.g. Stage 1 ), and/or any other request by the service 204 that changes the configuration of the device 202 and the like. The second device counter 214b is configured to count the number of reboots of the device 202. The advantage of having the device counter 214 being split into a first and second device counter 214a and 214b, respectively, (e.g. epoch and cohort counters) is that it partitions adjustments of the device counter 214 in relation to various events requested by the server of the service 204 and internal events of the device 202 and the like. For example, the service 204 can control changes made to the first device counter 214 by, by way of example only but not limited to, requesting when a reboot of the device 202 is made, and/or requesting a key refresh of the device 202. The device 202 internally/automatically changes or adjusts the second device counter 214b in the event of a reboot of the device. That is, the device counter 214 is split into a first device counter 214a that changes slowly or less often as the service 204 may request an event that changes the device 202, which means the device 202 is configured to adjust the first device counter 214a accordingly when it receives such requests from the service 204, whereas the second device counter 214b may change more regularly and is internally driven by events occurring on the device 202 (e.g. user reboots, device turns off/on etc.).

[00211] The device counter 214, which includes the first and second device counters 214a- 214b, is used in the same manner as calculated for iterative key generation system 200 when device 202 generates the attestation data in relation to the second stage of execution 206b (e.g. Stage 2). The second stage of execution 206b may include application firmware and the like. The attestation data in relation to the second stage of execution 206b includes the attestation code or tag 222a and the device counter 214 including the first and second device counters 214a and 214b. Alternatively or additionally, the attestation data in relation to the second stage of execution 206b may include the attestation code or tag 222a, the generated digest of the second execution stage 206b, and the device counter 214 including the first and second device counters 214a and 214b.

[00212] The attestation data 222a-222c in relation to the second stage of execution 206b may be stored in memory 208 for access and sending by the second stage 206b or any subsequent execution stages once the device 202 establishes communications with the server of service 204. For example, an attestation data 222a-222c may be sent via an attestation message 223 to server hosting the service 204. This may be because the initial bootloader of the first execution stage 206a may not have the capability to connect with the service 204 (e.g. a security measure) and send attestation data based on the stored attestation data 222a-222c. In which case, when the initial bootloader of the first execution stage 206a boots the second execution stage 206b including the application firmware associated with the second execution stage 206b, the application firmware may, as part of the attestation protocol, be configured to connect with server of service 204 and send the required portions 223 (e.g. as an attestation message) of the attestation data in relation to the second execution stage 206b to the service 204. However, if there are subsequent stages of execution (e.g. stage 3) on device 202 and the second stage of execution 206b is not configured to establish communications with server of service 204, 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 204.

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

[00214] As described previously, the trust management of service 204 may include one or more additional rules based on expected behaviour of the device counter 214. For example, a rule may be made in which the device counter 214 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 204 may assign a level of trust to the device 202 as it knows the conditions under which the device 202 may reboot or have a change of configuration and the like. The trust management of the service 204 may instruct the device to perform a reboot 264, if the trust management determines, after a reboot of the device, that the received device counter value 222c as received by service 204 is the same as was previously received after the reboot, then it knows something is wrong with the device 202 or with the communications between server and the device 202. The trust management of the service 204 may become suspicious of device 202 and/or decrease the level of trust associated with the device 202. The service 204 may also send an epoch update request 266 to the device 202 for rebooting the device 202 in which the device 202 adjusts (e.g. increments or decrements) the first device counter 214a (e.g. increase/decrease the epoch) in an expected manner in response.

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

[00215] Although an attacker may intercept the epoch update request 266 from the service 204 for adjusting (e.g. increasing/decreasing) the first device counter 214a (e.g. increasing/decreasing the epoch), then this would prevent the adjusting the first device counter 214a by device 202 in a manner expected by the server of service 204, and when the device 202 re-sends the attestation data in relation to the second stage of execution 206b after the reboot and the like, then the trust management of the service 204 can determine that there is a problem with the device 202 and that communications with the device 202 and/or the device 202 may be being tampered with. As a result the trustworthiness and/or level of trust associated with the device 202 may be decreased, e.g. decreased to untrusted and send a denial 262 of communication connection with device 202. The trust management of service 204 may also perform thresholding, threshold games and/or rules or policies for determining the level of trust that may be assigned to the device 202 and/or to each execution stage of the device 202. For example, counter deviation thresholds/thresholding games/rules may be defined, without limitation, for example for the behaviour of the first counter 214a and the second counter 214b in which the first counter 214a is not allowed to deviate from an expected value whereas the second counter 214b 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 204 was lost, then it may send this message a predetermined number of times to determine the behaviour of the first device counter 214a and assist in making risk management decisions in relation to the first device counter 214a 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 202 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.

[00216] The device 202 and service 204 may be configured to perform cryptographic operations and/or activities during execution of the second execution stage 206b and/or subsequent execution stages of the device 202 using a second stage key 274 (or subsequent stage keys for corresponding subsequent execution stages) 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 202 and the service 204, and/or for use by the second execution stage 206b in generating attestation data in relation to a next or third execution stage and/or subsequent execution stages and the like, if any. For example, a device 202 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 206b, the second stage key 274 may be used to generate a set of secret keys may be derived using a KDF and further input data such as, without limitation, for example key usage parameters or a set of key usage parameters and the like.

[00217] As described with in the iterative key generation system 100 described with reference to figures 1 a-1 e, the iterative key generation system 260 can iteratively derive one or more secret keys (or one or more execution stage keys) for an execution stage 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 also assumes that the other party, e.g. the server of the service 204 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 server hosting service 204 would require access to the secret key used to generate the attestation code or tag 222a 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 202 and/or is able to track 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 202. Since the hardware stored secret 212 (or first stage key) of the device is meant to be kept secret and inaccessible to the second and/or subsequent execution stage(s) 210, the device 202 and the service 204 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, without limitation, for example symmetric keys in which both the service 204 and the device 202 are capable of generating and so may use the same key. Iterative generation of stage keys may be based on the iterative generation key system as described with reference to figures 1 a-1 e and/or as describe herein with reference to figures 2a-4, combinations thereof, modifications thereto and the like.

[00218] As described, the data and/or code representative of the second execution stage 206b 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 204 and/or for generating tags/attestation codes in relation to subsequent execution stages and storing as attestation data for sending to service 204.

The generation of a credential and/or a secret key for the second execution stage 206b, a so- called second stage key 274, is performed during execution of the immediately preceding execution stage (e.g. the first execution stage 206a) using a previous execution stage key (e.g. hardware stored secret 212, which may be the first stage key of the first execution stage 206a). In this case, the first execution stage 206a is the immediately preceding execution stage of the second execution stage 206b, and so the first stage execution key 272 is used to generate the second stage key 274. The first stage execution key 272 may be based on, by way of example only but not limited to, the hardware stored secret 212. The first stage execution key 272 is used for generating the second stage key 274 using a Key Derivation Function (KDF) 270a. Thus, the first stage key 272, which is based on the hardware stored secret 212, may be input with the device counter 214 to the KDF 270a, and optionally, along with a key usage parameter 273a to generate the second stage key 274. Different key usage parameters 273a may be used to generate different second stage keys. Alternatively or additionally, a single second stage key 274 may be generated and the second execution stage 206b may be configured to use a KDF to generate further second stage keys based on the single second stage key 274 and a set of key usage parameters and the like.

[00219] The key usage parameter 273a 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", "decryption" and any other usage) known to the device 202 and/or the service 204 hosted by the one or more server(s). As the service 204 has a trusted copy of the hardware stored secret 212 and also has access to the device counter 214 via attestation data or the service counter 224, which tracks the device counter 214, the service 204 can derive the first stage key 272 and so may also derive the second stage key 274, once it receives the attestation data in relation to the second execution stage 210. The key usage parameter 273a 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 273a is an identifier for the type of secret key that is to be generated.

[00220] Generally, a KDF 270a 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 202 and service 204 (e.g. salt such as device counter 214 and key information such as key usage parameters 273a and the like). Any suitable KDF may be used such as, by way of example only but not limited to, an FIMAC KDF or FIKDF, 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. In this case, the master key is the first stage key 272, which is based on the hardware stored secret 212 and the agreed information may be the device counter 214 (or an agreed nonce or changing value) and key usage parameter 273a. The first stage key 272 may be the hardware stored secret 212 and/or generated using a KDF with the hardware stored secret 212 and/or any other input parameters, without limitation, for example key usage parameter, or device counter or any other nonce/changing value and the like. The KDF 270a generates a second stage key 274 from the first stage key 272, device counter 214 (or a nonce/changing value) and key usage parameter 273a, which is stored as the second stage key 274 in memory 208. 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 214 and key usage parameter, respectively. The KDF 270a may generate a second stage key based on second stage key = HKDF(first stage key 272, device counter 214, key usage parameter 273a). [00221] The KDF 270a is configured to ensure that the second stage key 274 cannot be used to derive the first stage key 272 or the hardware stored secret 212. One or more different second stage key(s) to the second stage key 274 may be generated based on different key usage parameters from the set of predefined values and stored in memory 208. The one or more different second stage key(s) are used by the second execution stage 206b and/or when required. Although the KDF 270a may be based, by way of example only but is not limited to, the FIMAC KDF or FIKDF and its derivatives etc., it is to be appreciated by the skilled person that any suitable KDF may be used by KDF 270a 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.

[00222] Once the first execution stage 206a has generated the second stage key(s) 274 and the first execution stage 206a has finished using the first stage key 272, the first stage key 272 and the hardware stored secret 212 are made inaccessible to the second execution stage 206b and any subsequent execution stage(s) prior to execution of the second execution stage 206b. This prevents the first stage key 272 and the hardware stored secret 212 from being exposed to the second execution stage 206b and/or subsequent execution stages. Making the first stage key 272 and/or hardware stored secret 212 inaccessible may include removing any data representative of the first stage key 272 and hardware stored secret 212 from the memory 208 of the device 202, and securing the hardware/memory/registers associated with the first stage key 272 and/or hardware stored secret 212 to be inaccessible. Although the first stage key 272 and hardware stored secret 212 are shown to be stored in separate locations, it is to be appreciated by the skilled person that the first stage key 272 may be the hardware stored secret 212, and thus, is stored securely in one location on the device 202. The memory 208 is used as an application memory for storing the application firmware of the second execution stage 206b, and can also be used to store the generated one or more second stage key(s) 274 (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) 274 are stored in memory 208, which the first execution stage 206a makes available.

[00223] In addition to the first execution stage 206a of the device 202 generating one or more second stage key(s) 274 for use by the second execution stage 206b during execution of the second execution stage 206b, the service 204 may be modified and configured to implement a similar type of KDF calculation to generate the same corresponding set of second stage key(s) 276. This can be used for symmetric encryption during a communication session between device 202 and service 204. In this regard, the service 204 also has a KDF 270b, which is the same as the KDF 270a of device 202, for generating the corresponding second stage key(s) 276 using the same input key and key information. This is possible because the service 204 has access to the copy of the hardware stored secret 226, from which the first stage key 272 may be derived, and the device counter 222c, and it is configured to know the key usage parameters that the device 202 uses to generate the one or more second stage keys 274. Thus, the service 204 generates a set of second stage keys 276 that correspond to the one or more second stage keys 274 stored in memory 208 of device 202.

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

[00225] For example, when the bootloader of the first execution stage 206a completes, the bootloader then boots 278 the application firmware of the second execution stage 206b. Prior to this point or at this point, the bootloader of the first execution stage 206a completes its execution, and prior to the execution of the application firmware of the second execution stage 206b the first execution stage 206a and the hardware stored secret 212/first stage key 272 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 212/first stage key 272. The device counter 214 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 202 reboots. Alternatively or additionally, the device counter 214 is incremented by logic/hardware and/or software (e.g. attestation components) that performs the attestation protocol between device 202 and service 204.

[00226] Once booted, the application firmware of the second execution stage 206b takes the attestation data 222a-222c stored by the first execution stage 206a and sends an attestation dataset or container 223 in relation to second execution stage 206b including data representative of at least the attestation data corresponding to the authentication data or tag 222a and device counter 222c to the service 204 once the application firmware connects with the service 204. Alternatively or additionally, the attestation dataset or container 223 in relation to the second execution stage 206b may include, if required, attestation code or tag 222a, the digest 222b of the second execution stage 206b, and device counter 222c. The service 204 may use the received attestation dataset or container 223 to generate the required second stage keys 276 for use in a secure communication session with device 202, and/or for performing the attestation protocol in relation to device 202. For example, the second stage key 274 generated by the device 202 and the corresponding second stage key 276 generated at the service 204 may be used to form, by way of example only but is not limited to, a transport layer security (TLS) session between device 202 and service 204.

[00227] The server hosting the service 204 may store the previous device counter 214 that it has received as a last device counter 268. This allows the service 204 to perform a comparison 269 between the last device counter 268 and the current received device counter 222c of a currently received attestation dataset or container 224. If the device counter 214 is adjusted as expected (e.g. is a monotonically increasing counter or a monotonically decreasing counter), then if the last device counter 268 when compared to the current received device counter 222c is not behaving as expected, then the service 204 may determine a replay attack may be being performed and the device 202 is to be untrusted.

[00228] The trust management of the service 204 may form multiple rules for determining the behaviour of the device counter 214 and for detecting whether the device 202 and/or communications between service 204 and device 202 are being tampered with by an attacker. For example, the trust management of service 204 may form a rule that after X (e.g. X=10) connection attempts, the service 204 should instruct the device 202 to perform a reboot 264 and/or send an update epoch request 266 to increase the first device counter 214a (e.g. increase epoch) in order to get a new count. Furthermore, the service 204 or the server hosting the service 204 may have a service or server counter 224 that may be used to track the device counter 214 and/or use to track at least the first device counter 214a. The first device counter 214a is used to track the number of changes requested by the service 204, so the service 204 may adjust its service counter 224 each time it requests a change on the device 202 (e.g. a reboot, epoch update, or secret key refresh etc.), which the device 202 is meant to record by adjusting the first device counter 214a. One or more rules and/or policies may use the service counter 224 and the received device counter 222c to determine whether the device counter 214 is behaving in an expected manner. For example, the service counter 224 may be compared with the corresponding portion of the received device counter 222c (e.g. the first device counter 214a) to determine whether the device counter 214 has been adjusted as requested by the service 204. The trust management may be configured to use the device counter 222c, last count 268 and/or service counter 224 to check whether the device 202 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 204 is operating in a cloud platform 203 and/or is hosted by one or more servers.

[00229] Figure 2e is another schematic diagram illustrating another example iterative key generation system 280 according to the invention based on iterative key generation systems 100, 200 and 260 of figures 1 a-2d in which device 100 or 202 and server(s) hosting service 104 or 204 have been further modified to enable a secret key refresh or a update of the first stage key 272 whilst enabling the first stage key 272 (e.g. first stage key 110a) to be inaccessible prior to execution of the second execution stage 206b (e.g. second execution stage 106b). This further enhances the iterative key generation scheme and also the example cryptographic operations, without limitation for example the attestation protocol and the like as described herein. Figure 2e 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 272 of the device 202. The shared key mode of operation describes a scenario in which the hardware stored secret 212 is known by both the device 202 and the service 204 hosted by one or more server(s). The public key mode of operation describes a scenario in which the hardware stored secret 212 is not known by the service 204 hosted by the one or more server(s).

[00230] In the example shared key mode of operation of iterative key generation system 280, the hardware stored secret 212 is assumed to have been securely shared with the service 204 associated with the device 202. For example, the hardware stored secret 212 of the device 202, which is stored on non-volatile memory of the device 202, may be securely shared via a manifest provided by the manufacturer of device 202 with the service 204. In another example, the operators or providers of the service 204 may arrange for the hardware stored secret 212 to be set on the device 202 by, for example but not limited to, pre-installing the hardware stored secret 212 in secure non-volatile memory on device 202 before deployment of the device 202. In a further example, the hardware stored secret 212 of the device 202 may be securely shared with the service 204 via a key exchange mechanism/protocol between device 202 and/or service 204. Although several methods of securely sharing the hardware stored secret 212 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 212 may be used and/or as the application demands.

[00231] In any event, in the shared key mode of operation, the hardware stored secret 212 of the device 202 has been securely shared with the service 204 hosted by one or more server(s). The device 202 of the iterative key generation system 280 is further configured by having the hardware stored secret 212 act as a key for decrypting the first stage key 272 during execution of the first stage of execution 206a. The first stage key 272 may be stored in encrypted form in non-volatile memory 208, which may be unsecured memory. The first stage key 272 may also be a symmetric key. The first stage key 272 may be decrypted prior to or during execution of the first stage of execution 206a using the hardware stored secret 212. The hardware stored secret 212 may be made accessible only to the first stage of execution 206a as described herein. The decrypted first stage key 272 may be used by the first execution stage 206a of the iterative key generation mechanism for generating the second stage key 274 using a device counter 214 (or nonce/changing value) as described with reference to figures 1 a to 2d and/or as described herein and/or used by the attestation protocol as described with reference to figures 1 a to 2d and/or as described herein. The first stage key 272 is then made inaccessible when the first execution stage 206a hands over execution to the second execution stage 206b, and is inaccessible thereafter to all other stages of execution.

[00232] Making the first stage key 272 inaccessible may include, by way of example only but is not limited to, removing or deleting data representative of the plaintext first stage key 272 or the decrypted first stage key 272 from memory 208 prior to execution of any of the other stages of execution 206b and the like whilst leaving the first stage key 272 encrypted by the hardware stored secret 212 in memory 208. The hardware stored secret 212 is stored on the device 202 and the corresponding hardware stored secret 226 (e.g. the copy of the hardware stored secret 212) is securely stored by the service 204 and is accessible to the service 204. The hardware stored secret 212 is configured to be inaccessible to all subsequent execution stages 206b and the like apart from the first execution stage 206a. Additionally or alternatively, the hardware stored secret 212 may be configured to be inaccessible to all execution stages 206a and 206b etc., but is used for initially decrypting the first stage key 272, which is encrypted with the hardware stored secret 212 prior to or during the execution of the first execution stage 206a. The first stage key 272 is configured to be inaccessible to the second execution stage 206b and any other subsequent execution stages when executed on the device 202.

[00233] In the shared mode of operation, the corresponding hardware stored secret 226 stored by the service 204 can be used by the service 204 to deliver at least a new first stage secret key to the device 202. As previously described with reference to figures 1 a-1 e, the first stage secret key 106a (e.g. first stage key 272) may be used to derive one or more second stage keys 106b (e.g. second stage key 274) on the device 102 (e.g. device 202), which are then used to, if required, derive/generate one or more next stage keys on the device 102 (e.g. device 202) and so forth. Alternatively or additionally, this iterative generation process may also be bypassed as the iterative key generation system 280 may be configured such that the service 204 may generate the first stage key and also any further second stage and/or subsequent stage keys and refresh these keys on the device 202 based on the shared mode of operation. Thus, the service 204 or servers hosting the service 204 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 1 a-2d and/or as described herein. Such methods may be used for extremely constrained devices that may not have the capability to perform key generation.

[00234] Nevertheless, assuming the device 202 is configured to iteratively generate keys as described with reference to figures 1 a-2d and/or as described herein, then the service 204 and/or server hosting the service 204 may be configured to refresh the first stage key 272 of the device 202. For a first stage key 272 refresh using the shared mode of operation, the service 204 may determine that a secret key refresh is required of at least the first stage key 272 and so may initiate the secret key refresh by sending the device 202 a secret key refresh request 281 (e.g. shared key mode refresh). For the secret key refresh request 281 , the service 204 generates one or more new first stage keys 272 and encrypts, which may be without limitation for example authenticated encryption, these new secret keys using the hardware-stored-secret 226 to generate a secret key refresh ciphertext. 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) 266 (e.g. adjustment of the first device counter 214a), which is used by the device 202 to initiate a reboot and decrypt the secret key refresh ciphertext after the reboot. The service 204 may adjust a service counter 224 to track the changes requested by the service 204 of the device 202, which includes the secret key refresh request and/or the epoch counter update. The secret key refresh is sent to the device 202, when communications have been established between device 202 and service 204, which is typically when one or more subsequent execution stages are executing (e.g. when the second execution stage 206b is executing). In this example, the secret key refresh is sent to the device 202, when the second execution stage 206b is executing and where the device 202 is configured (e.g. second execution stage 206b may be configured accordingly) to store the new secret key refresh ciphertext internally in memory 208. This may be in a particular memory location of memory 208, which the device 202 or first execution stage 206a 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 208, in which the device 202 or the first execution stage 206a is configured, on rebooting, to validate and identify the most up to date ciphertext for refreshing the secret keys.

[00235] Once the new secret key refresh ciphertext is stored, the device 202 is configured to reboot, the device 202 reboots in which the first execution stage 206a is configured to adjust (e.g. increments/decrements or replaces with the epoch counter value) the first device counter 214a (e.g. ordered by the epoch counter indication) in accordance with the new secret key refresh. The device 202 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 204. If the new secret key refresh ciphertext only includes data representative of a new first stage key, then the first execution stage 206a may simply overwrite the current encrypted first stage key 272 stored in memory 208, which may be decrypted using the hardware stored secret 212 during execution of the first execution stage 206a.

[00236] 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 202. The device 202 is configured to use the hardware stored secret 212 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 212 and replace the current encrypted first stage key 272 with the encrypted new first stage key. The device 202 may be configured to also place the decrypted additional data into the appropriate memory locations of memory 208 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 206b, and next stage keys 274 for the second stage of execution 206b and the like. Once the first stage of execution 206a 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 206b and the like on the device 202.

[00237] As a more detailed example, in the shared mode of operation, the service 204 may determine that a secret key refresh is required of at least the first stage key 272 and so may initiate the secret key refresh by sending the device 202 a secret key refresh request 281 (e.g. shared key mode refresh). For the secret key refresh request 281 , the service 204 encrypts a new secret key, using authenticated encryption with associated data (AEAD) with the first device counter 214a (e.g. the epoch counter/service counter 224) as the associated data and encrypted using the hardware-stored-secret 226, which is the same as the hardware stored secret 212 of the device 202. The secret key refresh request and associated ciphertext is sent to the device 202 during execution of a subsequent stage of execution when communications have been established between service 204 and device 202 (e.g. second stage of execution 206b), where the device 202 stores the new ciphertext internally in memory 208. The device 202 then reboots, in which the first execution stage 206a is configured to adjust (e.g. increments/decrements or even replaces) the first device counter 214a accordingly (e.g. as described with reference to figures 1 a-2e and/or as herein described), due to the adjustment of the first device counter 214a (e.g. ordered by the epoch counter) the device 202 is configured to, for example the first stage of execution 206a may be configured to, validate each stored ciphertext, and then chooses the latest valid ciphertext. It also reports to the first stage of execution 206a 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 226, which is the same as hardware stored secret 212.

[00238] The following describes the public key mode of operation for performing a secret key refresh or updating the first stage key 272. In the example public key mode of operation for updating the first stage key 272, the hardware stored secret 212 of device 202 is assumed not known by the service 204 hosted by one or more server(s). In this case, the service 204 and device 202 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 272 on the device 202 and the service 204 hosted by one or more server(s). That is, the first stage key 272 on the device 202 and the first stage key 227 of the service 204 hosted by one or more servers are the same. In order to perform this, the device 202 is modified and configured with the following items: a) a Service Public Key 282a associated with the service 204; and b) a Service Public Key integrity protection mechanism 283, which is used to validate the signed “first stage key update package”. The Service Public Key 282a and the Service Public Key integrity protection mechanism 283 may be installed on the device 202 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. [00239] The Service Public Key integrity protection mechanism 283 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 282a; 2) a trusted location (e.g. ROM or secure non-volatile memory) configured to store a hash of the Service Public Key 282a; an HMAC of the Service Public Key computed using hardware stored secret 212 and stored next to the Service Public Key 282a. The device 202 is also configured to include a first stage key generation/update counter 284a, which may hold a current value set by the service 204 from a previous refresh of the first stage key 272. The current value of “first stage key generation/update counter” may be secured with an HMAC computed using hardware stored secret 212. The device 202 also includes a device private key 285b stored in secure non-volatile memory. The Device Private Key 285b may be encrypted or secured based on the hardware stored secret 212 of the device 202.

[00240] Although a first stage key generation/update counter 284a may be a separate counter to the device counter 214, 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 214 including one or more additional counters that implement the first stage key generation/update counter 284a, or using the first device counter 214a as the first stage key generation/update counter 284a, or using the second device counter 214b as the first stage key generation/update counter 284a, or any other mechanism or process for implementing the functionality of the first stage key generation/update counter 284a described herein.

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

[00242] The device 202 of the iterative key generation system 280 is further modified by having the hardware stored secret 212 act as a key for encrypting/decrypting the first stage key 272, the Device Private Key 285b and/or the Service Public Key 282a. The Device Private Key 285b, the Service Public Key 282a and first stage key 272 may be stored in a secure or encrypted form in non-volatile memory. For example, the Service Public Key 282a of the service 204 may be protected/encrypted on the device 202 with the hardware stored secret 212 using, by way of example only but it is not limited to, HMAC or AES-CMAC, or AEAD. The first stage key 272 may be, without limitation, for example a symmetric key.

[00243] In the public key mode, the hardware stored secret 212 is not known by the remote service 204 hosted by one or more server(s). In this case, the remote service 204 and the device 202 exchange public key exchange data that may be derived from corresponding private key exchange data. For example, the service 204 and/or server hosting the service 204 may be configured to generate a service/server private key exchange data (SPrKX data) 287a, which is used for generating a service/server public key exchange data (SPbKX data) 287c. The device 202 may be configured to generate a device private key exchange data (DPrKX data) 287b, which is used to generate a device public key exchange data (DPbKX data) 287d. 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.

[00244] The public key mode process is described as follows: In step 1 , the service 204 initiates a public key mode refresh 286 for updating the first stage key 272, which is a shared secret. In step 2, the service 204 hosted by one or more server(s) computes SPrKX data 287a. For example, the service 204 may compute the SPrKX data 287a, which is used to form the service half of the key exchange algorithm with the device 202 and is used to form the so-called SPbKX data 287c in step 2a (e.g. Service Key exchange value (SKX)). This key exchange operation may use, by way of example only but is not limited to, Elliptic-curve Diffie-Hellman (ECDH) key exchange algorithm for generating the SPbKX data 287a public service half of the key exchange algorithm with device 202 from the SPrKX data 287a. It is to be appreciated that any other key exchange algorithm may be used to generate the SPbKX data from the SPrKX data as the application demands. In step 3, the service 204 adjusts the first stage key generation counter 284b to create a new first stage key generation count. For example, the service 204 may increment and/or decrement the first stage key generation counter (FKGC) 284b. The first stage key generation counter 284b may be a monotonically increasing or a monotonically decreasing counter. [00245] In step 4, the service 204 generates a first stage key update request 288a (e.g. First Stage key update with SPbKX data and FKGC) that includes the public key exchange data derived from the SPrKX data 287a and the first key generation counter 284b. The service 204 signs and/or encrypts the first stage key update request 288a with a Service Private Key 282b. For example, the signing/encrypting of the first stage key update request 288a with Service Private Key 282b 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 288a. In step 5, the service 204 is configured to send the signed first stage key update request 288b containing the SPbKX data 287c derived from the SPrKX data 287a and the value of the first stage key generation counter 284b to the device 202. The signed first stage key update request 288b may be sent from the service 204 to the device 202 when the device 202 is executing the second execution stage 206b and/or any other subsequent execution stage that has established communication with the server hosting the service 204. In step 6, the application firmware of the second execution stage 206b (or other subsequent execution stage) may be configured to store the received signed first stage key update request 288b in a designated, agreed or common location in the memory 208 of the device 202. In step 7, the application firmware of the second execution stage 206b (or other subsequent execution stage) is configured to, on receipt and storing of the received signed first stage key update request 288b, trigger and/or instruct the device 202 to perform a reboot.

[00246] In step 8, after the device 202 reboots and the first stage of execution 206a (e.g. initial bootloader firmware) starts executing, the first stage of execution 206a is modified and configured to check the designated or agreed location for storing any newly received signed first stage key update request 288b stored in memory 208. For example, when the initial bootloader of the first execution stage 206a executes, the initial bootloader is configured to check the designated/agreed location of the signed first stage key update request 288b in memory 208 to see if there is a newly received signed first stage key update request 288b, which indicates a new shared key refresh has been requested by the service 204. The first stage of execution 206a may also validate the Service Public Key 282a as stored or received. In step 8, if the initial bootloader finds a new signed first stage key update request 288b at the agreed location in memory 208, then the new signed first stage key update request 288b may be authenticated using signature validation 289, where the device 202 may use the Service Public Key 282a for validating the newly received signed first stage key update request 288b. For example, the signature validation 289 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 288b. This may signal and/or verify to the initial bootloader of the first stage of execution 206a that the service 204 has requested a new secret key refresh.

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

[00248] If the first stage generation counter check 290a confirms the received first stage generation counter value 284b is in the future (e.g. OK), then in step 10, the first stage of execution 206a computes a DPrKX data 287b (e.g. new device secret). For example, the device 202 may compute the DPrKX data 287b, which is used to form the device/client half of the key exchange algorithm with the service 204 to form a so-called SPbKX data 287d (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 204 from the DPrKX data 287b.

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 287b is used to generate the DPbKX data, which is sent to the server hosting the service 204. In step 11 , the first stage of execution 206a of the device 202 is configured to use the new DPrKX data (e.g. new device secret) 287b and the newly received SPbKX data (e.g. SKX), which was received in the signed first stage key update request 288b, to compute a new first stage key 291 a. For example, the device 202 may use the new DPbKX data 287b and newly received SPbKX data to create a new first stage key 291 a 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 206a of the device 202 is further configured to update the first stage key generation counter 284a by replacing it with the newly received first stage key generation counter value 284b. Note, the value of the first stage key generation counter 284a on the device 202 should now be the same as the value of the first stage key generation counter 284b on the service 204 hosted by one or more server(s). [00249] In step 13, the first stage of execution 206a generates a signed first stage key update response 292, which includes data derived from the new DPbKX data 287c (e.g. CKX) and the new first stage key generation counter 284a of the device 202. The device 202 signs or encrypts the first stage key update response 292 with the Device Private Key 285b. For example, the signing/encrypting of the first stage key update response 292 with the Device Private Key 285b 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 292.

[00250] In step 14, the first stage of execution 206a on the device encrypts the new first stage key 291 a using the hardware stored secret 212 and then replaces the previous encrypted first stage key 272 with the encrypted new first stage key 291 a. Thus, the encrypted first stage key 272 has been updated on the device 202 with the encrypted new first stage key 291 a.

The first stage of execution 206a may be further configured to clean the agreed, designated and/or common location in memory 208 for storing the newly received first stage update request 288b. Additionally or alternatively, the first stage of execution 206a may be further configured to clean or remove any plaintext data related to the first stage key update request 288b and/or first stage key update response 292 from memory 208. Additionally or alternatively, the first stage of execution 206a may be further configured to remove any other plaintext data from memory 208 that is representative of the generated updated first stage key 291a, newly received SPbKX data, new DPrKX data 287b, new DPbKX data 287d and/or newly received first stage key generation counter value 284b 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 202 from being able to duplicate or generate the new updated first stage key 272. The new encrypted first stage key 272 may be made accessible to the initial bootloader of the first execution stage 206a by decrypting it using the hardware stored secret 212 prior to or during execution of the first execution stage 206a.

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

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

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

[00254] In step 18, the service 204 receives the new signed first stage key update response 292 from the device 202 during execution of the second execution stage 206b and/or any other subsequent execution stage of the device 202 as newly received signed first stage key update response 293. The service 204 is configured to check or validate the signature of the received new signed first stage key update response 293 using the Device Public Key 285a stored on the server(s) hosting the service 204. The received new signed first stage key update response 293 may be authenticated using signature validation, where the service 204 may use the Device Public Key 285a for validating/decrypting the newly received signed first stage key update response 293. 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 293. This may signal and/or verify to the service 204 that the device 202 has performed the new secret key refresh and has a new first stage key 272. The service 204 may retrieve the DPbKX data 287d (e.g. CKX), which is derived from the DPrKX data 287b, and the first key generation counter value 284a of the device 202 from the received new first stage key update response 293.

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

[00256] In step 21 , once the service 204 has generated the new first stage key 291 b, the service 204 may securely store a copy of the new first stage key 291 b by replacing the previously stored first stage key 227 of the service 204 with the new first stage key 291 b. Thus, the first stage key 227 in relation to the device 202 has been updated on the server hosting the service 204 with the new first stage key 291 b. The updated copy of the first stage key 227 may be used to validate attestation data received from device 202 including attestation codes/tags and other values as described with reference to figures 1 a-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 202 and the like and/or as described herein. The service 204 stores the new first stage key 227 for use in the iterative key generation, attestation and/or authentication protocols and the like as described with reference to figures 1 a-4, combinations thereof, modifications thereto and/or as described herein. In some examples of figures 1 a-4 and/or as described herein, the hardware stored secret 212 (or hardware stored secret 110) may be used by the first execution stage 206a (or first execution stage 106a) as the first stage key 272 (or first stage key 110a), but may be replaced with the first stage key 227 of the service 204 as described herein. The new secret key refresh (or key update) does not significantly increase the resources required on the device 202, but it enhances the security of the device 202 as new second stage keys 274 and/or subsequent stage keys and new attestation data 222a-222c may be generated based on the new first stage key 272, where it is unlikely an attacker can derive the new first stage key 272.

[00257] 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- 11 , and/or 20 may be performed by any suitable cryptograph ic/key exchange algorithm and/or the like as the application demands. Although it is described that the device 202 stores the Service Public Key 282a in non-volatile memory, which may be protected by a Service Public Key integrity protection mechanism 283, 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 202 and/or service 204 to ensure the device 202 has a trusted copy of the Service Public Key 282a and/or as the application demand. For example, the device 202 may simply securely store a trusted hash of the Service Public Key 282a in non-volatile memory and/or in integrity-protected form in memory 208, where said Service Public Key 282a is sent in the signed first stage key update request 288b and stored, by the device 202, in memory 208 or permanent storage on device 202. The trusted hash may be used to verify that the received Service Public Key 282a is valid. Alternatively or additionally, the system 280 may use, without limitation, for example, signature chaining such that the trusted copies of the Service Public Key and Device Public Keys 282a and 285a are infrequently or indirectly used. For example, in this case, the Service Private Key 282b 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 202 may retain a trusted copy of the Service Public Key 282a or just a digest of the Service Public Key 282a. This approach allows the Service Private Key 282b to be infrequently used, which is much safer. The recipient verifies the Service Public Key 282a against the stored hash if necessary, then uses the Service Public Key 282a 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.

[00258] As a further example of securely storing the Device Private Key 285b, Service Public Key 282a, and first stage key 272, the hardware stored secret 212 that is in secret storage may be used for securing NVM storage that stores the Device Private Key 285b, Service Public Key 282a, and first stage key 272. When access to the hardware stored secret 212 is, for example, turned off, then the NVM storage can no longer be decrypted. Given it is encrypted and its integrity is protected, the NVM storage storing the Device Private Key 285b, Service Public Key 282a and first stage key 272 still has the same properties as the secret storage memory storing the hardware stored secret 212. The device 202 is configured to make these only accessible to the initial bootloader of the first execution stage 206a when required. This may be achieved by using the hardware stored secret to decrypt and verify the integrity of the NVM storage storing the Device Private Key 285b, Service Public Key 282a, and first stage key 272. When the hardware stored secret 212 is turned off and on, then this turns off and on the access to the secure NVM storage and hence the access to Device Private Key 285b, Service Public Key 282a, and first stage key 272. 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 208 and/or any volatile memory RAM of device 202. 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 208 and/or volatile RAM. Although the hardware stored secret 212 may be used for securing NVM storage that stores the Device Private Key 285b, Service Public Key 282a and first stage key 272, it is to be appreciated by the skilled person that the hardware stored secret 212 may be used for simply securing the Device Private Key 285b, Service Public Key 282a and/or first stage key 272 and which may be stored in memory 208 in encrypted form. It is to be appreciated by the skilled person that any other form of secure storage of the Device Private Key 285b, Service Public Key 282a and first stage key 272 may be applied or used based on the hardware stored secret 212 and/or as the application demands.

[00259] Although the shared mode of operation process(es) and/or public key mode of operation process(es) of figure 2e has been described, by way of example only but is not limited to, with reference to figure 2e and the iterative key generation system 100 and 200 of figures 1 a-2d and/or figures 2e-4, it is to be appreciated by the skilled person that the shared or public key mode of operation as described with reference to figure 2e may be combined, modified, applied and/or used by the iterative key generation and attestation system 100 and process(es) 120 and/or 130 as described with reference to figures 1 a-1 e and/or the 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.

[00260] 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 iterative key generation and attestation systems 100, 200, 260, 280, and devices 102, 202, services 104 and/or 204, process(es) 130, 120, 240, 250 as described with reference to figures 1 a to 2e may be further combined and/or modified to include the corresponding features of the example iterative key generation and attestation process 300, where the same and/or similar features of figures 1 a-2e 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 222a of figures 2a-2e), 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.

[00261] In this example, the loT device's bootloader (e.g. bootloader of the first execution stage 206a of figures 2a-2e or first execution stage 106a of figures 1 a-1 c) has a secret (e.g. hardware stored secret 212 or first stage key 272 of figures 2a-2e or hardware stored secret 110 or first stage key 110a of figures 1 a-1 c) that it shares with the service. At boot time, the bootloader hashes the target memory sections (e.g. application firmware or second executable stage 210 of figures 2a-2e or second execution stage 106b of figures 1 a-1 c), 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.)

[00262] 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: [00263] In step 302, the device is booted, in which bootloader 0 is executed in a first execution stage (e.g. 0-th execution stage).

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

[00265] In step 306, bootloader 0 generates a fresh attestation integrity key (e.g.

Attestation K_0JJ = HKDF(MasterAttestation_i, (CohortCount, "Attestation")), where MasterAttestationJ 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. Attestation K_0JJ) 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.

[00266] 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_1JJ = HMAC(AttestationK_0_iJ, ("Attestation", NextStage_1_hash)))

[00267] 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 next stage boot loader and/or application firmware) and generates the next stage key (e.g. Attestation K_1JJ = HKDF(AttestationK_0JJ, "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.

[00268] In step 312, bootloader 0 wipes the first stage key, i.e. attestation integrity key (e.g. Attestation K_0JJ) from memory and puts the next stage key (e.g. AttestationK_1JJ) in an agreed location in memory of the device for next execution stage (e.g. BootloadeM 's perusal, or application firmware perusal and the like).

[00269] 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. BootloadeM , or application firmware perusal and the like).

[00270] 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_iJ = HMAC(AttestationK_n_iJ, ("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_1JJ,.. MAC_n_iJ]) and/or separately.

[00271] In step 318, n-th execution stage computes a (n+1 )-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. Attestation K_(n+1 )JJ = HKDF(AttestationK_n_iJ, "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.

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

[00273] In step 321 , the n-th execution stage puts/stores the (n+1 )-th stage key (e.g. AttestationK_(n+1 )JJ) 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).

[00274] 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.

[00275] 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.

[00276] 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.

[00277] 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 iterative key generation and attestation systems and/or processes as described herein with reference to figures 1 a-2e and/or as described herein.

[00278] 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+1 )-th execution stage (e.g. attestation values [MAC_1JJ,.. MAC_n+1JJ]). Instead, the generation/calculation by the n-th execution stage of the (n+1 )-th MAC (e.g. MAC_n+1JJ) in the process 300 may be further modified to include the value of the preceding MAC (e.g. MAC_n_iJ) 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+1JJ) by incorporating the n-th attestation MAC (e.g. MAC_n_iJ) into the calculation (e.g. MAC_n+1JJ = HMAC(AttestationK_n+1JJ, ('Attestation", MAC_n_iJ, 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.

[00279] Figures 3c and 3d are a flow diagram illustrating an example secret key refresh process 330 for refreshing a key, e.g. a secret, MasterAttestationJ 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 ECDFI key exchange with a service. The shared secret that is derived from this process is then used to form the shared secret such as MasterAttestationJ used by the bootloader 0 to perform FIKDF 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 is 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 service 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 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. SKX 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 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.

[00280] 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. SKX) and EpochCount data from the service. The device stores the signed new 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.

[00281] 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 KX value and EpochCount has been received. In this case, it has received a signed new service KX 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.

[00282] 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 a client key exchange value (CKX). For example, the device creates, by way of example only but is not limited to, a new client ECDH secret and derives from it an ECDH key exchange value (CKX). In step 343, the device computes a new master attestation key (MasterAttestationJ) 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 (MasterAttestationJ). 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.

[00283] 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 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) 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.

[00284] 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 key exchange value and updated EpochCount are stored and determine whether a signed new device key exchange value 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.

[00285] In step 348, the service receives the signed new device key exchange value 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).

[00286] In step 352, the service computes a new master attestation key (MasterAttestationJ) 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 the output of the key exchange algorithm 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 (MasterAttestationJ) 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 and device 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. For example, the service and/or device may use the new master key in process(es) such as, without limitation, for example process(es) 120, 130, 160, and/or 300 for generating n-th stage key(s) and using in cryptographic operations/activity for the n-th stage (e.g. attestation codes/MACs; encrypt/decrypt; authentication etc.). For example, 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 and/or one or more steps of the processes 300 and/or 330 may be further modified, combined, applied and/or used with the iterative key generation and/or attestation systems, devices, servers and/or methods/processes as described with reference to figures 1 a-3c and/or as described herein.

[00287] 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 MasterAttestationJ) 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.

[00288] 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 1 a to 2e and/or as described herein. 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.

[00289] 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 update/refresh processes (e.g. public key mode and/or shared key mode operations) as described herein, and/or with reference to figures 1 a 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.

[00290] Further modifications and/or additional features may be included into the invention as described herein with reference to figures 1 a to 3d, 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.

[00291] 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 1 a-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 and/or server(s) hosting the 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)

1 a to 3d.

[00292] 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.

[00293] 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.

[00294] 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.

[00295] 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.

[00296] 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.

[00297] 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.

[00298] 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.

[00299] 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).

[00300] 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.

[00301] 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.

[00302] 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.

[00303] 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.

[00304] 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.

[00305] Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something".

[00306] 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.

[00307] 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.

[00308] 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.

[00309] 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.

[00310] 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.