Hybrid remote attestation method supporting bulk addition and deletion of devices

Abstract

The application discloses a hybrid remote attestation method supporting batch addition and deletion of devices, and comprises the following steps: designing static batch insertion for a new Merkle tree, wherein the new Merkle tree supports dynamic addition of new nodes, and each layer has a root node; in the insertion stage, dynamic batch insertion is designed for the new Merkle tree; wherein the static batch insertion and the dynamic batch insertion both add a time stamp and a validity period in the process of calculating a leaf node of the new Merkle tree; a device uses a non-interactive zero-knowledge proof protocol to generate attestation information and submit a proxy verifier smart contract, the proxy verifier smart contract makes all verifiers believe the integrity of the measurement attribute value of the device without obtaining the measurement attribute value of the device; when the proxy verifier does not receive the attestation of the device or the attestation of the device is expired, a verifier independently interacts with a remote attestation device in an authentication mode based on HMAC, and checks the integrity of the measurement attribute value of the device.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of information security, and particularly relates to a hybrid remote attestation method supporting batch addition and deletion of devices. BACKGROUND

[0002] The current remote attestation scheme based on non-interactive zero-knowledge proof can enable multiple verifiers to verify the integrity of the device state without possessing the measurement attribute value of the device. The scheme requires the device owner to calculate the measurement attribute value of all devices and device public key information in the initialization stage, and take the calculation result as the leaf node of the Merkle tree. Through the non-interactive zero-knowledge proof protocol, it is proved that the measurement attribute value of the device is the leaf node of the Merkle tree after calculation and has the Merkle path of the node, so that the root node calculated through the Merkle tree path of the node is consistent with the root node disclosed by the device owner, and the integrity of the measurement attribute value of the device can be proved.

[0003] The foregoing scheme has the following defects:

[0004] (1) The scheme does not support adding new remote attestation devices during operation. If new remote attestation devices need to be added during operation, the device owner needs to reinitialize and reconstruct the Merkle tree for all devices, and frequent addition of devices will increase the computational burden of the device owner.

[0005] (2) Once the device is successfully added, the existing device cannot be deleted.

[0006] (3) If an attacker obtains the challenge initiated by the verifier or the measurement attribute value of the device in advance, the identity of the device can be forged. SUMMARY

[0007] In order to overcome the shortcomings of the prior art, the present application provides a hybrid remote attestation method supporting batch addition and deletion of devices, which can solve the limitation that the remote attestation scheme based on non-interactive zero-knowledge proof does not support adding new remote attestation devices. In addition, it can indirectly solve the problem that the remote attestation scheme based on non-interactive zero-knowledge proof does not support deleting devices. Finally, it can solve the defect that an attacker can forge the integrity of the measurement attribute value of the device after obtaining the challenge of the verifier or the measurement attribute value of the device in advance.

[0008] According to one aspect of the present application, a hybrid remote attestation method supporting batch addition and deletion of devices is provided, comprising:

[0009] Designing static batch insertion for a new Merkle tree, the new Merkle tree supports dynamic addition of new nodes, and each layer has a root node;

[0010] In the insertion stage, a dynamic batch insertion is designed for the new Merkel tree; wherein, the static batch insertion and the dynamic batch insertion both add a timestamp and a validity period in the process of calculating the new Merkel tree leaf node;

[0011] The device generates proof information using a non-interactive zero-knowledge proof protocol and submits the proxy verifier smart contract, and the proxy verifier smart contract makes all verifiers convinced of the integrity of the measurement attribute value of the device without obtaining the measurement attribute value of the device;

[0012] When the proxy verifier does not receive the proof of the device or the proof of the device is expired, the verifier independently interacts with the remote proof device using an authentication method based on HMAC to verify the integrity of the measurement attribute value of the device.

[0013] As a further technical solution, a static batch insertion is designed for the new Merkel tree, comprising:

[0014] Input root node array , leaf node array and variable , wherein the variable represents the number of updated root nodes;

[0015] If the length of array is equal to 0, return one-dimensional array and variable ;

[0016] Initialize a dynamic array ;

[0017] Perform a loop operation as follows:

[0018] If or , then , ; if , add to the dynamic array ; wherein represents the length of one-dimensional array , and the value range of variable is with a step of 2;

[0019] Output the updated one-dimensional array and variable .

[0020] As a further technical solution, before the static batch insertion, it further comprises:

[0021] Initialization parameters: store the leaf nodes and authorized signatures of the new Merkle tree to be batch inserted, the Merkle tree path of the batch insertion device and the label corresponding to the path, and the root node of the new Merkle tree by generating a static array, and store all the leaf nodes successfully batch added to the new Merkle tree by generating a dynamic array;

[0022] Initialize the new Merkle tree: randomly select a value, initialize the leaf nodes of the new Merkle tree, and then perform a loop operation using a collision-resistant hash function to complete the initialization of the new Merkle tree.

[0023] As a further technical solution, after the static batch insertion, it further includes:

[0024] Generating the Merkle path of the new node insertion device, the label value corresponding to the path, the hash value of the device authorization validity period, and the authorization signature of the device owner to the device.

[0025] As a further technical solution, in the insertion stage, a dynamic batch insertion is designed for the new Merkle tree, including:

[0026] Input root node array , leaf node array , variable , variable , one-dimensional array , and variable , the variable represents the number of updated root nodes, and the one-dimensional array represents the length of the dynamic array calculated as an exponential vector with base 2.

[0027] If and , return and ;

[0028] If and , return and ;

[0029] Initialize a dynamic array and a boolean variable with a value of ;

[0030] Perform a loop operation as follows:

[0031] If or , then , ;

[0032] If , then is inserted into the dynamic array ; if , , and are met simultaneously, then is inserted into the dynamic array , , ;

[0033] Output the updated one-dimensional array and variable .

[0034] As a further technical solution, before performing dynamic batch insertion on the new Merkel tree, it further includes:

[0035] Initialize parameters: store the leaf nodes and authorization signatures of the new Merkel tree to be batch inserted, the Merkel tree path of the batch insertion device, and the label corresponding to the path by generating a static array.

[0036] As a further technical solution, after performing dynamic batch insertion on the new Merkel tree, it further includes:

[0037] Generate the Merkel path of the new node insertion device, the label value corresponding to the path, the hash value of the device authorization validity period, and the authorization signature of the device owner to the device;

[0038] Update the Merkel tree path of the new node insertion device and the label value corresponding to the path.

[0039] As a further technical solution, a recommendation method is provided for the number of new devices to reduce the update of the Merkel tree path and the label corresponding to the path of all devices before the current new devices during dynamic batch insertion.

[0040] As a further technical solution, the device generates proof information using a non-interactive zero-knowledge proof protocol, including designing the following non-interactive zero-knowledge proof circuit:

[0041] Input one-dimensional array , one-dimensional array , parameter , parameter , parameter , parameter , public key , private key , one-dimensional array , and parameter ;

[0042] Computing parameters ;

[0043] Computing parameters ;

[0044] Perform the following loop operation:

[0045] If , then compute ;

[0046] If , then compute ; where the value range of variable is ;

[0047] Initialize variable with a value of 0, and then perform the following loop operation: if , set the value of variable to 1; where the value range of variable is ;

[0048] Compute parameters ;

[0049] Assert whether is true.

[0050] As a further technical solution, the method further comprises:

[0051] The device periodically calculates corresponding proof information of the measurement attribute value of the device using a non-interactive zero-knowledge proof, and submits the information to a proxy verifier smart contract;

[0052] The proxy verifier smart contract verifies the authenticity and validity of the proof information, and if both do not meet the requirements, the authentication of the device fails, and the measurement attribute value of the device is at risk of being tampered with;

[0053] The verifier inputs the public key of the device to the proxy verifier smart contract to request the status of the device, and if the feedback is that the proof is expired or empty, the verifier selects a random number as a challenge based on the HMAC authentication mode;

[0054] The verifier initiates a challenge to the device and accepts the response of the device.

[0055] The application provides a hybrid remote attestation method supporting batch addition and deletion of devices, which can solve the limitation that the remote attestation scheme based on non-interactive zero-knowledge proof does not support adding new remote attestation devices. Compared with the prior art, the application has the beneficial effects that:

[0056] (1) Firstly, a static batch insertion technology is designed for the new Merkel tree to support the system to complete initialization quickly. In the insertion stage, a dynamic batch insertion technology is designed for the new Merkel tree, thereby realizing that the system supports adding new remote attestation devices in the running process.

[0057] (2) Secondly, a recommendation method is provided for the number requirement of the added remote attestation devices, which can reduce the update times of the Merkel tree path and the label corresponding to the path of all devices before the added devices.

[0058] (3) Subsequently, a timestamp and a validity period are added in the process of calculating the leaf node of the new Merkel tree, which can ensure that the remote attestation device that is not within the authorized validity period cannot prove the integrity of the measurement attribute value of the device. Therefore, the problem that the remote attestation scheme based on non-interactive zero-knowledge proof does not support the deletion of devices is indirectly solved.

[0059] (4) In addition, trusted hardware is used to ensure the secure storage of the private key of the remote attestation device. Even if the measurement attribute value of the device is obtained by an attacker, the attacker still cannot fake the real identity information of the device to prove the integrity of the measurement attribute value of the device.

[0060] (5) Finally, a hybrid remote attestation method is provided. The device uses the non-interactive zero-knowledge proof protocol to generate attestation information and submit it to the proxy verifier smart contract. The proxy verifier smart contract can make all verifiers confident about the integrity of the measurement attribute value of the device without obtaining the measurement attribute value of the device. When the proxy verifier does not receive the attestation of the device or the attestation of the device is expired, the verifier can use the authentication based on HMAC to independently interact with the remote attestation device, thereby verifying the integrity of the measurement attribute value of the device. BRIEF DESCRIPTION OF DRAWINGS

[0061] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings used in the embodiments or prior art description will be briefly described. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0062] Figure 1 The architecture diagram of the hybrid remote attestation method for supporting batch addition and deletion of devices provided by the embodiments of the present application.

[0063] Figure 2 The module schematic diagram of the hybrid remote attestation method for supporting batch addition and deletion of devices provided by the embodiments of the present application.

[0064] Figure 3A new Merkle tree schematic diagram provided by the embodiment of the application, wherein the root of the left drawing is [3, X, Z, W], and the root of the right drawing is [7, U, Z, W].

[0065] Figure 4 A non-interactive zero-knowledge proof circuit design diagram provided by the embodiment of the application. DETAILED DESCRIPTION

[0066] To make the purpose, technical scheme and advantages of the embodiments of the application clearer, the technical scheme in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application. In addition, the technical features in each embodiment or single embodiment provided by the application can be combined with each other to form new technical schemes, and the combination is not restricted by the sequence of steps and / or structure mode, but should be based on the realization by those skilled in the art. When the combination of technical schemes contradicts each other or cannot be realized, it should be considered that the combination of technical schemes does not exist, and is not within the protection scope of the application.

[0067] The application provides a hybrid remote attestation method supporting batch addition and deletion of devices, which is used for solving the limitation that the remote attestation scheme based on non-interactive zero-knowledge proof does not support adding new remote attestation devices.

[0068] The scheme of the application includes five roles, namely a device, a device owner, a device owner, a smart contract verifier, and a proxy verifier smart contract. The scheme architecture is as shown in Figure 1 The scheme of the application includes four core modules, as shown in Figure 2 .

[0069] (I) initialization module

[0070] 1.1 Parameter initialization

[0071] (a) The device owner inputs the number of devices to be batch inserted in this stage , and generates two one-dimensional static arrays and with a size of . The lengths of the two arrays are . Store the leaf nodes of the new Merkle tree-Shrubs to be batch inserted. The storage is the authorization signature of the device owner to the batch inserted devices.

[0072] (b) The device owner inputs the number of devices that need to be bulk inserted and the number of layers of the new Merkle tree-Shrubs , two two-dimensional static arrays are generated and . The column size of the two arrays is and the row size is . and store the Merkle tree path of the bulk inserted device and the label corresponding to the path.

[0073] (c) The device owner generates a one-dimensional static array with a length of . This array stores the root nodes of the new Merkle tree-Shrubs. Then the device owner generates a one-dimensional dynamic array . This dynamic array stores all the leaf nodes that are successfully bulk added to the new Merkle tree-Shrubs.

[0074] 1.2 Initialization of the new Merkle tree-Shrubs

[0075] (a) The device owner randomly selects a value as the leaf node of the new Merkle tree-Shrubs, and sets it to . Then, the device owner performs a loop operation as follows:

[0076]

[0077] where the value of the variable ranges from , and Hash() is a secure collision-resistant hash function. The insertion method of the new Merkle tree-Shrubs is shown in Figure 3 , where the number of layers of the tree is 4. When node 4 is inserted, the root node of the new Merkle tree-Shrubs is [3, X, Z, W]. When information node 7 is inserted, the root node of the new Merkle tree-Shrubs is [7, U, Z, W].

[0078] After the construction of the traditional Merkle tree is completed, it does not support the addition of new nodes, and there is only one root node. The new Merkle tree described in the present invention supports dynamic addition of new nodes after construction, and there is a root node at each layer. The practical complexity of adding a new node at a time is O(1). The selection method of the root node of each layer is: if the number of nodes in this layer is odd, the root node is the last node. If the number of nodes in this layer is even, the root node is the second last node.

[0079] 1.3 Bulk insertion of devices

[0080] (a) The device owner performs a loop operation as follows:

[0081]

[0082]

[0083] where the variable ranges from , is the metric attribute value of the device , and are the private key and public key of the device inserted in batches, respectively, is the leaf node of the new Merkle tree-Shrubs, which is also the identity of the device on the new Merkle tree-Shrubs. Note that the metric attribute value here includes information such as memory state integrity or user space processes, kernel modules, and code segments of the kernel. But it is not limited to this.

[0084] (b) The device owner generates a variable , and the corresponding value is 0. is the number of root nodes of the current new Merkle tree that have been updated. Then, the device owner uses the static batch insertion technique , inputs , and , and outputs the updated and . The updated and will be submitted to the device owner smart contract by the device owner, and all devices, all verifiers and proxy verifier smart contracts in the blockchain can view this information through the device owner smart contract.

[0085] The algorithm description of the static batch insertion technique is as follows:

[0086] The input internal parameters are one-dimensional array , one-dimensional array and variable .

[0087] The process description is as follows:

[0088] (1) If the length of array is equal to 0, return one-dimensional array and variable .

[0089] (2) Initialize a dynamic array .

[0090] (3) Perform a loop operation as follows:

[0091] If or , then , .

[0092] If , add to the dynamic array . Here, represents the length of the one-dimensional array . The variable has a value range of with a step size of 2.

[0093] (4) Input the one-dimensional array , the one-dimensional array , and the variable , call the algorithm , and output the updated one-dimensional array variable .

[0094] (5) Return the updated one-dimensional array variable .

[0095] (c) The device owner performs a loop operation as follows:

[0096]

[0097]

[0098]

[0099] Here, the variable has a value range of , is the private key of the device owner, is the timestamp when using the static batch insertion technology, is the Merkle path of the device and the label value corresponding to the path, , takes the value 0 or 1, representing the left node or right node on the Merkle path, and have a length of , is the validity period of the device for this static batch insertion, is a digital signature algorithm, is the authorization signature of the device owner to the device .

[0100] (d) The device owner adds the identity of all devices in this successful batch insertion to the dynamic array on the new Merkle tree-Shrubs .

[0101] (II) Dynamic batch insertion module

[0102] 2.1 Parameter initialization

[0103] (a) The device owner inputs the number of devices that need to be batch inserted in this stage , and generates two one-dimensional static arrays and with a size of . The length of the two arrays is . stores the leaf nodes of the new Merkle tree-Shrubs that need to be batch inserted. is the authorization signature of the device owner to the batch inserted devices.

[0104] (b) The device owner inputs the number of devices that need to be batch inserted and the number of layers of the new Merkle tree-Shrubs , and generates two two-dimensional static arrays and . The size of the row of the two arrays is , and the size of the column is . and store the Merkle tree path of the batch inserted devices and the label corresponding to the path.

[0105] 2.3 Batch insertion of devices

[0106] (a) The device owner performs a loop operation as follows:

[0107]

[0108]

[0109] where the variable takes a value in the range of , is the metric attribute value of the dynamically batch inserted device , and are the private key and public key of the dynamically batch inserted device , are the leaf nodes of a new type of Merkle tree - Shrubs.

[0110] (b) The device owner computes a one-dimensional array where , denotes the length of the dynamic array , denotes the acquisition of a certain number of base 2 exponent vector. For example, , input then return the array .

[0111] (c) The device owner initializes 2 variables and with default value 0.

[0112] (d) The device owner judges whether it is equal to 0. If equal, the following calculations are made:

[0113] (1) Initialize a dynamic array .

[0114] (2) Add and the value of array to the dynamic array .

[0115] (3) Input array , array , variable , variable , array and variable , call dynamic bulk insertion algorithm output updated and .

[0116] If is not equal to 0, input array , array , variable , variable , array and variable , call dynamic bulk insertion algorithm output updated and . The updated and will be submitted by the device owner to the device owner smart contract, and all devices, all verifiers and proxy verifier smart contracts in the blockchain can view this information through the device owner smart contract.

[0117] Dynamic bulk insertion technology The algorithm is described as follows:

[0118] Input internal parameters: one-dimensional array , one-dimensional array , variable , variable , one-dimensional array , and variable .

[0119] The process is described as:

[0120] (1) If and , return and .

[0121] (2) If and , return and .

[0122] (3) Initialize a dynamic array and a boolean variable with value .

[0123] (4) Perform a loop operation as follows:

[0124] (4.1) If or , then , .

[0125] (4.2) If , insert into the dynamic array . If , , and are all satisfied, insert into the dynamic array , , .

[0126] (5) Input one-dimensional array , one-dimensional array , and variable , variable , one-dimensional array , and variable , call the dynamic batch insertion technique , output the updated one-dimensional array variable .

[0127] (6) Return and .

[0128] (e) The device owner performs a loop operation as follows:

[0129]

[0130]

[0131]

[0132] wherein the value range of variable is , is the timestamp when the dynamic batch insertion technique is used, is the Merkle tree path of the device obtained by the dynamic batch insertion, and the label value corresponding to the path , takes the value of 0 or 1, representing the left node or right node on the Merkle tree path, respectively, and have a length of , is the validity period of the device this time, stores the authorized signature of the device owner on the dynamic batch insertion device .

[0133] (f) The device owner performs a loop operation as follows:

[0134]

[0135] wherein the value range of variable is , is the label value update function corresponding to the Merkle tree path and the path. The device updates the Merkle tree path to . The device updates the label value corresponding to the Merkle tree path to . If the system batch-inserts new nodes, this function will be called to update all nodes before the batch-inserted nodes in the path and the label value corresponding to the path.

[0136] (g) Finally, the device owner inserts the array calculated in this stage into the dynamic array .

[0137] (h) We will provide a recommended method for the number of newly added devices to reduce the update method of the Merkle tree path and the corresponding label of all devices before the newly added device at this time when dynamically batch inserting, as follows:

[0138] Input internal parameters: and . Wherein, is the number of dynamic batch insertions, is a positive integer.

[0139] Output: .

[0140] (1) Initialize the variable with a value of . Initialize the dynamic array with a length of 0.

[0141] (2) Set the number of devices for static batch insertion to , and set the length of to .

[0142] (3) Perform a while loop when , then perform the following operations:

[0143] When , and are met at the same time, the following operations are performed:

[0144]

[0145]

[0146]

[0147] Otherwise, the following operations are performed:

[0148]

[0149] .

[0150] (4) .

[0151] (Three) Proof module

[0152] Two kinds of remote proof authentication methods are used in this phase, which are based on non-interactive zero-knowledge proof authentication method and HMAC-based authentication method. The device The system needs to periodically use non-interactive zero-knowledge proofs to calculate corresponding proof information for the device's metric attribute values ​​and submit this information to the proxy verifier smart contract. The proxy verifier smart contract verifies the authenticity and validity of this proof information; if neither is satisfied, the device... If authentication fails, the device's metric attribute values ​​are at risk of being tampered with. The proxy validator smart contract verifies the device's... The status flags are divided into 5 types: trusted, untrusted, empty, proof expired, and authorization expired (i.e., device expired). If the device owner's authorization has expired, this is considered as the device owner deleting device D). Verifier inputs device information. The public key requests the device from the proxy validator smart contract. If the feedback indicates that the certificate has expired (i.e., the device...), The submitted supporting information is valid. However, the information exceeds the capabilities of the device. The authorization's validity period) or empty (i.e., the agent validator smart contract has never received the device). (Submitted proof information); the verifier will select a random number as the challenge based on the HMAC authentication method. The verifier then presented the device. Take on the challenge and accept the equipment The response. Note: and Built into the device by the device owner middle, For the equipment owner's rights to the equipment Authorized signature.

[0153] (a) Authentication method based on non-interactive zero-knowledge proof

[0154] (1) Equipment Use functions Accept the latest Merkel tree path Tag value corresponding to the path .

[0155] (2) Equipment calculate Among them are equipment The metric attribute value, It is equipment The public key.

[0156] (3) Equipment Computational zero-knowledge proof .in, It is a non-interactive zero-knowledge proof generation function for the device. The corresponding proof is generated from the metric attribute value.

[0157] (4) Device Computing signature where, is the private key of the device, is the signature function, is the time when the signature is computed, is the selected timestamp, is the validity period of the generated proof information.

[0158] (5) Device will actively send the proof information to the proxy verifier smart contract.

[0159] (b) HMAC-based authentication method

[0160] (1) Verifier and device perform a key agreement protocol to obtain a one-time key . The execution process is as follows:

[0161] (1.1) The verifier randomly selects a secret parameter , calculates and . Where, is the public key of the verifier, is an encryption algorithm with homomorphic properties. Then, the verifier sends the parameters and to the device .

[0162] (1.2) After receiving the parameters and , the device randomly selects a secret parameter and calculates the parameters and . Then, the device sends the parameters to the verifier.

[0163] (1.3) The device computes the one-time key . Where, is the decryption function, .

[0164] (1.4) The verifier computes the one-time key . Where, is the private key of the verifier.

[0165] (2) According to the challenge initiated by the verifier , the device computes the response , where Key Derivation Function (KDF), Hash-based Message Authentication Code (HMAC).

[0166] (3) Device Computing Signature .

[0167] (4) Device Sending response information to the verifier.

[0168] (c) Non-interactive Zero-Knowledge Proof Circuit Design

[0169] Non-interactive Zero-Knowledge Proof Circuit Circuit Detailed Design, as shown in Figure 4 .

[0170] Input internal parameters: one-dimensional array , one-dimensional array , parameter , parameter , parameter , parameter , public key , private key , one-dimensional array and parameter .

[0171] The process is described as:

[0172] (1) Calculate parameter .

[0173] (2) Calculate parameter .

[0174] (3) Perform a loop operation as follows:

[0175] If , calculate .

[0176] If , calculate .

[0177] Where, the value range of variable is .

[0178] (4) Initialize variable , value is 0. Then, perform a loop operation as follows:

[0179] If , variable The value of is set to 1. The variable... The range of values ​​is .

[0180] (5) Calculation parameters .

[0181] (6) Assertion Whether it is valid or not.

[0182] (iv) Verification Module

[0183] (a) Verification method based on non-interactive zero-knowledge proof

[0184] The agent validator smart contract receives the device proof information Then, the proxy verifier will perform the following operations:

[0185] (1) Verification equipment Authenticity of the signature: .

[0186] (2) Verify the authenticity of the device owner's signature: .

[0187] (3) Validity of the verification information: .

[0188] (4) Calculation .

[0189] (5) If or The device status is then marked as untrusted. If none of the conditions are met, then check... or If the conditions are met, the device status is marked as untrusted. If none of the conditions are met, the device is inspected. The amount of supporting information exceeds that of the device owner or the device The validity period of the authorization. That is, the inspection period. or Check if the condition is met. If the condition is met, the device status is marked as untrusted. Otherwise, the device is marked as trusted. Insert into array middle.

[0190] Note: It is a signature verification function. It is a non-interactive zero-knowledge proof verification function, array Store the hash values ​​of zero-knowledge proofs and signatures submitted by all devices whose states are marked as trusted. It is the timestamp of the current verification device's certification information.

[0191] (6) The proxy verifier smart contract monitors the attestation information of the trusted status device at all times. If the device exceeds the validity period authorized by the device owner, it is marked as authorization expired. If the attestation information exceeds the validity period authorized by the device, it is marked as attestation expired.

[0192] (b) HMAC-based authentication mode

[0193] After the verifier receives the response information of the device , the following operations will be performed:

[0194] (1) The verifier inputs the public key of the device and the challenge value initiated by the verifier, and requests the device key derivation function value from the device owner smart contract.

[0195] (2) After the device owner smart contract receives the request of the verifier, it will check whether the device is within the authorization limited period. If it is within the authorization validity period, the device owner will calculate the key derivation function value of the device , and send to the verifier in a secret way. Otherwise, the verifier is fed back that the device has expired authorization.

[0196] (3) The verifier checks the validity of the device signature: .

[0197] (4) The verifier checks whether or is true. If true, the status of the device is marked as untrusted. If both are not true, check whether or is true. If both are not true, the status of the device is marked as trusted.

[0198] Note: is the timestamp when the verifier initiates the challenge to the device , and is the time period required by the verifier to respond to the device when initiating the challenge.

[0199] ​​​​​It should be noted that the above examples are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the foregoing examples, those skilled in the art should understand that the technical solutions recorded in the foregoing examples can still be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present application.

Claims

1. A hybrid remote attestation method that supports bulk addition and deletion of devices, characterized in that, Comprise: A static batch insertion is designed for the new Merkle tree, which supports dynamic addition of new nodes, and each layer has a root node; In the insertion phase, a dynamic batch insertion is designed for the new Merkle tree, comprising: input array of root nodes , array of leaf nodes , variable , variable , one-dimensional array and variable , the variable denotes the number of root nodes that have been updated, the one-dimensional array denotes the computed dynamic array length in base 2 exponent vector; If and then return and ; If and then return and ; Initialize a dynamic array and a boolean variable with value ; The following loop operation is performed: If or then , ; If , then is inserted into the dynamic array ; if , , and are all satisfied, then is inserted into the dynamic array , , ; Output updated one-dimensional array and variables ; Among them, the static batch insertion and dynamic batch insertion both add timestamps and validity periods in the process of calculating the leaf nodes of the new Merkle tree; The device generates proof information using a non-interactive zero-knowledge proof protocol and submits it to the proxy verifier smart contract, which makes all verifiers confident about the integrity of the device's measurement attribute value without obtaining the device's measurement attribute value; When the proxy verifier does not receive the device's proof or the device's proof is expired, the verifier independently interacts with the remote proof device using an HMAC-based authentication method to verify the integrity of the device's measurement attribute value.

2. The hybrid remote attestation method of claim 1, wherein, A static batch insertion is designed for the new Merkle tree, comprising: an input array of root nodes , an array of leaf nodes , and variables , the variables representing the number of root nodes that have been updated; If the length of the array is equal to 0, return the one-dimensional array and the variable ; Initializing a dynamic array ; The following loop operation is performed: If or then , ; If , then add to the dynamic array ; where represents the length of the one-dimensional array , the variable has a value range of with a step size of 2; Output updated one-dimensional array and variables .

3. The hybrid remote attestation method of claim 2, wherein, Before the static batch insertion, it also includes: Initialization parameters: generate a static array to store the leaf nodes and authorization signatures of the new Merkle tree that need to be batch inserted, the Merkle tree path of the batch insertion device and the corresponding label value, and the root node of the new Merkle tree, and generate a dynamic array to store all the leaf nodes that are successfully batch added to the new Merkle tree; Initialize the new Merkle tree: randomly select a value to initialize the leaf nodes of the new Merkle tree, and then use a collision-resistant hash function to perform a loop operation to complete the initialization of the new Merkle tree.

4. The hybrid remote attestation method of claim 2, wherein, After the static batch insertion, it also includes: Generate the Merkle path of the device for the new node that has been inserted and the corresponding label value, the hash value of the device authorization validity period, and the authorization signature of the device owner to the device.

5. The hybrid remote attestation method of claim 1, wherein, Before the dynamic batch insertion of the new Merkle tree, it also includes: Initialization parameters: generate a static array to store the leaf nodes and authorization signatures of the new Merkle tree that need to be batch inserted, and the Merkle tree path of the batch insertion device and the corresponding label.

6. The hybrid remote attestation method of claim 1, wherein, After the dynamic batch insertion of the new Merkle tree, it also includes: Generate the Merkle path of the device for the new node that has been inserted and the corresponding label value, the hash value of the device authorization validity period, and the authorization signature of the device owner to the device; Update the Merkle tree path and the corresponding label value for the new node that has been inserted.

7. The hybrid remote attestation method of claim 1, wherein, Provide a recommended method for the number of new devices to reduce the update of the Merkle tree path and the corresponding label of all devices before the current new devices during dynamic batch insertion.

8. The hybrid remote attestation method of claim 1, wherein, The device generates proof information using a non-interactive zero-knowledge proof protocol, including designing the following non-interactive zero-knowledge proof circuit: input one-dimensional array one-dimensional array parameters parameters parameters parameters public key private key one-dimensional array and parameters ; Computing parameters ; Computing parameters ; The following loop operation is performed: If then compute ; If , then calculate ; where the variable has a value range of ; Initialize variable to value 0, then perform the following loop operation: if , then set the value of variable to 1; where variable has a range of values from ; Computing parameters ; assertion whether the assertion holds.

9. The hybrid remote attestation method of claim 1, wherein, The method also includes: The device periodically uses a non-interactive zero-knowledge proof to calculate the corresponding proof information for the device's measurement attribute value and submits it to the proxy verifier smart contract; The proxy verifier smart contract verifies the authenticity and validity of the proof information, and if both are not met, the device's authentication fails, and the device's measurement attribute value is at risk of being tampered with; The verifier inputs the public key of the device to the agent verifier smart contract to request the status of the device. If the feedback is that the proof is expired or empty, the verifier selects a random number as a challenge based on the HMAC authentication method; The verifier initiates a challenge to the device and accepts the response of the device.

Images