Computer-implemented method and system

Abstract

A method and system are provided in which attestation of data on a device can be reliably provided while mitigating the risk of side channel attacks and interrupt events.

Description

Technical Field

[0001] This invention relates to a method and system. In particular, but not exclusively, this invention relates to a computer-implemented method and system. More particularly, but not exclusively, this invention relates to a computer-implemented method for providing proof of data on a device. Background Technology

[0002] Advances in quantum computing have created a need to develop technologies that enable computers to defend against attacks from quantum computers. This has accelerated the development of post-quantum cryptography (PQC).

[0003] Devices typically request proof of the data held on the device to demonstrate to entities outside the device that the information on the device is authentic.

[0004] A disadvantage is that devices are typically limited by finite resources in terms of processing capacity, storage, and memory. This conflicts with the need for more sophisticated schemes to mitigate attacks from quantum computers.

[0005] The foregoing content is taken into account in conceiving the various aspects and implementation methods. Summary of the Invention

[0006] Proof of data on the device is required from various aspects. The data on the device that constitutes the subject of the proof request may involve the device's identifier or a public key that has been provided to the device in a trusted relationship by an external entity.

[0007] From a first perspective, a computer-implemented method is provided for providing proof of data on a device. The proof provides evidence of the existence of data on the device, and specifically, evidence provided to an external party via cryptographic means, that information on the device (e.g., identity, identifier, public and private keys, serial number, configuration settings, and hash value) is authentic or as expected. The device may be a computing device. The computing device may include processing resources and secure computing resources capable of performing operations related to signature generation and data proof. The method may be implemented on the computing device. The computing device may be a mobile computing device. The computing device may be an embedded computing device configured to perform one or more tasks. The computing device may include sensors, which may be Internet of Things (IoT) devices. The data may include at least one of the following: device identifier, public and private keys, serial number associated with the device, configuration data, and hash value.

[0008] The method may include initializing a signature generation structure for generating signatures, wherein initializing the signature generation structure includes generating a first signature tree, and in response to the generation of the first signature tree, immediately generating a second signature tree. The signature tree may include multiple layers of up to a height parameter. The signature tree may include a bottommost secret key layer (which may be divided into secret key blocks), which is hashed to create a public key layer, and then the public key layer is continuously hashed to form the next layer, wherein the next layer and subsequent layers are formed by continuous hashing and concatenation of previous layers, until a signature tree of height h is reached. The number of secret keys forming the basis of the signature tree is limited by parameters that can be set by a computing device. For example, (for a signature tree of height h) it may be limited to signatures generated using 2^h secret keys. Secret keys can be used to form the basis of signatures generated by the signature tree. The number of secret keys can be set based on the height h of the tree. Each signature tree can be configured to generate the same number of signatures. Each signature tree can be configured to generate a different number of signatures.

[0009] The method may include generating a first signature tree public key. This can be done by sequential hashing and concatenation of a key layer initialized by secret blocks.

[0010] The method may further include signing the public key of the first signature tree with a signature generated using a private key associated with the device. The device private key may be based on a recovery tree, which is configured and set up similarly to the first and second signature trees.

[0011] The method may additionally include generating a second signature tree public key. This can also be generated through successive hashing and concatenation of a key layer initialized by secret blocks. The second signature tree public key differs from the first signature tree public key. Successive signature trees can be signed using signatures based on previous signature trees.

[0012] The method may further include signing the public key of the second signature tree with the private key obtained using the first signature tree. The private key may be based on a secret key block generated using random numbers as the initial layer in the first signature tree.

[0013] The method may further include receiving a request for proof of data on the device, wherein the request is received from a requesting entity. The requesting entity may be part of an external network (outside the computing device). The data may relate to the device and its state. For example, the data may be stored solely on a secure computing element on the device, or it may include data on the device itself. The request for proof is to ensure that the device is authentic, that it has not been compromised and is operating in the correct condition, and that the proof has been generated by the device or by a secure element on the device.

[0014] The method may further include obtaining the data to be proven. The data may be stored in a storage device that is part of a secure computing element on a computing device.

[0015] The method may further include using a signature generation structure to generate a signature, wherein the signature is based on one of a first signature tree or a second signature tree.

[0016] A first signature tree can be selected to generate a signature before an interruption event, and a second signature tree can be selected to generate a signature in response to the detection of an interruption event. An interruption event may be, for example, an event that includes, for example, a power outage of the computing device or a functional interruption of the device.

[0017] The method may include generating a proof by signing the data with a selected signature. The proof may be generated by hashing the data and by assigning a secret key block to a portion of the hash of the data and then generating a continuous hash or hash sequence of the secret key block. The proof may then include the hash values ​​of the concatenated secret key blocks. The proof may be based on only a portion of the data, where a portion of the data does not refer to all the data. The proof may also include a checksum.

[0018] The method may include providing proof to the requesting entity. This may include transmitting a proof that may include a hash of the data, along with a signature of the corresponding concatenation and authentication path of the hash value of the secret key block, to the requesting entity.

[0019] The method according to the first aspect enables the reliable provision of proofs, even in the event of an interruption. The proof can still be authenticated using the link between the first and second signature trees enabled by the signature of the second signature tree based on the first signature tree.

[0020] In other words, consecutive signature trees can be generated and used to support proof of data on the device. Each of the consecutive signature trees includes multiple layers, which begin with a secret key block, move upwards to the public key block associated with the secret key block, and then form consecutive layers based on the hashes of the layers below.

[0021] Optionally, a second signature tree can be generated immediately in response to the generation of the first signature tree. The technical effect of doing so is that signatures are always available, even if an interruption event occurs before the first signature tree expires.

[0022] Optionally, the device public key can be shared with external entities. This enables the establishment of trusted relationships with external entities, which may be requesting entities.

[0023] Both the first and second signature trees can be restricted to generating a finite number of signatures. The number of signatures can be based on the height parameter of the respective signature tree. The height parameter can be set to a small number so that the signature tree is not used as the basis for signature generation for an extended period. This minimizes the computational resources used for signature generation and authentication, and allows for the construction of long signature chains even using smaller signature trees.

[0024] Each private or secret key can only be used once to generate a signature. This provides protection against side-channel attacks that can be built on the use of the same private key for consecutive signature generation.

[0025] Optionally, a third signature tree can be generated after the first signature tree expires. This third signature tree can be generated immediately after the second signature tree is generated, as it is generated immediately after the resource allocation and identification of the second signature tree. A public key for the third signature tree can then be generated, and the third signature tree public key is then signed using the second signature tree. The third signature tree can then be used to generate proofs, especially in the event of an interruption during signature generation using the second signature tree.

[0026] In response to an interruption event or if the number of signatures that can be generated using a signature tree has been reached, a signature tree can then be generated continuously.

[0027] Optionally, prior to the generation of the signature generation structure, a recovery generation structure may be generated, comprising a recovery generation tree including multiple recovery private keys. In response to determining that a recovery event has occurred, the recovery generation structure can be used to generate another signature tree and an associated public key. The associated public key can then be signed using a signature generated using the recovery private key obtained from the recovery generation tree. Examples of recovery events may include data loss of the device or network; data loss associated with the corresponding signature tree; or an estimated verification time exceeding a verification threshold. The verification threshold may be a time set for the acceptable verification of the proof provided by the device. This could be a situation where the number of nodes provided as authentication paths on the signature tree exceeds a certain number. This can be determined in real time, i.e., in response to an increase in demand for network resources.

[0028] Optionally, a trust chain can be initialized between the corresponding signature tree and the proof; and the trust chain can be transmitted to the blockchain for publication, wherein the trust chain can be associated with the blockchain. The blockchain can include multiple blockchain transactions. Blockchain transactions can be verified and confirmed using consensus-based blockchain protocols. Each blockchain transaction can include data associated with the corresponding signature tree or with a device's public or private key or recovery key. The data can include hashes of data associated with the corresponding device, key, or signature tree.

[0029] Optionally, proof of the data may include determining the hash of the data.

[0030] Alternatively, a computer program product may be provided, which, when executed on a processing medium, configures the processing medium to perform the steps of the first aspect.

[0031] Various aspects may also provide a non-transitory storage medium configured to store instructions, which, when executed by appropriately configured hardware, provide the instructions to a processing medium to implement the steps of the first aspect. Attached Figure Description

[0032] The embodiments will now be described by way of example and with reference to the following figures, in which:

[0033] Figure 1 The apparatus is shown to be able to respond to a request for data verification in a manner that is appropriate for its use.

[0034] Figure 2 An apparatus configured to respond to a request for data verification is illustrated schematically according to an embodiment;

[0035] Figure 3 The signature generation structure that can be used according to the embodiments is illustrated schematically;

[0036] Figure 4 A tree structure that can be used in the method according to the embodiment is schematically shown; and

[0037] Figure 5 The flowchart illustrates the steps that can be used to generate a proof.

[0038] Figure 6 The flowchart illustrates the steps that can be used in response to a recovery event;

[0039] Figure 7 This illustrates the trust provisioning steps that can occur to establish a trusted relationship with the network;

[0040] Figure 8 This demonstrates the initialization of the blockchain corresponding to the signature tree; and

[0041] Figure 9 This shows a blockchain that can be used to verify proofs. Detailed Implementation

[0042] Now refer to Figures 1 to 3 Method 100 describes a method for providing proof of data on the device.

[0043] In step S102, the signature generation structure (T) is initialized. Initialization of the signature generation structure includes generating a first signature tree (T1), and immediately following the generation of the first signature tree, generating a second signature tree (T2). Generating T2 immediately after generating T1 generally means that once the hardware resources for T1 are allocated and identified, the hardware resources for T2 are allocated and identified immediately afterward. Similarly, as discussed below, another signature tree is generated immediately after the generation of the previous signature tree and before its use begins. That is, for example, the second signature tree T2 can be generated before the first signature tree T1 is used, so that the public key of the second signature tree can be signed using the first secret key of the first signature tree. In applications with lower security awareness, the generation of signature tree T2 may follow the generation of signature tree T1 over a longer period; that is, the generation of T2 may not be immediate, as it may occur seconds or minutes after the hardware resources for T1 are allocated and identified, rather than immediately following the allocation and identification of the resources corresponding to the previous signature tree. The signature generation structure T is initialized using the secure element 202 on the computing device 200, because the secure element 202 allocates hardware resources to the signature trees T1 and T2. (See reference...) Figure 4 Describe the structure of the first signature tree (T1) and the second signature tree (T2).

[0044] In step S104, a first signature tree public key (PubK_T1) is generated for the first signature tree (T1). See below for reference. Figure 4 This is described in which the public key of the first signature tree is generated by continuous hashing and concatenation to form the root of the first signature tree T1.

[0045] In step S106, the first signature tree public key (PubK_T1) is signed using a cryptographic signature generated using the private key (PriK_Dev) corresponding to the computing device 200. This private key may be referred to below. Figure 6 The described recovery tree R obtains the private key. This private key can also be a different private key set by the manufacturer during the manufacture of the device. As described later, the device private key (PriK_Dev) can be used to establish a trusted relationship between the computing device 200 and the network.

[0046] In step S108, a public key (PubK_T2) is generated for the second signature tree (T2). See below for reference. Figure 4 This is described in which the public key for the second signature tree is generated through continuous hashing and concatenation to form the root of the second signature tree T2.

[0047] Then, the public key of the second signature tree (PubK_T2) is signed using the signature generated with the next available private key from T1. This is step S110. This ensures that the next signature tree can always be signed during an interruption event (described below), and that the same private key is not required to generate the signature during the proof process. This protects the signature generation process from side-channel leakage.

[0048] Computing device 200 is configured to receive requests for proof of data on the device from an external entity. An example entity could be network entity 210, which could be another computing device configured to issue a proof request to computing device 200. If computing device 200 wants to communicate with a network using network entity 210 and is requested to prove that the device is not a malicious actor, then computing device 200 can receive the request for proof. In one example, this could be a situation where the device is an Internet of Things (IoT) device wishing to communicate with the network and the network needs to prove, in the form of data proof, that the device is genuine and not a malicious actor. In step S112, the request for proof is received at communication interface 204 of computing device 200.

[0049] A request for proof may include a data item to be proven by computing device 200 in response to the request. Examples of such data items may include information stored on the device, such as a device identifier, serial number, public key (e.g., a device public key or a public key already shared with the device), configuration settings, a value of a status register, or a hash value corresponding to a hash of a code segment running on the device. A data item may also be an alphanumeric sequence, such as a name or other identifier. A request for proof may be “empty”, as the request may be directed only to the proof of data existing in the secure element 202 on computing device 200. In this case, empty data may be represented by a nominal identifier such as “zero” or the word “empty”.

[0050] For example, the proof may involve the functionality of computing device 200, which enables computing device 200 to verify, via cryptographic means, to an external party (e.g., external network entity 210) that information on the device (e.g., identity and identifiers, public and private keys, serial numbers, configuration settings, and hash values) is authentic or as expected. The proof may also extend to information sources connected to secure devices (e.g., host controllers, bootloaders, peripheral devices) via trusted, protected connections.

[0051] The data items generally relate to the device and its state (i.e., whether the device is functioning as intended and has not been compromised). Data items may be data stored solely on the secure element 202, or they may include data on the host computing device 200. The proof provides assurance that the device is genuine and has not been compromised by, for example, malicious parties or malware, and that the signature in the proof has been generated by the secure element 202. The data (which is the subject of the proof request) may include a device identifier or the secure element 202 and / or the computing device 200. Data may also include hashes of computer program code running on the device, status register values, or other data placed on the device during manufacturing or trust provisioning. The data used may be determined by the user or the manufacturer.

[0052] When a request is received at communication interface 204, the request is processed to determine which data item will be proved. This enables computing device 200 to obtain and determine which data item will be the subject of the proof. This is step S114.

[0053] The processing of this request determines which device identifier and device content (i.e., which data item, such as a public key, is to be proven as a result of receiving the request). The request can then be provided to the secure element 202 to provide the proof. The signature generation structure T and the process of following it to generate the proof will now be described.

[0054] In step S116, the secure element 202 begins the signature generation process using a signature generation structure comprising multiple signature generation trees, and will now refer to... Figure 3 and 4 The signature tree shown is used to describe the signature tree.

[0055] exist Figure 3 The diagram illustrates the relationship between multiple signature trees (T1, T2, and T3) and the recovery tree R. The recovery tree R will be described later.

[0056] Each of T1, T2, and T3 is a hash-based signature tree structure, which is an example of a signature tree structure that can be used to generate signatures as part of method 100. Figure 4 The diagram provides a schematic representation of this hash-based signature tree structure. Each of T1, T2, and T3 is constructed similarly and will be referenced later. Signature generation using T1, T2, and T3 follows the same series of steps, starting with different secret key values.

[0057] The following discussion focuses on restoring the signature generation functionality after a recovery event, specifically the recovery tree R and the first recovery signature tree T'1.

[0058] The bottom layer of the signature tree structure consists of multiple secret key blocks sk[i,j], each paired with its corresponding public key. A secret key block is a block of the secret key wots_sk[i] (which can also be called the private key). That is, each signature tree structure has 2^h secret keys.

[0059] Regarding the correspondence between secret key blocks and public keys, secret key block sk[0,0] is paired with public key pk[0,0], secret key block sk[0,1] is paired with public key pk[0,1], and so on. A suitable random number generator is used to generate the secret key blocks; this generator is recommended for, for example, Leighton-Micali signatures (LMS) or extended Merkle signature schemes for signature tree structures (as suggested in standard NIST-SP 800-208). Secret key blocks are combined to form a one-time signature secret key, i.e., wots_sk[0] is formed by combining sk[0,0], sk[0,1], ..., sk[0,L-1], where L = len, as mentioned in the figure. This combination of secret key blocks used to form the one-time signature secret key can be formed, for example, by concatenating the values ​​of sk[i,j]. The one-time signature secret key can be described as a private key.

[0060] A public key corresponding to the secret key block is generated by hashing the corresponding secret key block w-1 times. The parameter w can be set by specifying a trusted relationship with the manufacturer of network entity 210, secure element 202, or computing device 200. An example hash function can be SHA256. Other example hash functions can be SHA256 / 192, SHAKE256 / 256, or SHAKE256 / 192. The secret key block sk[i,j] is hashed to create the corresponding public key pk[i,j], enabling the formation of a cryptographic pair between the secret key block and the corresponding compressed public key.

[0061] For example, the compressed public key at node [0] is then formed by hashing the concatenation of each of pk[0,0]…pk[0,L-1] (e.g., H(pk[0,0]||pk[0,1]||…||pk[0,L-1])), i.e., pk[0] = node [0], where H() is the corresponding hash function. This is consistent with what is described in the guide to NIST SP 800-208.

[0062] Then, the compressed public key for the corresponding node in the 2^h nodes is formed by concatenating the corresponding nodes in pk[i,j], where i is in the range of 0 to 2^h-1 and j is in the range of 0 to L-1. That is, the compressed public key for node [2^h-1] is formed by H(pk[2^h-1,0]||pk[2^h-1,1]||…||pk[2^h-1,L-1]), where x||y represents the concatenation of x and y. In other words, the compressed public key corresponding to node [2^h-1] is formed by obtaining the hash of the concatenation of pk[2^h-1,0], [2^h-1,1], …, pk[2^h-1,L-1].

[0063] The signature tree public key is moved up to the second-level compressed public key, pk2[k], where k ranges from zero to h. This is formed by the concatenated hash of the keys at the previous layer (i.e., pk[0] (= node [0]) and pk[1] (= node [1])), and the final node pk2[2^(h-1)] is formed by the concatenated hash of pk[2^h-2] and pk[2^h-1]. Then, the public key at node [1], pk[1], can form part of the authentication path for any signature generated using wots_sk[0], and this is the same for subsequent layers of the signature tree. Other nodes on the authentication path will be... Figure 4 As shown in the diagram. Then, the signature provided in the proof can be verified using the public keys at these nodes (i.e., the public keys formed by hashing the nodes at the previous layer, as previously shown) based on which wots_sk was being used as the basis for the signature at that time.

[0064] Finally, in order to form the public key corresponding to the signature tree, the public key at the penultimate level (which is formed by hashing the concatenation of hash values ​​from the previous levels) is concatenated and then hashed to form the root node, which is equal to the public key of the corresponding signature tree.

[0065] The intermediate layer is similarly formed by hashing the concatenation of keys that form the previous layer.

[0066] In other words, PubK_T1, the public key of the first signature tree, is formed as follows: Figure 4 The root node of the signature tree described in [reference]. That is, starting from the secret key block sk[i,j], through [reference]... Figure 4 The described sequential hashing and concatenation are used to form the public key until a tree of height h is reached. Height h can be specified by the manufacturer of the secure element 202 or the computing device 200. Similarly, PubK_T2 is formed by sequential concatenation and hashing starting from the secret key block sk[i,j] and reaching a tree of height h. Similarly, the signature tree public key corresponding to the subsequent signature tree is formed.

[0067] refer to Figure 1 as well as Figure 3 and 4 Following the generation of T1, a second signature tree T2 is generated, and as described above, a second signature tree T2 is also generated, and T2 is formed similarly to T1. These signature trees are detailed above. Figure 4 The way the description is constructed and generated.

[0068] Then, using the current private key of T1, i.e., the currently used private key, the public key of the second signature tree (PubK_T2) is signed. To generate a signature on PubK_T2 (i.e., where PubK_T2 is L), PubK_T2 is first divided into blocks, for example, by truncating L equal-sized segments to identify PubK_T2. In a simple example, if PubK_T2 is 213456798696 and L equals 3, then the first data block could be 2134, the second data block could be 5679, and the third data block could be 8696. It should be emphasized that L = 3 is merely an illustrative example. L can be any positive integer greater than 2. For example, L could be 67 or 133 or even higher.

[0069] Secondly, identify the next available secret key from T1. If this is done at the beginning of using the signature generation structure T, it is likely that the next available secret key will be wots_sk[0], which is divided into secret key blocks sk[0,0], sk[0,1], and sk[0,2 (i.e., L-1)]. If the next available secret key is needed, since wots_sk[0] has already been used to generate the signature, then the block corresponding to wots_sk[1], i.e., sk[1,0], sk[1,1], and sk[1,2] (when L=3), will be used.

[0070] The generation of the corresponding public key pk[i,j] was described above. Regarding the signature, each secret key block is combined with its corresponding data block (i.e., the corresponding block of PubK_T2) to form the input, which forms the basis for determining the signature block. For the first data block, i.e., 2134, the secret key block sk[0,0] is hashed 2134 times. For the second data block, i.e., 5679, the secret key block sk[0,1] is hashed 5679 times. For the third data block, the secret key block sk[0,2] is hashed 8696 times. The corresponding hashes of the secret key blocks (i.e., the 2134th, 5679th, and 8696th order hashes) can then be concatenated and hashed to form a signature of the public key PubK_T2 of the second signature tree. That is, the public key of the second signature tree is now signed. The signature can then be stored in the local storage device of the secure computing element 202.

[0071] Since wots_sk[0] has already been used, it cannot be used again. The next available secret key will be wots_sk[1], which will be divided into blocks to be used as the basis for signature generation (and subsequent proof generation).

[0072] The importance of immediately generating T2 and the signature on the public key of the second signature tree will be described below in the context of the interruption event.

[0073] The returned reference signature generation structure is used to generate proofs for data items; now refer to... Figure 5 Describe how to generate a proof for such data items. This will be in response to the request received in step S112.

[0074] In step S500, the data is hashed (using, for example, one of SHA256, SHA256 / 192, SHAKE256 / 256, or SHAKE256 / 192), and then the data is divided into L (=len) equal-sized blocks. That is, the data is hashed to generate a numerical representation of the data. Then, the numerical representation is divided into L equal-sized blocks.

[0075] Optionally or otherwise, not all data may need to form the basis of proof. In this case, only a portion of the data may be separated and hashed, and subsequent steps may only be applied to the corresponding hash.

[0076] In the example above where PubK_T2 is signed, L equals 3, but as explained above, it can be any integer greater than 2. If the data item to be proven is deemed too large for the proof to be computationally verifiable, it can be truncated to extract the first T bytes before it is hashed and divided into L blocks. Optionally or additionally, if the data item to be proven is deemed too large (i.e., it exceeds a specified threshold in terms of the size or number of alphanumeric characters), the hashing step can be to hash the data into a value that can be stored using T bytes before subsequent operations.

[0077] Data items may correspond, for example, to a third-party public key stored on the device, which may be a very large number on the order of 10^20 to 10^30.

[0078] We will continue from the point where wots_sk[0] has been used and is therefore no longer available. Therefore, the secret key wots_sk[1] will be used as the basis for signature generation.

[0079] In step S502, each of the secret key blocks corresponding to wots_sk[1], i.e. sk[1,0], sk[1,1]...sk[1,L-1], etc., is assigned to the corresponding block of the data hash (or the corresponding block of the data hash in truncated form). In step S504, the data hash may be stored in the local storage device of the secure element 202. However, this is entirely optional and can be specified by the user of the computing device 200 or the manufacturer or user of the secure element 202.

[0080] In step S506, a signature block is then generated by hashing the corresponding secret key block a number of times corresponding to the hash of the data. For example, if the hash of the data is 12345, then the corresponding secret key block is hashed 12345 times. This is implemented using a hash algorithm, such as one of SHA256, SHA256 / 192, SHAKE256 / 256, or SHAKE256 / 192.

[0081] Optionally, only a portion of the data can be the body of the proof. If this is the case, only that portion of the data will form the basis of the signature, and only the block corresponding to that portion of the data will be generated.

[0082] The corresponding hashes of the secret key block—those formed by performing a series of hashes on the secret key block corresponding to the number of times the hashed block value is applied—correspond to the signature blocks, which are then concatenated and hashed to form a proof. This can also be described as a concatenation of corresponding nodes on a signature tree. This forms the proof of the data.

[0083] This is step S508. Return to reference. Figure 1 In step S118, a data proof, along with a hash of the data that serves as the proof subject, is provided to the requesting entity. The data proof provided to the requesting entity includes the proven data and a cascading signature. The manufacturer of the device or the implementer of a system in which device 200 is part may choose to include additional data that may be relevant to a specific use case. For example, a checksum may be included in the proof provided to the requesting entity. The checksum may involve a specific value calculated according to the SP 800-208 standard.

[0084] As seen above, each secret key can only be used once to form a signature. When all secret keys in the signature tree are exhausted, another signature tree, such as T2, is needed. As mentioned above, when generating T2, the public key (PubK_T2) of T2 is signed using the current secret key of T1, i.e., the secret key formed by the next available secret key (wots_sk). This means that the first and subsequent proofs generated using the signature tree are generated forward using sk[1,0]…sk[1,L-1] until sk[2^h-1,0]…sk[2^h-1,L-1] are exhausted. When sk[2^h-1,0]…sk[2^h-1,L-1] (from T1) are exhausted, T2 is used to implement the signature generation that forms the basis of the proof (e.g., Figure 5 (As described in [the document]). Alternatively, or optionally, if an interruption event is identified, T2 is used to generate the proof. This is described in more detail below.

[0085] Therefore, parameter h provides a numerical limit on the number of messages that can be proven using, for example, a signature tree of T1 or T2. That is, including signatures with respect to PubK_T2, the signature tree can only be used to prove data until the secret key is exhausted; that is, if a secret key used to sign the public key of the next tree has already been signed, then 2^h-1 proofs are generated. This means that the signature tree can be kept to a reasonable size, which does not consume excessive computational resources during the signature generation of proofs, for example (described below). Parameter h can be specified by the manufacturer or user of computing device 200 or secure element 202.

[0086] In the event of an interruption (which may also be described as a tearing event) or when the maximum number of secret keys in T1 is used up, i.e., when the maximum number of signatures have been generated, a second signature tree T2 is then used to generate a signature for use in response to the request to form a proof according to step S112.

[0087] Example interruption events include power outages or loss of data connection. Other example events could be message loss during communication with external entities. Each of these events could be caused by, for example, a malicious actor viewing access to computing device 200 by examining secure content (e.g., public keys and other secure content that can be used in the proof process). For this reason, the use of private keys is intended to be restricted, especially when hardware resources are limited and resources such as protected hash accelerators are unavailable.

[0088] By enabling secure element 202 to switch from T1 to T2 to generate a signature as part of the proof process, secure element 202 avoids reusing the last (or more) secret keys used. Without a switch from T1 to T2 (and the immediate generation of T2), if the signing process is interrupted by an event, the signature may run out before the public key of T2 can be signed using the secret key obtained from T1. This would compromise the trust relationship between the external entity and the device with which the trust relationship exists. In other words, the signature generation process would be disrupted.

[0089] This remedies the breach in the signature generation mechanism when signing PubK_T2 with the secret key from T1.

[0090] PubK_T2 can be distinguished from other content signed with the same key. A controlled tag length value structure or similar structure can be used to separate arbitrary content blocks from public key blocks.

[0091] If the signing process (using T1) is interrupted by the loss of at least part of the signature, it cannot be restarted with the same private key. Therefore, the next private key (from T1) is used to restart the signing process used when generating the proof.

[0092] When using T2 and receiving a request for proof, Figure 5 The process detailed in the document is used in conjunction with the secret key (and secret key block) from T2 to generate proof.

[0093] In other words, in response to an interruption event, the second signature tree T2 is used instead of the first signature tree T1 to generate the proof.

[0094] When generating the second signature tree T2 as described above, the third signature tree T3 can be generated immediately, and the third signature tree T3 is consistent with... Figure 4 The signature tree shown is constructed similarly. That is, a random number generator is used to generate the secret key, and continuous hashing and concatenation are used to establish the root node (public key) for generating the third signature tree T3. This is exemplified as PubK_T3. Then, the public key of the third signature tree T3 is signed using the current secret key from T2, and the public key of the third signature tree T3 can be shared with computing device 200 and also with network entity 210. Subsequently, if an interruption event is subsequently determined, T3 can be used to generate a proof.

[0095] Similarly, the sizes of T2 and T3 are determined by the parameter h, which limits the number of proofs that can be generated using any particular signature tree. The parameter h can be a small number, such as 2, 3, 4, 5, or 6. It can also be a large number, such as greater than 6. This means that smaller signature trees that are easier to store and do not require long verification paths, which are computationally expensive and in some cases infeasible, can be implemented.

[0096] In generation Figure 3 When using the signature generation structure shown (recovery trees R and T'1 will be described later), a smaller signature generation tree can be implemented while providing long (almost infinite) signatures. Figure 3 The diagram illustrates a signature generation structure, where, for example, T1 (signed using T2's public key) endorses signature tree T2, and T2 in turn endorses T3. This continuity in the signature generation structure also helps the secure element 202 avoid denial-of-service in the event of an interruption. This also means that long signatures can be used while maintaining a reasonably, computationally feasible signature tree size, because new trees can be generated and endorsed at any time.

[0097] Subsequently, when generating T3, a fourth signature generation structure T4 can be generated in a similar manner to continue the signature generation structure, thereby further demonstrating the resilience of the signature generation structure against interruption events.

[0098] When a secret key is used only once to generate a signature for proof of data, the secure element 202 and (by extension) the computing device 200 are enhanced to resist side-channel attacks. For example, in the case of LMS-based signature generation, each secret key is used at most twice. This includes the generation of the public key and during the signature generation process (whether signing the public key of another tree or generating proof). This is enforced by a usage counter stored in non-volatile memory (NVM) in the secure element 202, which increments when any particular secret key is used. When the usage counter equals 2, the secret key is not used again (e.g., wots_sk[0]), and the next secret key is used (e.g., wots_sk[1]), and this continues until wots_sk[2^h-1] is used, which is when the signature generation process switches to the next signature tree, i.e., T1 switches to T2 regardless of whether there is an interruption event, and then T2 switches to T3 when the number of secret keys in the usage counter T2 is exhausted.

[0099] One-time signature (OTS) public keys, which are formed by hashing and concatenating secret key blocks in a signature tree as described above, can be stored or cached to enable the computation of authentication paths. This will be described later. The storage of such public keys can be transferred to an external entity.

[0100] Additionally, when generating a signature in the manner described, it is possible to interleave the signature generation step with other operations or interrupt it with other operations. When using the parameter w to control signature generation, the signature length, which is in bytes, can be maintained at kilobytes. Signatures are typically never stored on the device, but they can be stored on the device. Because it is not necessary to store the signature on the computing device 200, proofs can be provided in smaller blocks (i.e., the size of a single hash output).

[0101] In practice, signature generation may need to be interleaved with other operations. This is because the time spent generating a proof can be on the order of tens of seconds or even tens of minutes. The latency caused by such interruptions is determined by calculating the hash chain used to generate the signature. This could potentially prolong exposure to interruption events (or tearing events), but the aforementioned characteristics make it possible to mitigate the impact of such interruptions.

[0102] Optionally or additionally, the recovery tree R can be used to generate the availability of signatures that form the basis of proofs. This makes it possible to obtain the secret key even if one or more complete public tree blocks (i.e., pk[0,0], pk[0,1], ..., pk[0,L-1]) are permanently lost, thereby preventing the verification of the proof signature from taking too long to enable verification due to the number of public tree blocks involved in the authentication path.

[0103] As explained below, the public key can be associated with the recovery tree R (as the recovery tree public key), and this can be used during trust pre-configuration with external network entity 210. The recovery tree public key can be shared with the outside world during the initial trust pre-configuration step or even during manufacturing, and can be used to formulate signatures about the blockchain, which enables the verification of proof operations from computing device 200.

[0104] In step S600, when the first signature tree T1 is generated, a recovery tree R is also generated. The recovery tree R is constructed similarly to T1, i.e., a secret key layer is randomly generated, and the secret key layer can be continuously hashed and concatenated to form a recovery tree public key at the root of the recovery tree R. Moreover, similar to T1, the parameter h is used to limit the number of signatures that can be generated by the recovery tree. The parameter h used for the recovery tree R may be different from the parameter h used in signature trees T1, T2, T3, and T4. When PubK_T2 is signed based on T1, the next available private key of T1 (e.g., wots_sk[1] formed by the combination of blocks sk[1,0], ..., sk[1,L-1]) can be used to sign the recovery tree public key using the same procedure described above. The first available private key for T1, namely wots_sk[0], which is formed by the combination of blocks (and secret keys) sk[0,0], ..., sk[0,L-1], will be used to sign PubK_T2 when generating T2.

[0105] When the first signature tree T1 is generated (see above), the next available private key from R can be used to sign PubK_T1. This creates an authentication path between R and T1 (and subsequent signature trees such as T2, T3, etc.).

[0106] If one or more public keys from the active signature tree are unavailable, i.e., if any block of the public key in T1 is permanently lost (i.e., the security element 202 fails to access the necessary blocks to form an authentication path) or if the verification path is too long, i.e., if the size of the tree makes the authentication proved at verification computationally infeasible, then the recovery tree R can be used to generate a signature to be used as the basis for the proof (as follows). This is step S602.

[0107] Upon determining the recovery event, another signature tree T'1 is generated in a manner similar to T1, i.e., secret key blocks sk[0,0], ..., sk[0,L-1], ..., sk[2^h-1,0], ..., sk[2^h-1,L-1] are generated and used as the basis, followed by continuous hashing and concatenation (as described in NIST SP 800-208) to form PubK_T'1 as the root of signature tree T'1 (and the public key of signature tree T'1). PubK_T'1 is then signed using the next available private key of recovery tree R (i.e., the next available combination of secret keys such as sk[j,0], sk[j,1], ..., sk[j,L-1], etc.). The signature of PubK_T'1 is then shared with computing device 200 as a combination of PubK_T'1. PubK_T'1 can then be shared with external entities such as network entity 210.

[0108] Then, in response to an activity's request for proof or a subsequent request for proof, a signature for forming the proof is generated using the signature tree T'1.

[0109] Whether the request for proof is from an existing event (i.e., received before the recovery event) or received after the recovery event, the process of generating proof follows the same principle. Figure 5 The steps described in [the document] are as follows. Similarly, if only the data block needs proof, then only the block can be provided. This is step S604.

[0110] Then the signature tree T'1 is used similarly until an interruption event occurs or the number of secret keys is exhausted (similarly based on a usage counter used to regulate the usage of secret keys from T1, T2, etc.).

[0111] When generating T'1, another signature tree (T'2) can be generated similarly, and the public key (PubK_T'2) of the other signature tree can be signed using the next available secret key of T'1.

[0112] In the next recovery event, R is used again to generate the signature tree, and steps S600 to S606 are repeated. Then, the public key of the newly generated signature tree is signed using the next available secret key from the recovery tree R. The signature is then shared with computing device 200 using the newly generated signature tree public key. The newly generated signature tree public key can then be shared with external entities, such as network entity 210, which have a trusted relationship with computing device 200.

[0113] The recovery tree R can only be used to generate a limited number of additional signature trees. That is, although the recovery tree R is constructed similarly to the signature trees T1, T2, etc., it may have a parameter h, which is set to a lower value than the equivalent parameter of T1, T2, so that the recovery tree R can only be used to sign a relatively small number of recovery trees.

[0114] The recovery tree public key is shared with network entities outside of computing device 200 to establish a trusted relationship, for example, between computing device and network entity 210. This is implemented by obtaining the recovery tree public key from secure element 202. Optionally, the manufacturer of the device or the manufacturer of the secure element may generate the recovery public key during the appropriate manufacturing stage and extend the trusted relationship to third parties by generating certificates based on the recovery public key.

[0115] Prior to the commencement of method 100, a trust pre-configuration procedure may be completed, which generates an initial root of trust between computing device 200 and an external network entity that can seek the proofs described above. This references... Figure 7 To describe.

[0116] In order to generate a root of trust between computing device 200 and external network entity 210, computing device 200 obtains the device public key from secure element 202. This is step S700.

[0117] The device public key is then transmitted to network entity 210. This is step S702.

[0118] Network entities may additionally use the device's public key to sign the certificate to extend the trusted relationship to other entities. This is step S704.

[0119] Steps S700 to S704 can be performed in step S100 (see...) Figure 1 This is executed before, and therefore before, the signature tree T1 is established. This makes it possible to establish a chain of trust between the manufacturer of the device (or secure element) at the first end and the signature tree T1 at the root end, with the device's public key between them.

[0120] After the signature tree T2 is established, it will be added to the end of the trust chain, i.e., the trust chain will be device key -> T1 -> T2.

[0121] In other words, a trusted relationship can be established between computing device 200 and network entity 210 before the signature tree is built. This trusted relationship can be established through a shared public key. Network entity 210 can be the source of requests for data verification.

[0122] For each signature tree, a blockchain transaction can be initialized to enable verification of proofs generated using the signature tree. This is in Figure 8 As described in the text.

[0123] In step S800, the master node of the blockchain network initializes the public blockchain and issues requests for certificates from network entities. Other ledger structures may be used. The certificate contains a device identifier for computing device 200. This identifier is also included in any proof requests from network entity 210 to the computing device. The blockchain in Figure 9 As shown in the diagram. The device identifier can be a key provided by the manufacturer of the computing device 200.

[0124] A transaction (Tx1) is initiated to obtain a certificate and store it on the blockchain. A subsequent transaction (Tx2) corresponding to the recovery tree can then be established, which signs the output of the certificate transaction (Tx1) using the public key of the recovery tree. A transaction (Tx3) corresponding to the entire tree structure T (i.e., T1, T2, T3, etc.) can then be initialized, which can be done by signing Tx2 using the device's public key.

[0125] A subsequent transaction (Tx4) corresponding to the first signature tree T1 can be initialized, which signs the output of Tx3 using PubK_T1. Then, a subsequent transaction (Tx5) corresponding to the second signature tree T2 can be initialized, which signs the output of Tx4 using PubK_T2. Subsequent transactions are then initialized as needed. Each transaction may include a hash of the corresponding public key. A transaction corresponding to the proof can then be initialized and added to the end of the blockchain. This transaction signs the most recent signature tree transaction or the output of the signature tree used to generate the signature for the transaction. The transaction corresponding to the proof then makes the proof verifiable because each transaction includes a hash of each public key and a timestamp of the transaction. This allows any validator to verify the proof using a trust chain supported by the blockchain structure.

[0126] Each signature tree transaction can have a number of outputs equal to the number of signatures that can be generated using that signature tree.

[0127] In a blockchain with unused transaction outputs (UTXO), the initialization of a transaction may include hashing a certificate or public key and including the hash as metadata in the unusable output.

[0128] In step S802, a proof is received from network entity 210 and can be verified using the blockchain initialized in step S800. The proof may also include an authentication path comprising hashes corresponding to nodes on the appropriate signature tree used to generate the proof.

[0129] Because each proof is then included in the corresponding transaction. This forms a chain between the certificates and proofs obtained from the device. This allows the proof sequence and proof tree sequence (e.g., T1, T2, T3, ...) to be verified by the verifier.

[0130] Authentication path in Figure 4 As shown in [the diagram]. The corresponding hashes on the authentication path can be used for authentication proofs because they can be used to authenticate the hash values ​​at each level of the corresponding signature tree. This is also shown in SP 800-208.

[0131] In summary, a secure proof scheme based on hash-based signature generation is described, which addresses the challenges of devices constrained by computational power, working memory, code memory, event processing latency requirements, security requirements (i.e., resistance to side-channel attacks and fault injection), and limited non-volatile memory.

[0132] It should be noted that the aspects and embodiments mentioned above illustrate this disclosure but do not limit it, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals placed in parentheses in the claims should not be construed as limiting the claims. The words “comprising” and “comprises” do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, “comprises” means “includes” or “consists of”, and “comprising” means “including” or “consisting of”. A singular reference to an element does not exclude a plural reference to such an element, and vice versa. This disclosure can be implemented by means of hardware comprising several disparate elements and by means of a suitably programmed computer. In an apparatus claim listing several components, several of these components may be embodied by the same object in the hardware. The fact that certain measures are described in different subsidiary claims alone does not mean that a combination of these measures cannot be used to gain an advantage.

Claims

1. A computer-implemented method of providing attestation of on-device data, the method comprising: The method comprises: initializing a signature generation structure for generating a signature, wherein initializing the signature generation structure comprises: generating a first signature tree, and in response to generation of the first signature tree, immediately generating a second signature tree; generating a first signature tree public key; signing the first signature tree public key with a signature generated using a private key associated with the device; generating a second signature tree public key; signing the second signature tree public key with a private key generated using the first signature tree; receiving a request for an attestation of data on a device, wherein the request is received from a requesting entity; obtaining data to be attested; generating a signature using the signature generation structure, wherein the signature is based on one of the first signature tree or the second signature tree; wherein the first signature tree is selected to generate the signature prior to an interruption event, and the second signature tree is selected to generate the signature in response to detecting an interruption event, and generating the attestation by signing the data with the selected signature; and providing the attestation to the requesting entity.

2. The method of claim 1, wherein, The second signature tree is generated immediately in response to generation of the first signature tree.

3. The method of claim 2, wherein, The generation of the second signature tree is initialized when resource allocation to the first signature tree has been completed.

4. The method of claim 1, wherein, A device public key is shared with an external entity.

5. The method of claim 4, wherein, The device public key is associated with a recovery tree structure.

6. The method of claim 1, wherein, The respective signature tree public keys are formed based on successive generation and concatenation of public keys based on a secret key.

7. The method of claim 6, wherein, The secret key is based on a randomly generated value.

8. The method of claim 7, wherein, Generation of the randomly generated value is based on SHA256.

9. A computer program product, characterised in that, The processing medium, when executing the instructions, is configured to implement the steps of claim 1.

10. A non-transitory storage medium configured to store instructions, the instructions comprising: The instructions, when executed by the appropriately configured hardware, provide for implementing the steps of claim 1.

Images