Dynamic key derivation method for bidirectional authentication between Internet of Things equipment and cloud

Abstract

The invention relates to the technical field of Internet of Things security, in particular to an Internet of Things equipment and cloud bidirectional authentication dynamic key derivation method, which comprises the following steps of: distributing a unique identity label, an initial key and an equipment serial number for equipment, and encrypting and storing the initial key; the device obtains a current timestamp, calculates a time quantum factor, and performs cascade processing on the initial key, the identity label, the device serial number and the time quantum factor by adopting a multi-stage cascade key derivation structure to obtain an intermediate key; the equipment encrypts the registration request by using the intermediate key and then sends the encrypted registration request to the gateway, the gateway carries out decryption verification and generates a random number, and the equipment and the gateway derive an access token based on the intermediate key and the random number; the equipment generates a request signature identifier by using the access token, and sends the service parameters, the request signature identifier and the request serial number to the gateway; and the device and the cloud carry out bidirectional identity verification. According to the technical scheme of the invention, high-strength bidirectional authentication and key dynamic generation of the equipment and the cloud are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things security, and particularly relates to a dynamic key derivation method for bidirectional authentication of Internet of Things devices and a cloud. BACKGROUND

[0002] With the rapid development of Internet of Things technology, the security problem of massive devices accessing cloud services is increasingly prominent. Traditional Internet of Things device authentication schemes mostly use static key pre-implantation or fixed encryption algorithm transmission, that is, the secret key is written into the hardware storage module in advance during the device production link, or the secret key is directly transmitted to the device end through a fixed encryption protocol. Although such methods can meet the basic encryption needs, with the upgrading of network security risks, they gradually expose technical defects that are difficult to avoid: in the static secret key pre-implantation mode, all devices in the same batch share the same secret key, and once a device is cracked or the secret key is leaked in the production and storage link, the security line of the entire batch of devices will collapse, causing unpredictable losses to merchants and business platforms; the encryption logic of existing fixed encryption protocols (such as conventional AES and DES encryption) is fixed and lacks dynamic adjustment capability, and hackers can track secret key transmission data packets for a long time, analyze encryption rules, gradually crack the encryption algorithm, and then illegally obtain the secret key, causing security problems such as transmission information tampering and content forgery; in the traditional transmission method, the device end can only passively receive the secret key and perform simple decryption, and cannot establish a collaborative verification process based on exclusive verification rules with the cloud. When data packet tampering or false secret key injection occurs during transmission, the device end cannot effectively identify it, which may lead to initialization failure or access to illegal business services. The secret key is directly transmitted to the device end.

[0003] The Chinese invention patent CN113285807A discloses a method for intelligent device network access authentication. In the method, the intelligent device sends an HTTP request for applying for network access credentials to an authentication server. The request carries a signature timestamp, an application APPID, an APPKEY, a device SN, and a first signature generated from the above information. The authentication server checks the legality of the signature timestamp, the first signature, and the device SN in the HTTP request, and generates network access credentials for the intelligent device after the check is passed. The network access credentials include a ClientID, a login username, and a token required for connecting to an MQTT Broker. The intelligent device sends a login request through the network access credentials. The authentication server performs double-checking on the token and the ClientID used by the intelligent device for login. The technical solution improves the timeliness of authentication through the signature timestamp mechanism and enhances security through double-checking of the token and the ClientID. However, the generation and distribution process of the network access credentials in the solution relies on fixed derivation rules, lacks a dynamic key derivation mechanism based on device hardware features and time factors, and requires high accuracy of clock synchronization between the device and the server. When there is a deviation in the device clock, the signature timestamp check may fail. Moreover, the solution does not establish a reverse identity verification process from the cloud to the device, which poses a risk of tampering with response data or man-in-the-middle attacks. SUMMARY

[0004] Therefore, the present application provides a dynamic key derivation method for bidirectional authentication of Internet of Things devices and the cloud to solve the problems of single key leakage risk, weak anti-cracking ability of fixed encryption algorithm, and insufficient key verification coordination between devices and the cloud in the prior art.

[0005] The technical solution of the present application is implemented as follows: The present application provides a dynamic key derivation method for bidirectional authentication of Internet of Things devices and the cloud, comprising the following steps: S1, assigning a unique identity, an initial key, and a device serial number to the device, and encrypting the initial key for storage; S2, the device obtains a current timestamp, quantizes the timestamp according to a preset time window width using a time window quantization mechanism to obtain a time window identifier, calculates a time quantum factor based on the time window identifier and the identity, and performs a cascade processing on the initial key, the identity, the device serial number, and the time quantum factor using a multi-level cascade key derivation structure to obtain an intermediate key; S3, the device encrypts a registration request containing the identity and the time window identifier using the intermediate key and sends it to the gateway. The gateway retrieves the corresponding initial key based on the identity and performs decryption verification. After the gateway verification is passed, a random number is generated. The device and the gateway derive an access token based on the intermediate key and the random number; S4, the device sorts and splices the service parameters according to the preset rule, generates a request signature identifier by using the access token for hash message authentication code operation, and sends the service parameters, the request signature identifier and the request sequence number to the gateway; S5, the gateway verifies the device identity based on the service parameters using the access token, and calculates a gateway identity identifier and returns it to the device, and the device verifies the gateway identity identifier using the access token, thereby realizing the two-way identity authentication between the device and the cloud.

[0006] On the basis of the above technical scheme, preferably, in step S2, the intermediate key is obtained by using a multi-stage cascade key derivation structure, comprising: A1, calculating a first-stage shift parameter according to the identity identifier and the time quantum factor, and performing shift and hash operations on the combination of the initial key and the time quantum factor to obtain a first-stage cascade output; A2, calculating a second-stage shift parameter according to the device sequence number and the time quantum factor, and performing a nonlinear transformation on the first-stage cascade output by using an adaptive shift amount mechanism based on S-box mapping to obtain a second-stage cascade output; A3, calculating a cross shift parameter, performing a symmetric cross shift operation on the second-stage cascade output, performing XOR fusion on the left shift result and the right shift result, and performing confusion diffusion on the combination hash value of the first-stage cascade output and the second-stage cascade output, and finally generating the intermediate key.

[0007] On the basis of the above technical scheme, preferably, in step A2, the adaptive shift amount mechanism based on S-box mapping comprises: performing hash operation on the first-stage cascade output to obtain a 256-bit hash value, and using the hash value to construct a dynamic S-box lookup table, the lookup table comprising a plurality of sub-tables, each sub-table comprising a plurality of entries, each entry being a shift increment value in a preset range, the value of each entry in the lookup table being obtained by performing XOR operation on a plurality of bytes of the hash value and then taking the modulus; using different byte segments of the hash value as row index and column index to obtain a nonlinear adaptive increment in the lookup table, and adding the second-stage shift parameter calculated according to the device sequence number and the time quantum factor to the nonlinear adaptive increment and then taking the modulus to obtain the final adaptive shift amount; performing cyclic shift on the first-stage cascade output according to the final adaptive shift amount, and then performing XOR operation on the combination hash value of the device sequence number and the time window identifier to obtain the second-stage cascade output.

[0008] On the basis of the above technical scheme, preferably, the calculation formula of the intermediate key is: ; ; wherein, is the result after left shift of the second-stage cascade output, output the result after right shifting as the second level cascade output, output the result as the first level cascade output, output the result as the second level cascade output, identify the identity, identify the device serial number, identify the time window, perform the XOR operation, perform the string concatenation operation.

[0009] On the basis of the above technical solutions, preferably, step S3 comprises: S31, the device uses the intermediate key as an encryption key to encrypt the registration request message body containing the identity, the device serial number and the time window identifier, and transmits it to the cloud gateway through a secure channel; S32, after the gateway receives the registration request, the corresponding initial key is searched according to the identity, and the same time window quantization and multi-level cascade derivation process as the device end is performed, and a three-window attempt mechanism is used to perform decryption verification in turn using the current time window, the previous time window and the next time window, and if any time window verification is passed, the device identity verification is completed; S33, after the gateway verification, a random number is generated and encrypted using the intermediate key and sent back to the device; S34, the device and the gateway use the key derivation algorithm to derive the access token using the intermediate key as the input key and the information containing the identity, the random number and the time window identifier as the derivation parameter.

[0010] On the basis of the above technical solutions, preferably, in step S34, the key derivation algorithm uses the HKDF-Expand algorithm, the intermediate key is used as a pseudo-random key, the strings "access-token", the identity, the random number and the time window identifier are concatenated in order and connected with a separator to form the info parameter, the output length is 256 bits, and the access token is generated.

[0011] On the basis of the above technical solutions, preferably, step S4 comprises: S41, the device sorts the service parameters in ascending order according to the lexicographical order of the parameter names; S42, the sorted service parameters are concatenated in the format of "parameter name=parameter value", and multiple parameters are connected using a preset separator to form a parameter string; S43, using the access token as a key, the parameter string is subjected to HMAC-SHA256 hash message authentication code operation to generate a request signature identifier; S44, the service parameters, the request signature identifier and the monotonically increasing request sequence number are encapsulated into a request message and sent to the gateway.

[0012] On the basis of the above technical solutions, preferably, step S5 comprises: S51, the gateway receives the service request and searches for the corresponding access token according to the identity; S52, the gateway generates a parameter string according to the same sorting and splicing rules as the device side for the service parameters in the request message, and calculates an expected signature value using the access token; S53, the gateway compares and verifies the expected signature value with the request signature identifier in the request, and verifies whether the request sequence number meets the monotonic increasing condition, if the signature verification is passed and the sequence number is valid, the identity authentication of the device to the gateway is completed; S54, the gateway uses the access token as a key to perform HMAC-SHA256 hash message authentication code operation on the response data and the request context information to obtain the gateway identity, and returns the response data and the gateway identity to the device; S55, the device receives and uses the access token to calculate the expected gateway identity for the response data and the original request context, and compares it with the received gateway identity, if they are consistent, the identity authentication of the gateway to the device is completed.

[0013] On the basis of the above technical solutions, preferably, step S5 further comprises an abnormality detection and response mechanism: The gateway monitors the request behavior of the device in real time during the execution of steps S51 to S55, and triggers an abnormal alarm when it is detected that the number of failed request signature verifications exceeds a preset threshold, the request sequence number is rolled back or repeated, the request frequency in a unit time exceeds the normal range, or sensitive resources are accessed. The gateway records the abnormal event and marks the device as suspicious, suspends or rejects the subsequent request of the device, and requires the device to re-register and authenticate or enter the manual review process.

[0014] On the basis of the above technical solutions, preferably, the dynamic key derivation method further comprises an adaptive authentication enhancement mechanism: The gateway calculates the risk score of the device according to the historical behavior data, access frequency and abnormal event record of the device, divides the device into low risk level, medium risk level and high risk level, sets different access token validity periods for devices of different risk levels, and the higher the risk level, the shorter the access token validity period. When the risk level of the device is improved, the gateway dynamically shortens the access token validity period and increases the authentication frequency.

[0015] The dynamic key derivation method for bidirectional authentication of the Internet of Things device and the cloud has the following beneficial effects compared with the prior art: (1) Through the time window quantization mechanism combined with three-window attempt verification, multi-level cascade key derivation structure, self-adaptive shift amount mechanism and bidirectional identity verification, a complete security system from device initialization, key derivation, registration authentication to bidirectional verification is constructed, effectively solving the problems of easy leakage of static key, weak anti-cracking ability of fixed encryption algorithm and insufficient cooperation of device and cloud verification in the authentication of Internet of Things devices, realizing high-strength bidirectional authentication and dynamic generation of key between device and cloud under the premise of adapting to the limitation of the computing capacity of Internet of Things devices.

[0016] (2) The traditional scheme requires that the time stamps of the device and the server be strictly consistent, and once the clock deviation exceeds several seconds, the authentication fails. The application introduces a time window quantization mechanism, expands the tolerance deviation of the clock of both parties, and improves the engineering deployability and authentication success rate of the system. In a large-scale Internet of Things deployment scenario, especially for edge devices that lack network time synchronization capability, this mechanism can greatly reduce the authentication failure rate caused by clock deviation.

[0017] (3) A three-level cascade key derivation structure is adopted, the application identity is deeply fused with the initial key through the first level of cascade, the self-adaptive shift amount mechanism based on S-box mapping is introduced in the second level of cascade, a dynamic S-box lookup table is constructed by the hash value of the first level output to obtain a nonlinear adaptive increment, so that the final shift amount is nonlinearly affected by the complete state of the output of the previous level, and the third level of cascade realizes full-bit bidirectional diffusion through symmetric cross shift, so that even if an attacker obtains part of the intermediate state information through side channel attack, the actual shift amount cannot be deduced, and the anti-side channel attack ability is significantly enhanced compared with the traditional fixed shift derivation scheme.

[0018] (4) Through the bidirectional identity verification mechanism, the device and the gateway mutually authenticate each other, effectively preventing man-in-the-middle attacks and fake gateway attacks. Most of the traditional schemes only verify the device identity, and the gateway identity is not verified by the device, so the attacker can pretend to be a legal gateway to intercept the device request. In the application, the gateway generates a gateway identity identifier bound to the context of the request after verifying the device identity, and the device confirms the legality of the gateway by verifying the identifier, forming a bidirectional closed-loop authentication, thereby improving the authentication security. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, a brief introduction will be given below to the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Figure 1A flowchart of a dynamic key derivation method for bidirectional authentication of an Internet of Things device and a cloud; Figure 2 A flowchart of a multi-level cascading key derivation structure; Figure 3 A flowchart of an adaptive shift amount mechanism based on S-box mapping; Figure 4 A device registration and access token derivation flowchart; Figure 5 A bidirectional identity authentication mechanism schematic diagram. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0022] As shown in Figure 1 The present application provides a dynamic key derivation method for bidirectional authentication of an Internet of Things device and a cloud, comprising the following steps: S1, a unique identity, an initial key and a device serial number are assigned to the device, and the initial key is encrypted and stored; S2, the device acquires a current timestamp, quantizes the timestamp according to a preset time window width using a time window quantization mechanism to obtain a time window identifier, calculates a time quantum factor based on the time window identifier and the identity, and performs cascading processing on the initial key, the identity, the device serial number and the time quantum factor using a multi-level cascading key derivation structure to obtain an intermediate key; S3, the device encrypts a registration request containing the identity and the time window identifier using the intermediate key and sends it to the gateway, the gateway retrieves the corresponding initial key according to the identity and performs decryption verification, the gateway generates a random number after verification, and the device and the gateway derive an access token based on the intermediate key and the random number; S4, the device sorts and splices the business parameters according to a preset rule, generates a request signature identifier using the access token for a hash message authentication code operation, and sends the business parameters, the request signature identifier and a request serial number to the gateway; S5, the gateway verifies the device identity based on the business parameters using the access token, and calculates a gateway identity identifier and returns it to the device, the device verifies the gateway identity identifier using the access token, and realizes bidirectional identity authentication between the device and the cloud.

[0023] In an embodiment of the present application, step S1 comprises: when the device is manufactured or first configured, the system allocates a globally unique application identity appid for each device, which is generated in the format of UUID v4 and has a length of 128 bits, ensuring global uniqueness. At the same time, a 256-bit initial key secretA is allocated for the device, which is generated by a true random number generator in the hardware security module or the trusted execution environment, ensuring its unpredictability. The serial number sn of the device is burned into the device firmware by the manufacturer during the production process, which is bound to the device hardware fingerprint and is verified by digital signature to prevent forgery. The initial key secretA is encrypted and stored on the device side in the AES-256-GCM mode, and the encryption key is the device hardware root key rootKey, which is solidified in the one-time programmable area of the chip or generated by the physical unclonable function, ensuring that even if the device firmware is extracted, the attacker cannot directly obtain the initial key plaintext. On the cloud gateway side, the encrypted copy of the initial key is stored in the device identity database, and the gateway encrypts the initial key by using the master key in the hardware security module, which is generated by the hardware security module and is subject to strict access control.

[0024] In an embodiment of the present application, as shown in Figure 2 and 3 , step S2 comprises: the device acquires the current timestamp reqTimestamp, which is in the format of Unix timestamp and has a unit of s. Considering the problem of clock desynchronization commonly existing in Internet of Things devices, the device quantizes and aligns the timestamp according to a preset time window width, which is 60s in this embodiment. The formula for calculating the time window identifier timeWindow by the device is: ; wherein, represents the floor operation. This quantization operation aligns the timestamp to the nearest minute boundary, so that the timeWindow calculated by the device and the gateway remains consistent at any time within the same minute, thereby tolerating a deviation of within ±30s between the clocks of the two parties.

[0025] Based on the quantized time window identifier, the device calculates the time quantum factor timeQuantum, and the calculation formula is: ; wherein, represents the SHA-256 hash function, represents the byte string concatenation operation, represents the first 8 bytes of the hash output result. This time quantum factor fuses the time window and application identity information, ensuring that different devices will generate different time quantum factors even within the same time window.

[0026] The device adopts a multi-stage cascaded key derivation structure to cascade the initial key, the identity, the device serial number and the time quantum factor to obtain an intermediate key secretC. Before the key derivation calculation, the implementation of the cyclic shift operation needs to be determined: the cyclic left shift operation ROL and the cyclic right shift operation ROR are performed on the 256-bit data as a whole at the bit level. Specifically, the 32-byte key data is interpreted as a 256-bit binary integer in the big-endian sequence, and the cyclic left shift of n bits means that the high n bits of the integer are moved to the low n bit position, and the original low 256-n bits are moved to the high bit, realizing the cyclic movement of the bits without losing any information.

[0027] Further, the process of obtaining the intermediate key in step S2 by using the multi-stage cascaded key derivation structure includes the following sub-steps: A1, calculating a first-stage shift parameter according to the identity and the time quantum factor, and performing a shift and a hash operation on the combination of the initial key and the time quantum factor to obtain a first-stage cascaded output.

[0028] Specifically, the hash value of the identity is calculated , the first 4 bytes are taken and interpreted as a 32-bit unsigned integer, denoted as , the first 4 bytes of the time quantum factor are denoted as , and the two are subjected to an XOR operation and then modulo 128 to obtain the first-stage shift parameter: ; wherein represents the bitwise XOR operation, and \mod represents the modulo operation. The shift parameter has a value range of 0 to 127.

[0029] The time quantum factor is cyclically repeated 4 times to expand it to 256 bits, denoted as , and the intermediate state of the first-stage cascade is calculated: ; The intermediate state is subjected to a cyclic left shift operation and XOR mixed with the identity hash to obtain the first-stage cascaded output: ; wherein represents a cyclic left shift operation of on the 256-bit data by bits. The first-stage cascade realizes the deep integration of the identity and the initial key.

[0030] A2, calculate the second-level shift parameter according to the device serial number and the time quantum factor, and perform nonlinear transformation on the first-level cascade output by using the adaptive shift amount mechanism based on S-box mapping to obtain the second-level cascade output.

[0031] Calculate the hash value of the device serial number , and take the first 4 bytes as , and take the last 4 bytes of the time quantum factor as , calculate the second-level shift parameter: ; Perform nonlinear transformation on the first-level cascade output by using the adaptive shift amount mechanism based on S-box mapping, which specifically includes: performing hash operation on the first-level cascade output to obtain a 256-bit hash value, using the hash value to construct a dynamic S-box lookup table, the lookup table contains multiple sub-tables, each sub-table contains multiple entries, and each entry is a shift increment value in a preset range, the value of each entry in the lookup table is obtained by performing XOR operation on multiple bytes of the hash value and then taking the modulus; use different byte segments of the hash value as row index and column index to obtain nonlinear adaptive increment in the lookup table, add the second-level shift parameter calculated according to the device serial number and the time quantum factor to the nonlinear adaptive increment, and take the modulus to obtain the final adaptive shift amount; cyclically shift the first-level cascade output according to the final adaptive shift amount, and then perform XOR operation with the combined hash value of the device serial number and the time window identifier to obtain the second-level cascade output.

[0032] Specifically, first, perform hash operation on the first-level cascade output: ; Wherein, is the 256-bit hash value of the first-level cascade output, containing 32 bytes. Use the hash value to construct a dynamic S-box lookup table SBox1, which contains 8 sub-tables, each sub-table has 16 entries, and each entry is a shift increment value from 0 to 127. The value of each entry in the lookup table is obtained by performing XOR operation on multiple bytes of the hash value and then taking the modulus: ; Wherein is the table index, is the entry index, represents the kth byte of the hash value, represents the bitwise XOR operation. This construction method ensures that each entry of the S-box depends on the complete state information of the first-level output.

[0033] Use different byte segments of as row index and column index to obtain nonlinear adaptive increment in the lookup table: ; ; ; wherein, is the row index of the lookup table, obtained by taking the 0th byte of modulo 8, with a value range of 0-7; is the column index of the lookup table, obtained by taking the 1st byte of modulo 16, with a value range of 0-15; is the nonlinear adaptive increment obtained from the S-box lookup table, with a value range of 0-127.

[0034] The second-stage shift parameter is added to the nonlinear adaptive increment and then modulo operation is performed to obtain the final adaptive shift amount: ; The first-stage concatenated output is cyclically shifted according to the final adaptive shift amount, and then XOR operation is performed with the combined hash value of the device serial number and the time window identifier to obtain the second-stage concatenated output: ; wherein, denotes the operation of cyclically right-shifting the 256-bit data by bits. This mechanism enhances the security of key derivation through dynamic S-box lookup tables and nonlinear transformations. Even if an attacker obtains part of the intermediate state information through side-channel attacks, the actual shift amount cannot be derived due to the strong nonlinear characteristics of the lookup process and the dynamic generation of the S-box lookup table from the complete 256-bit hash value.

[0035] A3、Calculate the cross-shift parameter, perform a symmetric cross-shift operation on the second-stage concatenated output, XOR fuse the left-shift result and the right-shift result, and perform confusion diffusion with the combined hash value of the first-stage concatenated output and the second-stage concatenated output to finally generate the intermediate key.

[0036] Specifically, calculate the hash value of the second-stage output, take the first 1 byte as , and calculate the cross-shift parameter: ; Perform a symmetric cross-shift operation on the second-stage concatenated output: ; The symmetric design ensures that the first half and the second half of the data are both subjected to sufficient movement in opposite directions, and the movement distance is complementary. The results of the shift in both directions are XOR fused and confused and diffused with the combined hash value of the application identity, device serial number and time window identification: ; To further enhance security, the third-level temporary output is finally mixed to generate an intermediate key: ; wherein, is the result of the left shift of the second-level concatenated output, is the result of the right shift of the second-level concatenated output, is the first-level concatenated output, is the second-level concatenated output, is the identity, is the device serial number, is the time window identification, is the XOR operation, is the string concatenation operation.

[0037] The final mixing step introduces the joint hash of the first two levels of output, so that even if the attacker obtains the third-level intermediate state, the final intermediate key cannot be directly derived, and the first-level and second-level outputs must be obtained simultaneously to complete the calculation. The three-level concatenated structure realizes high nonlinear confusion and avalanche effect through multiple cyclic shifts, adaptive parameter generation and symmetric diffusion mechanism, ensuring that any slight change in the input information will cause a dramatic change in the output.

[0038] In an embodiment of the present application, as shown in Figure 4 and 5 , step S3 includes the following sub-steps: S31, the device uses the intermediate key as an encryption key to encrypt the registration request message body containing the identity, device serial number and time window identification, and transmits it to the cloud gateway through a secure channel.

[0039] The device uses the intermediate key as an encryption key to encrypt the registration request message body containing the identity, device serial number and time window identification. The message body of the registration request is encapsulated in JSON format, serialized and encrypted using the AES-256-GCM mode, the initialization vector IV uses a 12-byte random number, and the authentication tag tag is 16 bytes long. The encrypted data includes ciphertext, initialization vector IV and authentication tag, which are encapsulated together and transmitted to the cloud gateway through a TLS1.3 secure channel.

[0040] S32, the gateway receives the registration request, retrieves the corresponding initial key according to the identity, and performs the same time window quantization and multi-level cascade derivation process as the device side. The three-window attempt mechanism is used to verify the current time window, the previous time window and the next time window in turn. If any time window verification is passed, the device identity verification is completed.

[0041] The gateway receives the registration request, retrieves the corresponding initial key according to the identity, and the gateway side maintains a device identity database, which stores the encrypted copy of the initial key corresponding to each identity. The gateway decrypts the initial key through the hardware security module to obtain the plaintext, and then performs the same time window quantization and multi-level cascade derivation process as the device side. To solve the time window boundary problem, the gateway uses a three-window attempt mechanism: first, use the current time window Calculate the intermediate key and try to decrypt. If decryption fails, the gateway automatically tries the previous time window Verify, if still failed, try the next time window Verify. Only when the verification of the three time windows fails, the gateway determines that the authentication fails. This mechanism expands the time tolerance range to plus or minus 90s, significantly improves the authentication success rate under the premise of ensuring security.

[0042] To prevent replay attacks, the gateway maintains a sliding window type used request record table, which records the combination of all successfully verified time window identifiers and request sequence numbers within the last 180s. In the three-window attempt process, if it is found that a combination of a time window and a sequence number has been used, the request is rejected. The record table uses a timing cleaning mechanism to clean records older than 180s every 60s, and the storage overhead is controllable.

[0043] S33, the gateway generates a random number and encrypts it with the intermediate key and sends it back to the device after verification.

[0044] The gateway generates a 256-bit random number nonce as a salt value for key derivation after verification. The gateway uses the intermediate key as the key and encrypts the random number using the AES-256-GCM mode to generate the ciphertext encryptedNonce and its corresponding initialization vector IV and authentication tag tag, and sends it back to the device through the TLS 1.3 channel.

[0045] S34, the device and the gateway use the key derivation algorithm to derive the access token with the intermediate key as the input key and the information containing the identity, random number and time window identifier as the derivation parameter.

[0046] After the device receives the encrypted nonce issued by the gateway, the device uses the intermediate key derived by itself as a decryption key to perform AES-256-GCM decryption on the encryptedNonce. After successful decryption, the device and the gateway use a key derivation algorithm to derive an access token secretD, using the intermediate key as an input key and using information including an identity, a random number, and a time window identifier as derivation parameters.

[0047] The access token has a life cycle attribute, and the gateway sets the valid period of the token after completing derivation. A typical value is 24 hours. The device records the generation timestamp of the access token, and checks whether the current time exceeds the valid period before initiating a service request each time. If the valid period is exceeded, the device needs to perform the device registration process again, derive a new intermediate key, and obtain a new access token. The device securely stores the access token in a local encrypted storage area, which is also protected by AES-256-GCM encryption using the device hardware root key rootKey.

[0048] In an embodiment of the present application, step S4 includes the following sub-steps: S41, the device sorts the service parameters in ascending order according to the lexicographical order of the parameter names; wherein the sorting rule uses ASCII code value comparison of the parameter names.

[0049] S42, the sorted service parameters are spliced in the format of "parameter name=parameter value", and multiple parameters are connected using a preset separator, to form a parameter string; in this embodiment, the separator is the "&" character, and the parameter string is in the format of "key1=value1&key2=value2&key3=value3". This sorting and splicing process ensures that the same parameter set will generate the same parameter string regardless of the original order, facilitating consistent verification by the server.

[0050] S43, the access token is used as a key to perform HMAC-SHA256 hash message authentication code operation on the parameter string to generate a request signature identifier; wherein the request signature identifier secretF is: ; wherein, represents that is used as a key, A message HMAC-SHA256 message authentication code calculation process of the message. The HMAC-SHA256 algorithm is a message authentication mechanism based on a key, has the collision resistance of SHA-256 and the key-dependent unforgeability, and can effectively resist length extension attack and chosen plaintext attack.

[0051] S44, the service parameters, the request signature identifier and the monotonically increasing request sequence number are encapsulated into a request message and sent to the gateway. Specifically, the device maintains a monotonically increasing request sequence number reqSeq, and includes the current sequence number in the request message each time the request is initiated, and increments the sequence number after the request is successful. The device encapsulates the service parameters, the request signature identifier secretF and the request sequence number reqSeq into a request message, and sends the request message to the gateway through a TLS 1.3 secure channel. The request message is in JSON format and includes an application identity identifier for the gateway side to index the corresponding access token.

[0052] In an embodiment of the application, step S5 includes the following sub-steps: S51, the gateway extracts the application identity identifier of the device from the request message after receiving the service request, and retrieves the currently valid access token by querying the device session database; S52, the gateway generates a parameter string according to the same sorting and splicing rules as the device side for the service parameters in the request message, and calculates an expected signature value using the access token; the expected signature value is: ; wherein, is the access token retrieved by the gateway, is the parameter string generated by the gateway according to the same rules as the device side.

[0053] S53, the gateway compares and verifies the expected signature value with the request signature identifier in the request, and verifies whether the request sequence number meets the monotonically increasing condition, and if the signature verification is passed and the sequence number is valid, the identity authentication of the device to the gateway is completed.

[0054] Specifically, the gateway compares the expected signature value calculated with the request signature identifier in the request in constant time to prevent time side channel attacks. If they are exactly the same, it proves that the request is indeed initiated by the device holding the legal access token, and the request parameters have not been tampered with in the transmission process. At the same time, the gateway verifies whether the request sequence number reqSeq meets the monotonically increasing condition, and the gateway side records the maximum processed sequence number maxSeq corresponding to each identity identifier, and checks whether it meets If the signature verification is passed and the sequence number is valid, the identity authentication of the device to the gateway is completed. The double constraints of the sequence number mechanism combined with the timestamp effectively prevent replay attacks and request forgery.

[0055] S54, the gateway uses the access token as a key to perform an HMAC-SHA256 hash message authentication code operation on the response data and the request context information to obtain a gateway identity, and returns the response data and the gateway identity to the device.

[0056] Specifically, after verifying the device identity, the gateway needs to prove its legitimacy to the device to prevent man-in-the-middle attacks or fake gateways. The gateway uses the access token as a key to perform an HMAC-SHA256 hash message authentication code operation on the response data responseData and the original request timestamp to obtain a gateway identity : ; wherein, represents the service response data returned by the gateway to the device, is the original request timestamp. The gateway identity binds the context information of this request, ensuring the one-time use of the identity. The gateway encapsulates the response data and the gateway identity into a response message and returns it to the device through a TLS 1.3 secure channel.

[0057] S55, the device receives the response data and uses the access token to calculate the expected gateway identity based on the original request context, and compares it with the received gateway identity. If they are consistent, the gateway-to-device identity authentication is completed.

[0058] After receiving the response message, the device uses the access token it holds to calculate the expected gateway identity based on the response data and the original request timestamp according to the same rule: ; The device compares the calculated with the carried in the response message. If they are consistent, it proves that the response is indeed sent by the gateway holding the legal secretD, and the gateway-to-device identity authentication is completed, thus realizing complete two-way identity authentication.

[0059] In an embodiment of the present application, step S5 further includes an abnormality detection and response mechanism: The gateway monitors the request behavior of the device in real time during the execution of steps S51 to S55. When it detects that the number of failed request signature verifications exceeds a preset threshold, the request sequence number appears to be rolled back or repeated, the request frequency per unit time exceeds the normal range, or sensitive resources are accessed, it triggers an abnormality alarm. The gateway records the abnormal event and marks the device as suspicious, suspends or rejects the subsequent requests of the device, and requires the device to re-register and authenticate or enter a manual review process.

[0060] The gateway maintains a signature verification failure counter failCount and a request frequency statistics reqRate within a time window for each identity. When the number of request signature verification failures exceeds a preset threshold, the request sequence number appears to be rolled back or repeated, the request frequency per unit time exceeds the normal range, or sensitive resources are accessed, an abnormal alarm is triggered. In this embodiment, when the signature verification of a certain identity fails for 5 consecutive requests, or the request frequency within a 1 min time window exceeds 100 times / min, the gateway determines that the device has abnormal behavior. The gateway records the abnormal event and marks the device as suspicious, suspends or rejects the subsequent requests of the device, and requires the device to re-register and authenticate or enter the manual review process. The gateway temporarily freezes the access permission of the identity, and the freezing duration is 10 min. After the freezing period ends, the device needs to go through the complete re-registration and identity verification process to restore normal access. If the device still has abnormal behavior in 3 consecutive re-registrations, the gateway adds the identity to the blacklist, permanently denies its access, and triggers the manual review process.

[0061] The abnormality detection mechanism can identify various attack modes such as brute force cracking, replay attacks, and abnormal parameter injection in real time, complete detection and response within 30s after the attack is initiated, take measures such as freezing access permission and forcing re-registration, and effectively curb the spread of attacks.

[0062] In an embodiment of the present application, the dynamic key derivation method further includes an adaptive authentication enhancement mechanism: The gateway calculates the risk score of the device according to the historical behavior data, access frequency and abnormal event record of the device, divides the device into a low risk level, a medium risk level and a high risk level, sets different access token validity periods for devices of different risk levels, the higher the risk level, the shorter the access token validity period, and when the risk level of the device is improved, the gateway dynamically shortens the access token validity period and increases the authentication frequency.

[0063] The gateway calculates the risk score of the device according to the historical behavior data, access frequency and abnormal event record of the device. The gateway maintains the behavior index statistics within a recent time window for each identity, including the signature verification failure rate rateFail, the request frequency variance varFreq, and the abnormal parameter ratio ratioAbnormal. Based on these indexes, the gateway calculates the risk score: ; wherein, is a weight coefficient, which is configured according to business characteristics and security policies, and satisfies In this embodiment, the values are 0.5, 0.3, and 0.2, respectively. The gateway divides the devices into low-risk levels, medium-risk levels, and high-risk levels. In this embodiment, two risk levels are set: low-risk level L1 and high-risk level L2. When the risk score exceeds the preset threshold 0.6, the gateway raises the risk level of the device to L2; when the risk score is continuously lower than the security threshold 0.3 for 48 hours, the gateway lowers the risk level of the device back to L1.

[0064] Different access token validity periods are set for devices of different risk levels, and the higher the risk level, the shorter the access token validity period. For devices in the low-risk level L1, the gateway uses the standard authentication process, and the access token validity period is set to 24 hours, and the device can continuously use the same access token for business requests within the validity period. For devices in the high-risk level L2, the gateway increases the authentication strength, shortens the access token validity period to 1 hour, and requires the device to re-register and update the key more frequently; requires the device to perform secondary authentication during critical business operations, that is, in addition to the regular signature verification, the device needs to derive a new intermediate key and use a new time window identifier to perform a complete two-way authentication process; performs more stringent semantic checks and anomaly detection on the request parameters of the device, such as parameter value rationality verification, request frequency fine-grained monitoring, etc. When the risk level of the device is raised, the gateway dynamically shortens the access token validity period and increases the authentication frequency.

[0065] The adaptive authentication enhancement mechanism also supports risk assessment based on geographic location and network environment. The gateway records the commonly used access IP addresses and geographic location information of the device, and automatically triggers risk level raising when detecting that the device initiates a request from an abnormal geographic location or an uncommon IP address segment. For example, if the device initiates a request from two locations with a geographic distance of more than 1000 kilometers within a time interval of less than 1 hour, the gateway determines that it is suspicious behavior, marks the device as a high-risk level L2, and requires the device to perform secondary authentication.

[0066] This adaptive authentication enhancement mechanism dynamically adjusts the authentication strength according to the risk level of the device, and achieves a flexible balance between security and availability, which can protect abnormal devices on the premise of not affecting the normal use of devices, and realize the optimal allocation of resources.

[0067] Through the above-mentioned multi-stage cascading key derivation structure, adaptive shift amount mechanism based on S-box mapping, bidirectional identity authentication mechanism, three-window attempt mechanism, anomaly detection mechanism and adaptive authentication enhancement mechanism, the application constructs a complete security system from device initialization, key derivation, registration authentication, request signature to bidirectional verification and adaptive protection. The method solves the actual engineering problem of clock asynchronization of Internet of Things devices through the time window quantization mechanism, tolerates a certain deviation of the clocks of both parties, the three-window attempt mechanism expands the time fault tolerance range, significantly improves the engineering deployability and authentication success rate of the system. The three-stage cascading structure makes any slight change of the input information cause a dramatic change of the output after multiple rounds of propagation through the adaptive shift amount and symmetric cross shift mechanism, meets the avalanche effect criterion in cryptography, and significantly improves the anti-side channel attack ability compared with the traditional fixed shift scheme.

[0068] The above merely describes preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A dynamic key derivation method for two-way authentication between IoT devices and the cloud, characterized in that: Includes the following steps: S1. Assign a unique identifier, initial key, and device serial number to the device, and encrypt and store the initial key; S2. The device obtains the current timestamp, uses a time window quantization mechanism to quantize the timestamp according to the preset time window width to obtain the time window identifier, calculates the time quantum factor based on the time window identifier and the identity identifier, and uses a multi-level cascaded key derivation structure to cascade the initial key, identity identifier, device serial number and time quantum factor to obtain the intermediate key. S3. The device uses an intermediate key to encrypt the registration request containing the identity identifier and time window identifier and sends it to the gateway. The gateway retrieves the corresponding initial key based on the identity identifier and performs decryption verification. After the gateway verifies the information, it generates a random number. The device and the gateway derive the access token based on the intermediate key and the random number. S4. After the device sorts and concatenates the service parameters according to the preset rules, it uses the access token to perform hash message authentication code calculation to generate a request signature identifier, and sends the service parameters, request signature identifier and request sequence number to the gateway. S5. The gateway uses an access token to verify the device identity based on business parameters and calculates the gateway identity identifier, which is then returned to the device. The device uses the access token to verify the gateway identity identifier, thus achieving two-way authentication between the device and the cloud.

2. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 1, characterized in that: In step S2, the intermediate key is obtained using a multi-level concatenated key derivation structure, including: A1. Calculate the first-level shift parameters based on the identity identifier and the time quantum factor, and perform shift and hash operations on the combination of the initial key and the time quantum factor to obtain the first-level concatenated output; A2. Calculate the second-stage shift parameters based on the device serial number and time quantum factor, and use an adaptive shift mechanism based on S-box mapping to perform a nonlinear transformation on the first-stage cascaded output to obtain the second-stage cascaded output; A3. Calculate the cross-shift parameters, perform a symmetrical cross-shift operation on the second-level cascade output, XOR the left-shift result and right-shift result, and then confuse and diffuse the result with the combined hash value of the first-level cascade output and the second-level cascade output to finally generate the intermediate key.

3. The dynamic key derivation method for two-way authentication between IoT devices and the cloud as described in claim 2, characterized in that: In step A2, the adaptive shift mechanism based on S-box mapping includes: A hash operation is performed on the first-stage concatenated output to obtain a 256-bit hash value. This hash value is used to construct a dynamic S-box lookup table. This lookup table contains multiple sub-tables, each containing multiple entries. Each entry is a shift increment value within a preset range. The value of each entry in the lookup table is obtained by performing an XOR operation on multiple bytes of the hash value and then taking the modulo. The nonlinear adaptive increment is obtained by using different byte segments of the hash value as row and column indices in the lookup table. The second-level shift parameter calculated based on the device serial number and time quantum factor is added to the nonlinear adaptive increment and the modulo is taken to obtain the final adaptive shift amount. The first-stage cascaded output is cyclically shifted according to the final adaptive shift amount, and then XORed with the combined hash value of the device serial number and time window identifier to obtain the second-stage cascaded output.

4. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 2, characterized in that: The formula for calculating the intermediate key is as follows: ； ； in, The output of the second cascaded output is the result after left shift. Output the right-shifted result for the second cascade. This is the first-stage cascade output. For the second stage of cascaded output, For identification purposes, For the device serial number, For time window identification, For XOR operation, This is for string concatenation operations.

5. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 1, characterized in that: Step S3 includes: S31. The device uses an intermediate key as an encryption key to encrypt the registration request message body containing the identity identifier, device serial number and time window identifier, and transmits it to the cloud gateway through a secure channel. S32. After receiving the registration request, the gateway retrieves the corresponding initial key based on the identity identifier, executes the same time window quantization and multi-level cascading derivation process as the device, and adopts a three-window trial mechanism to decrypt and verify in sequence using the current time window, the previous time window, and the next time window. If the verification in any time window is successful, the device identity verification is completed. S33. After the gateway verification is successful, a random number is generated, encrypted with an intermediate key, and sent back to the device. S34. Both the device and the gateway use a key derivation algorithm with the intermediate key as the input key and information including the identity identifier, random number and time window identifier as the derivation parameters to derive the access token.

6. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 5, characterized in that: In step S34, the key derivation algorithm adopts the HKDF-Expand algorithm, using the intermediate key as the pseudo-random key. The string "access-token", identity identifier, random number and time window identifier are concatenated in sequence and connected with a delimiter to form the info parameter, thereby generating the access token.

7. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 1, characterized in that: Step S4 includes: S41. The device sorts the service parameters in ascending order according to the lexicographical order of the parameter names; S42. Concatenate the sorted business parameters in the format "parameter name=parameter value", and connect multiple parameters with a preset separator to form a parameter string; S43. Using the access token as a key, perform HMAC-SHA256 hash message authentication code operation on the parameter string to generate a request signature identifier; S44. Encapsulate the business parameters, request signature identifier, and monotonically increasing request sequence number into a request message and send it to the gateway.

8. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 1, characterized in that: Step S5 includes: S51. After receiving a service request, the gateway retrieves the corresponding access token based on the identity identifier. S52. The gateway generates parameter strings for the business parameters in the request message according to the same sorting and concatenation rules as the device, and uses the access token to calculate the expected signature value. S53. The gateway compares and verifies the expected signature value with the request signature identifier in the request, and at the same time verifies whether the request serial number meets the monotonically increasing condition. If the signature verification is successful and the serial number is valid, the device-to-gateway identity authentication is completed. S54. The gateway uses the access token as a key to perform HMAC-SHA256 hash message authentication code calculation on the response data and request context information to obtain the gateway identity identifier, and returns the response data and gateway identity identifier to the device. S55. After receiving the data, the device uses the access token to calculate the expected gateway identity based on the response data and the original request context, and compares it with the received gateway identity. If they match, the gateway-to-device authentication is completed.

9. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 8, characterized in that: Step S5 also includes anomaly detection and response mechanisms: During the execution of steps S51 to S55, the gateway monitors the device's request behavior in real time. When it detects that the number of failed request signature verifications exceeds a preset threshold, the request sequence number is rolled back or duplicated, the request frequency per unit time exceeds the normal range, or when accessing sensitive resources, it triggers an abnormal alarm. The gateway records the abnormal event and marks the device as suspicious, suspends or rejects the device's subsequent requests, and requires the device to re-register and authenticate or enter the manual review process.

10. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 1, characterized in that: The dynamic key derivation method also includes an adaptive authentication enhancement mechanism: The gateway calculates the risk score of a device based on its historical behavior data, access frequency, and abnormal event records, classifying the device into low-risk, medium-risk, and high-risk levels. Different access token validity periods are set for devices with different risk levels; the higher the risk level, the shorter the access token validity period. When the device's risk level increases, the gateway dynamically shortens the access token validity period and increases the authentication frequency.

Images