A dynamic key derivation method for bi-directional authentication between an internet of things device and a cloud

Abstract

The application relates to the technical field of Internet of Things security, in particular to a dynamic key derivation method for bidirectional authentication of Internet of Things equipment and a cloud end, which comprises the following steps: allocating a unique identity, an initial key and a device serial number to the equipment, and encrypting the initial key; the equipment acquires a current timestamp, calculates a time quantum factor, and adopts a multi-stage cascaded key derivation structure to perform cascaded processing on the initial key, the identity, the device serial number and the time quantum factor to obtain an intermediate key; the equipment sends a registration request to a gateway after encrypting the registration request by using the intermediate key, the gateway performs 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 a service parameter, the request signature identifier and a request serial number to the gateway; and the equipment and the cloud end perform bidirectional identity authentication. The technical scheme of the application realizes high-strength bidirectional authentication and dynamic generation of keys of the equipment and the cloud end.

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, 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 which the intelligent device sends an HTTP request for applying for network access credentials to an authentication server, the request carrying a signature timestamp, an APPID, an APPKEY and a device SN of the application, 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 of the intelligent device after the check is passed, the network access credentials including 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, and 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 the security through the double-checking of the token and the ClientID, but the generation and distribution process of the network access credentials in the solution depends on fixed derivation rules, lacks a dynamic key derivation mechanism based on device hardware features and time factors, and the authentication process has a high requirement for the clock synchronization accuracy between the device and the server, which may lead to the failure of signature timestamp checking when there is a deviation in the device clock, and the solution does not establish a reverse identity verification process from the cloud to the device, which has the risk of tampering or man-in-the-middle attack of the response data. SUMMARY

[0004] Therefore, the 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 cooperation between devices and the cloud in the prior art.

[0005] The technical solution of the application is implemented as follows: the application provides a dynamic key derivation method for bidirectional authentication of Internet of Things devices and the cloud, comprising the following steps:

[0006] S1, a unique identity, an initial key and a device serial number are allocated to the device, and the initial key is encrypted and stored;

[0007] S2, the device acquires a current timestamp, quantizes the timestamp according to a preset time window width to obtain a time window identifier using a time window quantization mechanism, calculates a time quantum factor based on the time window identifier and the identity, and performs 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;

[0008] S3, the device sends a registration request containing the identity and the time window identifier to the gateway after encrypting the registration request using the intermediate key, the gateway retrieves the corresponding initial key according to the identity and performs decryption verification, generates a random number after the gateway verification is passed, and the device and the gateway derive an access token based on the intermediate key and the random number;

[0009] 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 a request sequence number to the gateway;

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

[0011] 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:

[0012] 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;

[0013] A2, calculating a second-stage shift parameter according to the device sequence number and the time quantum factor, and performing 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;

[0014] A3, calculating a cross shift parameter, performing symmetric cross shift operation on the second-stage cascade output, performing exclusive OR 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.

[0015] On the basis of the above technical scheme, preferably, in step A2, the adaptive shift amount mechanism based on S-box mapping comprises:

[0016] 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 exclusive OR operation on a plurality of bytes of the hash value and then taking the modulus;

[0017] 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 a final adaptive shift amount;

[0018] performing cyclic shift on the first-stage cascade output according to the final adaptive shift amount, and then performing exclusive OR operation on the combination hash value of the device sequence number and the time window identifier to obtain the second-stage cascade output.

[0019] On the basis of the above technical scheme, preferably, the calculation formula of the intermediate key is:

[0020] ;

[0021] ;

[0022] wherein, is the result of left shift of the second level cascade output, is the result of right shift of the second level cascade output, is the first level cascade output, is the second level cascade output, is the identity, is the device serial number, is the time window identifier, is the exclusive or operation, is the string concatenation operation.

[0023] On the basis of the above technical scheme, preferably, step S3 comprises:

[0024] 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;

[0025] S32, after the gateway receives the registration request, the corresponding initial key is searched according to the identity, 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;

[0026] S33, after the gateway verification, a random number is generated and encrypted using the intermediate key and sent back to the device;

[0027] 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, the random number and the time window identifier as the derivation parameter.

[0028] On the basis of the above technical scheme, preferably, in step S34, the key derivation algorithm adopts 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.

[0029] On the basis of the above technical scheme, preferably, step S4 comprises:

[0030] S41, the device sorts the service parameters in ascending order according to the lexicographical order of the parameter names;

[0031] S42, the sorted service parameters are spliced in the format of "parameter name=parameter value", and multiple parameters are connected by a preset separator to form a parameter string;

[0032] 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;

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

[0034] On the basis of the above technical scheme, preferably, step S5 comprises:

[0035] S51, the gateway retrieves the corresponding access token according to the identity after receiving the service request;

[0036] 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;

[0037] 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, and if the signature verification is passed and the sequence number is valid, the identity authentication of the device to the gateway is completed;

[0038] 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 a gateway identity identifier, and returns the response data and the gateway identity identifier to the device;

[0039] S55, the device receives the response data and the original request context using the access token to calculate the expected gateway identity identifier, and compares it with the received gateway identity identifier, and if they are consistent, the identity authentication of the gateway to the device is completed.

[0040] On the basis of the above technical scheme, preferably, step S5 further comprises an exception detection and response mechanism:

[0041] The gateway monitors the request behavior of the device in real time during the execution of steps S51 to S55, and triggers an exception alarm when it detects 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 exception 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.

[0042] On the basis of the above technical scheme, preferably, the dynamic key derivation method further comprises an adaptive authentication enhancement mechanism.

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

[0044] The dynamic key derivation method for two-way authentication of the Internet of Things device and the cloud has the following beneficial effects compared with the prior art:

[0045] (1) Through the time window quantization mechanism combined with three window attempt verification, multi-level cascade key derivation structure, adaptive shift amount mechanism and two-way identity verification, a complete security system from device initialization, key derivation, registration authentication to two-way 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 Internet of Things device authentication, realizing high-strength two-way authentication and dynamic key generation of device and cloud under the premise of adapting to the limitation of Internet of Things device computing capability.

[0046] (2) The traditional scheme requires that the time stamps of the device and the server be strictly consistent, and once the clock deviation exceeds a few seconds, the authentication fails. The present 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 large-scale Internet of Things deployment scenarios, especially for edge devices lacking network time synchronization capability, this mechanism can significantly reduce the authentication failure rate caused by clock deviation.

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

[0048] (4) The application realizes mutual authentication of the device to the gateway and the gateway to the device through a bidirectional identity authentication mechanism, effectively preventing man-in-the-middle attacks and fake gateway attacks. Traditional schemes mostly only verify the device identity, and the gateway identity is not verified by the device, so attackers can pretend to be a legal gateway to intercept device requests. In the application, the gateway generates a gateway identity identifier bound to the context of the current 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

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0050] Figure 1 The flowchart of the dynamic key derivation method for the bidirectional authentication of the Internet of Things device and the cloud of the present application;

[0051] Figure 2 The flowchart of the multi-level cascading key derivation structure of the present application;

[0052] Figure 3 The flowchart of the adaptive shift amount mechanism based on S-box mapping of the present application;

[0053] Figure 4 The device registration and access token derivation flowchart of the present application;

[0054] Figure 5 The schematic diagram of the bidirectional identity authentication mechanism of the present application. DETAILED DESCRIPTION

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

[0056] 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:

[0057] S1, a unique identity identifier, an initial key and a device serial number are allocated to the device, and the initial key is encrypted and stored;

[0058] S2, the device acquires a current timestamp, quantizes the timestamp according to a preset time window width to obtain a time window identifier by using a time window quantization mechanism, calculates a time quantum factor based on the time window identifier and the identity identifier, and performs cascade processing on the initial key, the identity identifier, the device serial number and the time quantum factor by using a multi-level cascade key derivation structure to obtain an intermediate key;

[0059] S3, the device sends a registration request containing the identity identifier and the time window identifier to the gateway after encrypting the registration request by using the intermediate key, the gateway retrieves the corresponding initial key according to the identity identifier 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;

[0060] S4, the device sorts and splices the service parameters according to a preset rule, generates a request signature identifier by using the access token to perform a hash message authentication code operation, and sends the service parameters, the request signature identifier and a request serial number to the gateway;

[0061] S5, the gateway verifies the device identity based on the service parameters by using the access token, and returns the gateway identity identifier to the device, the device verifies the gateway identity identifier by using the access token, and realizes the bidirectional identity authentication between the device and the cloud.

[0062] In an embodiment of the present application, step S1 includes: when the device is manufactured or first configured, the system allocates a globally unique application identity appid for each device, the identity identifier is generated in the form of UUID v4, the length is 128 bits, and the global uniqueness is ensured. At the same time, a 256-bit initial key secretA is allocated for the device, the key is generated by a true random number generator in a hardware security module or a trusted execution environment, and the unpredictability is ensured. The serial number sn of the device is burned into the device firmware by the manufacturer during the production process, the serial number is bound with the device hardware fingerprint, and digital signature verification is performed to prevent forgery. The initial key secretA is encrypted and stored on the device side by using the AES-256-GCM mode, the encryption key is the device hardware root key rootKey, the hardware root key is solidified in the one-time programmable area of the chip or generated by the physical unclonable function, and 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, and the master key is generated by the hardware security module and is subject to strict access control.

[0063] In an embodiment of the present application, as Figure 2 and 3As shown, step S2 includes: the device obtains the current timestamp reqTimestamp, which uses the Unix timestamp format and is in seconds. Considering the common clock synchronization problem among IoT devices, the device quantizes and aligns the timestamp according to a preset time window width; in this embodiment, 60 seconds is used as the time window width. The formula for calculating the time window identifier timeWindow is:

[0064] ;

[0065] in, This indicates a floor operation. This quantization operation aligns the timestamp to the nearest minute boundary, ensuring that the timeWindow calculated by the device and the gateway remains consistent at any point within the same minute, thus tolerating a deviation of ±30 seconds between the clocks of both parties.

[0066] Based on the quantized time window identifier, the device calculates the time quantum factor (timeQuantum) using the following formula:

[0067] ;

[0068] in, This refers to the SHA-256 hash function. This indicates a byte string concatenation operation. This indicates that the first 8 bytes of the hash output should be retrieved. This time quantum factor combines time window and application identity information to ensure that different devices will produce different time quantum factors even within the same time window.

[0069] The device employs 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, secretC. Before performing key derivation calculations, the implementation method of the circular shift operation needs to be clarified: the circular left shift (ROL) and circular right shift (ROR) operations perform bit-level shifts on the entire 256-bit data. Specifically, the 32-byte key data is interpreted as a 256-bit binary integer in big-endian order. A circular left shift of n bits means moving the high n bits of this integer to the low n bits, while the original low 256 minus n bits are moved to the high bits, achieving a circular bit shift without losing any information.

[0070] Furthermore, the process of obtaining the intermediate key using a multi-level concatenated key derivation structure in step S2 includes the following sub-steps:

[0071] 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 cascaded output.

[0072] Specifically, a hash value of the application 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 first level shift parameter is obtained by performing XOR operation on the two and taking modulo 128:

[0073] ;

[0074] wherein denotes a bitwise XOR operation, and \mod denotes a modulo operation. The shift parameter has a value range of 0 to 127.

[0075] The time quantum factor is cyclically repeated 4 times to expand to 256 bits, denoted as , and the intermediate state of the first level cascade is calculated:

[0076] ;

[0077] The intermediate state is subjected to a cyclic left shift operation and XOR mixed with the identity hash to obtain the first level cascade output:

[0078] ;

[0079] wherein denotes a cyclic left shift operation of 256-bit data by bits. The first level cascade realizes deep fusion of the application identity and the initial key.

[0080] A2. A second level shift parameter is calculated according to the device serial number and the time quantum factor, and a second level cascade output is obtained by performing nonlinear transformation on the first level cascade output using an adaptive shift amount mechanism based on S-box mapping.

[0081] A hash value of the device serial number is calculated , the first 4 bytes are taken and denoted as , the last 4 bytes of the time quantum factor are denoted as , and the second level shift parameter is calculated:

[0082] ;

[0083] The adaptive shift amount mechanism based on S-box mapping is used to perform nonlinear transformation on the first-stage cascade output, specifically including: performing a hash operation on the first-stage cascade output to obtain a 256-bit hash value, using the hash value to construct a dynamic S-box lookup table, the lookup table including a plurality of sub-tables, each sub-table including 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 an XOR operation on a plurality of bytes of the hash value and then taking a modulus; using different byte segments of the hash value as row indexes and column indexes to obtain a nonlinear adaptive increment in the lookup table, adding the second-stage shift parameter calculated according to the device serial number and the time quantum factor to the nonlinear adaptive increment and then taking a modulus to obtain a final adaptive shift amount; performing a cyclic shift on the first-stage cascade output according to the final adaptive shift amount, and then performing an XOR operation with the combined hash value of the device serial number and the time window identifier to obtain the second-stage cascade output.

[0084] Specifically, first, a hash operation is performed on the first-stage cascade output:

[0085] ;

[0086] wherein, is a 256-bit hash value of the first-stage cascade output, including 32 bytes. A dynamic S-box lookup table SBox1 is constructed using the hash value, the table including 8 sub-tables, each sub-table including 16 entries, each entry being a shift increment value from 0 to 127. The value of each entry in the lookup table is obtained by performing an XOR operation on a plurality of bytes of the hash value and then taking a modulus:

[0087] ;

[0088] wherein is a table index, is an entry index, represents the kth byte of the hash value, represents a bitwise XOR operation. This construction method ensures that each entry of the S-box depends on the complete state information of the first-stage output.

[0089] Using different byte segments of the hash value as row indexes and column indexes to obtain a nonlinear adaptive increment in the lookup table:

[0090] ;

[0091] ;

[0092] ;

[0093] wherein, is a row index of the lookup table, obtained by ​The value is obtained by taking the modulo of 8 from the 0th byte, and the value range is 0-7; To find the column index of the table, by The value is obtained by taking the first byte modulo 16, and the value range is 0-15; This is the nonlinear adaptive increment obtained from the S-box lookup table, with a value range of 0-127.

[0094] The second-stage shift parameter The final adaptive shift amount is obtained by adding the nonlinear adaptive increment and taking the modulus.

[0095] ;

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

[0097] ;

[0098] in, This indicates 256 bits of data. Perform a circular right shift Bit manipulation. This mechanism enhances the security of key derivation through a dynamic S-box lookup table and nonlinear transformations. Even if an attacker obtains some intermediate state information through a side-channel attack, the actual shift amount cannot be derived because the S-box is a lookup table dynamically generated from a complete 256-bit hash value, and the lookup process has strong nonlinear characteristics.

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

[0100] Specifically, calculate the hash value of the second-level output. Take the first byte and denote it as Calculate the cross-shift parameters:

[0101] ;

[0102] Perform a symmetrical cross-shift operation on the second-stage cascaded output:

[0103] ;

[0104] 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:

[0105] ;

[0106] To further enhance security, the third-level temporary output is finally mixed to generate an intermediate key:

[0107] ;

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

[0109] 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, it cannot directly deduce the final intermediate key, and must simultaneously know the outputs of the first and second levels 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.

[0110] In an embodiment of the present application, as shown in Figure 4 and 5 , step S3 includes the following sub-steps:

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

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

[0113] S32, after the gateway receives the registration request, the corresponding initial key is retrieved 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 use the current time window, the previous time window and the next time window in turn to decrypt and verify, and if any time window is verified, the device identity verification is completed.

[0114] After the gateway receives the registration request, the corresponding initial key is retrieved according to the identity, and the gateway side maintains a device identity database, which stores an 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 end. 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 the decryption fails, the gateway automatically tries the previous time window Verify, if it still fails, 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.

[0115] 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 serial numbers within the last 180s. In the three-window attempt process, if it is found that a combination of a time window and a serial 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.

[0116] S33, after the gateway verification, a random number is generated and encrypted using the intermediate key and sent back to the device.

[0117] After the gateway verification is passed, a 256-bit random number nonce is generated as a salt value for key derivation. The gateway uses the intermediate key as a key to encrypt the random number in the AES-256-GCM mode to generate a ciphertext encryptedNonce, an initial vector IV corresponding to the ciphertext, and an authentication tag tag, and sends them back to the device through the TLS 1.3 channel.

[0118] In step S34, the device and the gateway use a key derivation algorithm to derive an access token by taking the intermediate key as an input key and taking information containing an identity, a random number, and a time window identifier as a derivation parameter.

[0119] After the device receives the encrypted random number issued by the gateway, the device uses the intermediate key derived by the device 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 by taking the intermediate key as an input key and taking information containing an identity, a random number, and a time window identifier as a derivation parameter. The key derivation algorithm uses the HKDF-Expand algorithm, takes the intermediate key as a pseudo-random key, concatenates the strings "access-token", the identity, the random number, and the time window identifier in sequence to form an info parameter, and outputs a length of 256 bits to generate the access token.

[0120] The access token has a life cycle attribute, and the gateway sets the valid period of the token after completing the 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 re-execute the device registration process, derive a new intermediate key, and obtain a new access token. The device securely stores the access token in a local encrypted storage area, and the storage area is also protected by AES-256-GCM encryption using the device hardware root key rootKey.

[0121] In an embodiment of the present application, step S4 includes the following sub-steps:

[0122] In step S41, the device sorts the service parameters in ascending order according to the lexicographical order of the parameter names. The sorting rule uses the ASCII code value comparison of the parameter names.

[0123] S42. The sorted business parameters are concatenated in the format "parameter name=parameter value", with multiple parameters connected by a preset separator to form a parameter string; in this embodiment, the separator is the "&" character, for example, the parameter string format is "key1=value1&key2=value2&key3=value3". This sorting and concatenation process ensures that the same set of parameters will generate the same parameter string regardless of the original order, facilitating consistency verification by the server.

[0124] S43. Using the access token as the key, perform HMAC-SHA256 hash message authentication code calculation on the parameter string to generate a request signature identifier; wherein, the request signature identifier secretF is:

[0125] ;

[0126] in, Indicated by For key, This describes the process of calculating the HMAC-SHA256 message authentication code for a message. The HMAC-SHA256 algorithm is a key-based message authentication mechanism that possesses the collision resistance and key-dependent unforgeability of SHA-256, effectively resisting length extension attacks and chosen-plaintext attacks.

[0127] S44. The device encapsulates the business parameters, request signature identifier, and monotonically increasing request sequence number into a request message and sends it to the gateway. Specifically, the device maintains a monotonically increasing request sequence number, `reqSeq`, includes the current sequence number in the request message each time a request is initiated, and increments the sequence number after a successful request. The device encapsulates the business parameters, request signature identifier `secretF`, and request sequence number `reqSeq` into a request message and sends it to the gateway via a TLS 1.3 secure channel. The request message is in JSON format and includes an application identity identifier used by the gateway to index the corresponding access token.

[0128] In one embodiment of the present invention, step S5 includes the following sub-steps:

[0129] S51. After receiving a service request, the gateway extracts the application identity identifier of the device from the request message and retrieves the currently valid access token by querying the device session database.

[0130] 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 calculates the expected signature value using the access token; the expected signature value is:

[0131] ;

[0132] in, the access token retrieved for the gateway, the parameter string generated for the gateway according to the same rules as for the device end.

[0133] S53, the gateway compares the expected signature value with the request signature identifier in the request, and verifies whether the request sequence number satisfies the monotonic 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.

[0134] Specifically, the gateway compares the calculated expected signature value with the request signature identifier in the request at a 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 during transmission. At the same time, the gateway verifies whether the request sequence number reqSeq satisfies the monotonic increasing condition, and the gateway side records the maximum processed sequence number maxSeq corresponding to each identity identifier, and checks whether it satisfies 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.

[0135] 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 identifier, and returns the response data and the gateway identity identifier to the device.

[0136] Specifically, after verifying the identity of the device, 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 HMAC-SHA256 hash message authentication code operation on the response data responseData and the original request timestamp to obtain the gateway identity identifier :

[0137] ;

[0138] wherein, the service response data returned by the gateway to the device, the original request timestamp. The gateway identity identifier binds the context information of this request, ensuring the one-time use feature of the identifier. The gateway encapsulates the response data and the gateway identity identifier into a response message and returns it to the device through a TLS 1.3 secure channel.

[0139] S55, the device receives the response data and calculates the expected gateway identity identifier using the access token and the original request context, and compares it with the received gateway identity identifier, and if they are consistent, the identity authentication of the gateway to the device is completed.

[0140] The device uses the access token it holds to calculate the expected gateway identity from the response data and the original request timestamp according to the same rule:

[0141]

[0142] The device compares the calculated expected gateway identity with the one carried in the response message. If they are consistent, it proves that the response is indeed sent by the gateway holding the legitimate secretD, completing the gateway-to-device identity authentication, and thus achieving complete mutual authentication.

[0143] In an embodiment of the present application, step S5 further includes an abnormality detection and response mechanism:

[0144] The gateway monitors the device's request behavior in real time during the execution of steps S51-S55. When it detects that the number of failed 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 abnormality 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.

[0145] The gateway maintains a signature verification failure counter failCount and a request frequency reqRate within a time window for each identity. When it detects that the number of failed 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. In this embodiment, when a certain identity fails in signature verification for 5 consecutive requests, or the request frequency within a 1min time window exceeds 100 times / min, the gateway determines that the device has abnormal behavior. The gateway records the abnormality 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. The gateway temporarily freezes the access rights of the identity, with a freeze duration of 10min. After the freeze period ends, the device needs to go through a complete re-registration and identity verification process to restore normal access. If the device still exhibits 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.

[0146] This abnormality detection mechanism can identify multiple 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, and take measures such as freezing access rights and forcing re-registration to effectively contain the spread of attacks.

[0147] ​​​In an embodiment of the present application, the dynamic key derivation method further comprises an adaptive authentication enhancement mechanism.

[0148] The gateway calculates the risk score of the device according to the historical behavior data, access frequency and abnormal event records 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.

[0149] The gateway calculates the risk score of the device according to the historical behavior data, access frequency and abnormal event records of the device. The gateway maintains the behavior index statistics in the 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:

[0150] ;

[0151] wherein, is a weight coefficient, configured according to business characteristics and security policies, satisfying In the embodiment, the values are 0.5, 0.3 and 0.2 respectively. The gateway divides the device into a low risk level, a medium risk level and a high risk level. In the embodiment, two risk levels are set: a low risk level L1 and a high risk level L2. When the risk score exceeds a preset threshold 0.6, the gateway improves the risk level of the device to L2; when the risk score continuously falls below the security threshold 0.3 for 48h, the gateway reduces the risk level of the device back to L1.

[0152] Different access token validity periods are set for devices of different risk levels, the higher the risk level, the shorter the access token validity period. For devices in the low risk level L1, the gateway adopts a standard authentication process, the access token validity period is set to 24h, 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 improves the authentication strength, shortens the access token validity period to 1h, and requires the device to re-register and update the key more frequently; during critical business operations, the device is required to perform secondary authentication, 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; the request parameters of the device are subjected to more stringent semantic checking and abnormal detection, such as parameter value rationality verification, request frequency fine-grained monitoring, etc. When the risk level of the device is improved, the gateway dynamically shortens the access token validity period and increases the authentication frequency.

[0153] The adaptive authentication enhancement mechanism also supports risk assessment based on geographical location and network environment. The gateway records the commonly used access IP address and geographical location information of the device, and automatically triggers the risk level promotion when detecting that the device initiates a request from an abnormal geographical location or an uncommon IP address segment. For example, if the device initiates a request from two locations with a geographical 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.

[0154] The adaptive authentication enhancement mechanism dynamically adjusts the authentication strength according to the risk level of the device, achieves a flexible balance between security and usability, can focus on protecting abnormal devices without affecting the normal use of devices, and realizes the optimal allocation of resources.

[0155] Through the above-mentioned multi-level 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, expands the time fault tolerance range through the three-window attempt mechanism, and significantly improves the engineering deployability and authentication success rate of the system. The three-level cascading structure realizes adaptive shift amount and symmetric cross shift mechanism, so that any slight change of input information will cause a dramatic change of output after multiple rounds of propagation, meeting the avalanche effect criterion in cryptography, and significantly improving the anti-side channel attack ability compared with the traditional fixed shift scheme.

[0156] The above only describes the preferred embodiments of the application and is not intended to limit the application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the application shall be included in the protection scope of the 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 and returns it to the device. The device uses the access token to verify the gateway identity identifier, thereby realizing two-way authentication between the device and the cloud. 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 combined hash value of the first-level cascade output and the second-level cascade output to finally generate the intermediate key. 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.

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 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.

3. The dynamic key derivation method for two-way authentication between IoT devices and the cloud as described in claim 1, characterized in that: The formula for calculating the intermediate key is as follows: in, The output of the second cascaded stage 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.

4. 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.

5. The dynamic key derivation method for two-way authentication between an IoT device and the cloud as described in claim 4, 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.

6. 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.

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 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.

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: 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