Lightweight two-way authentication method and system for internet of things device identification

Abstract

The present application relates to the technical field of bidirectional authentication, and discloses a lightweight bidirectional authentication method and system for Internet of Things device identification, which comprises the following steps: mapping the encrypted device identification of an authentication response device and an authentication request device into a dynamic session key, performing a distributed challenge-response protocol on the dynamic session key to obtain a dynamic token, verifying the dynamic token and an expected token, generating a bidirectional authentication state, identifying the validity of the bidirectional authentication state, executing step S5 when the bidirectional authentication state is invalid, executing step S6 when the bidirectional authentication state is valid, then extracting a failure record in the validity identification result, tracing the failure record of the authentication request device based on the failure record to obtain an authentication defect feature, optimizing the distributed challenge-response protocol based on the authentication defect feature, and finally generating an authentication confirmation message based on the bidirectional authentication state; the present application can improve the authentication efficiency and accuracy of the lightweight bidirectional authentication for Internet of Things device identification.

Description

Technical Field

[0001] This invention relates to the field of two-way authentication technology, and in particular to a lightweight two-way authentication method and system for identifying Internet of Things (IoT) devices. Background Technology

[0002] With the exponential growth in the number of IoT devices, two-way authentication between devices faces significant challenges:

[0003] Existing two-way authentication between devices is limited by resources. Traditional asymmetric encryption cannot meet the real-time authentication requirements, and the protocols have vulnerabilities. Static key systems are susceptible to replay attacks, while dynamic token schemes, if they adopt software-level challenge responses, cannot adapt to the real-time requirements of industrial control scenarios. Furthermore, hijacking attacks can forge device identifiers through man-in-the-middle attacks. Existing authentication mechanisms lack the ability to trace the root cause of failures in real time. Therefore, how to achieve two-way device authentication that is resistant to replay attacks and has self-optimization capabilities in resource-constrained environments has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a lightweight two-way authentication method and system for IoT device identification to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides a lightweight two-way authentication method for IoT device identification, comprising:

[0006] S1, map the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key;

[0007] S2, Execute a distributed challenge-response protocol on the dynamic session key to obtain the dynamic token of the authentication response device;

[0008] S3, perform consistency verification on the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device;

[0009] S4, perform validity identification on the two-way authentication status. If the two-way authentication status is invalid, proceed to step S5. If the two-way authentication status is valid, proceed to step S6.

[0010] S5, extract the failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features;

[0011] S6, Generate an authentication confirmation message based on the two-way authentication status.

[0012] In a preferred embodiment, mapping the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key includes:

[0013] S201, standardize the device identifiers of the authentication response device and the authentication request device to obtain standard device identifiers of the authentication response device and the authentication request device;

[0014] S202, the standard device identifier is input into a preset hash function to obtain the encrypted device identifier of the standard device identifier;

[0015] S203, perform one-way encryption mapping processing on the encrypted device identifier to obtain the initial session key of the standard device identifier;

[0016] S204, perform bit length reduction processing on the initial session key to obtain a dynamic session key.

[0017] In a preferred embodiment, the standardization process for the device identifiers of the authentication response device and the authentication request device to obtain standard device identifiers for the authentication response device and the authentication request device includes:

[0018] Load the original device identifiers of the authentication response device and the authentication request device;

[0019] Perform character cleaning operation on the original device identifier to generate an intermediate device identifier between the authentication response device and the authentication request device;

[0020] The intermediate device identifier is subjected to a fixed-length normalization conversion process to obtain the standard device identifiers of the authentication response device and the authentication request device.

[0021] In a preferred embodiment, performing a distributed challenge-response protocol on the dynamic session key to obtain a dynamic token from the authentication response device includes:

[0022] S401, Input the dynamic session key into a preset random number generator to obtain the initial challenge value of the authentication request device;

[0023] S402, Perform a bit-width expansion mapping operation on the initial challenge value to obtain an expanded challenge vector;

[0024] S403, perform an XOR obfuscation operation on the authentication request device based on the dynamic session key and the extended challenge vector to obtain the request-side dynamic token of the authentication request device;

[0025] S404, after receiving the initial challenge value, the authentication response device performs steps S402-S403 to obtain the local dynamic token of the authentication response device;

[0026] S405, perform token exchange between the requesting end dynamic token and the local dynamic token to obtain the dynamic token of the authentication response device.

[0027] In a preferred embodiment, the consistency verification of the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device includes:

[0028] S501, perform binary conversion on the dynamic token and the expected token respectively to obtain a dynamic token binary string and an expected token binary string;

[0029] S502, calculate the difference metric between the dynamic token binary string and the expected token binary string;

[0030] S503, perform a zero threshold judgment on the difference metric value to obtain the two-way authentication status of the authentication request device.

[0031] In a preferred embodiment, the step of validating the two-way authentication status, wherein if the two-way authentication status is invalid, step S5 is executed, and if the two-way authentication status is valid, step S6 is executed, includes:

[0032] S601, Read the status value from the two-way authentication status;

[0033] S602, perform a validity check on the state value to obtain a state flag;

[0034] S603, based on the state flag, perform a branch decision operation on the state value. If the result of the branch decision operation is an invalid flag value, then trigger step S5. If the result of the branch decision operation is a valid flag value, then trigger step S6.

[0035] In a preferred embodiment, the step of tracing the authentication request device based on the failure records to obtain authentication defect characteristics includes:

[0036] S701, extract failure records from the results of the validity identification to obtain the time-series failure dataset of the authentication request device;

[0037] S702, based on a preset defect tracing algorithm, defect indicators are calculated on the time series failure dataset to obtain the defect quantification index of the authentication request device, wherein the mathematical expression of the defect tracing algorithm is as follows;

[0038]

[0039] In the formula, For the quantification of defects, The number of failed records. Index for failure records, The time decay weighting coefficient for the k-th failed record. This is the difference metric for the k-th failed record;

[0040] S703, perform defect feature extraction on the defect quantification index to obtain the authentication defect features of the authentication request device.

[0041] In a preferred embodiment, optimizing the distributed challenge-response protocol based on the authentication defect characteristics includes:

[0042] S801, parse the authentication defect features to obtain the defect type of the authentication requesting device;

[0043] S802, the defect type is optimized based on a preset protocol parameter dynamic adjustment algorithm to obtain an optimized parameter set for the authentication defect features;

[0044] S803, the optimized parameter set is injected into the protocol register of the distributed challenge-response protocol.

[0045] In a preferred embodiment, generating an authentication confirmation message based on the two-way authentication status includes:

[0046] S901, Extract the session identifier associated with the valid two-way authentication status in the two-way authentication status;

[0047] S902, convert the session identifier into the original confirmation message of the authentication request device;

[0048] S903, perform lightweight encryption on the original confirmation message to obtain an authentication confirmation message.

[0049] To address the aforementioned problems, the present invention also provides a lightweight two-way authentication system for IoT device identification, the system comprising:

[0050] The identifier mapping module is used to map the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key;

[0051] A distributed token generation module is used to execute a distributed challenge-response protocol on the dynamic session key to obtain a dynamic token from the authentication response device.

[0052] A two-way authentication module is used to verify the consistency between the dynamic token and the expected token of the authentication request device in order to obtain the two-way authentication status of the authentication request device.

[0053] The authentication validity identification module is used to identify the validity of the two-way authentication status. When the two-way authentication status is invalid, step S5 is executed, and when the two-way authentication status is valid, step S6 is executed.

[0054] The authentication failure handling module is used to extract failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features.

[0055] The authentication message generation module is used to generate an authentication confirmation message based on the two-way authentication status.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. High-efficiency processing is achieved through a hardware-accelerated hash engine and parallel bit comparators, coupled with a dedicated pipeline to achieve fast processing per byte cycle, significantly reducing the computational load on resource-constrained devices and meeting the real-time requirements of industrial control scenarios. In terms of security, a static key system is abandoned, and a dynamic session key generation and update mechanism is used to defend against replay attacks. A distributed challenge-response protocol is used to generate dynamic tokens, combined with lightweight encryption algorithms to protect authentication confirmation messages, effectively preventing risks such as man-in-the-middle attacks and device identifier forgery.

[0058] 2. A defect attribution algorithm is used to quantitatively analyze failure records. This algorithm introduces a time decay weighting coefficient, prioritizing recent failure events. It calculates quantitative defect indicators through logarithmic transformation to accurately locate defect types such as channel interference, token tampering, and identifier forgery. Based on defect characteristics, the system dynamically adjusts the challenge value length, retransmission count, and security strength level through protocol parameters. For example, for identifier forgery, the challenge value length and security level can be automatically increased, forming a closed loop of failure-attribution-optimization. This allows the authentication protocol to adapt to the dynamic changes in the IoT environment and maintain high reliability over the long term. Attached Figure Description

[0059] Figure 1 This is a flowchart illustrating a lightweight two-way authentication method for IoT device identification provided in an embodiment of the present invention.

[0060] Figure 2 A functional block diagram of a lightweight two-way authentication system for IoT device identification provided in an embodiment of the present invention;

[0061] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0062] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0063] This application provides a lightweight two-way authentication method for IoT device identifiers. The executing entity of this lightweight two-way authentication method for IoT device identifiers includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the lightweight two-way authentication method for IoT device identifiers can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0064] Reference Figure 1 The diagram shown is a flowchart illustrating a lightweight two-way authentication method for IoT device identifiers according to an embodiment of the present invention. In this embodiment, the lightweight two-way authentication method for IoT device identifiers includes:

[0065] S1, map the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key;

[0066] In this embodiment of the invention, mapping the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key includes:

[0067] S201, standardize the device identifiers of the authentication response device and the authentication request device to obtain standard device identifiers of the authentication response device and the authentication request device;

[0068] S202, the standard device identifier is input into a preset hash function to obtain the encrypted device identifier of the standard device identifier;

[0069] S203, perform one-way encryption mapping processing on the encrypted device identifier to obtain the initial session key of the standard device identifier;

[0070] S204, perform bit length reduction processing on the initial session key to obtain a dynamic session key.

[0071] It should be noted that the preset hash function is based on the standard device identifier. It performs a one-way hash transformation through the SHA-256 algorithm module embedded in the encryption chip, and generates a 512-bit data block by message grouping and filling the 128-bit input according to the FIPS180-4 standard. Then, it is processed through 80 rounds of compression function iteration to finally output a 256-bit encrypted device identifier.

[0072] Furthermore, the physical implementation of the encryption process using the preset hash function relies on a hardware-level encryption engine, which achieves efficient processing per byte cycle through a dedicated pipeline. Its mathematical one-wayness and avalanche effect ensure that the device identifier is irreversibly mapped to a randomized digital fingerprint.

[0073] It should be noted that the one-way encryption mapping process is as follows: Based on the 256-bit encryption device identifier, a bilinear transformation is performed through the prime field discrete mathematical unit to divide the input into a high 128-bit segment encryption device identifier and a low 128-bit segment encryption device identifier. Modular multiplication and affine transformation are performed on the high 128-bit segment encryption device identifier and the low 128-bit segment encryption device identifier respectively to obtain the high segment modular multiplication result and the low segment affine transformation value.

[0074] A bit rearrangement operation is performed on the high-segment modular multiplication result and the low-segment affine transform value to obtain a 256-bit initial session key, wherein the mathematical expression of the bilinear transform is as follows:

[0075]

[0076] In the formula, For high-level modular multiplication results, These are the values ​​of the lower-segment affine transformation. The high 128 bits are used to encrypt the device identifier. The lower 128 bits are used to encrypt the device identifier. , and All are parameters of the prime number field;

[0077] Furthermore, the algorithmic expression used for the bit recombination operation is as follows:

[0078]

[0079] In the formula, This is the initial session key. This is the key reconfiguration state. For high-level modular multiplication results, These are the values ​​of the lower-segment affine transformation. The sign of the logical left shift. For bitwise XOR operator, This is a circular left shift function.

[0080] Furthermore, the key reconfiguration state is a 256-bit data bus temporary value.

[0081] It should be noted that the bit length reduction process is to reduce the bit length of the initial 256-bit session key by using a lead bit truncation strategy to obtain a 128-bit dynamic session key.

[0082] Furthermore, the specific process of the preamble truncation strategy is as follows: First, locate the starting address of the data storage of the initial session key, and then extract the 0th to 127th consecutive bits of the initial session key for output to obtain a 128-bit dynamic session key.

[0083] In this embodiment of the invention, the standardization process for the device identifiers of the authentication response device and the authentication request device to obtain standard device identifiers for the authentication response device and the authentication request device includes:

[0084] Load the original device identifiers of the authentication response device and the authentication request device;

[0085] Perform character cleaning operation on the original device identifier to generate an intermediate device identifier between the authentication response device and the authentication request device;

[0086] The intermediate device identifier is subjected to a fixed-length normalization conversion process to obtain the standard device identifiers of the authentication response device and the authentication request device.

[0087] It should be noted that the character cleaning operation is based on the original device identifier string. A hardware-level regular expression processor performs dynamic filtering to remove all non-hexadecimal characters. Then, an ASCII conversion module performs forced capitalization to unify the encoding format. Finally, a memory verifier verifies that consecutive characters constitute a valid hexadecimal byte sequence, generating a standardized intermediate device identifier.

[0088] Furthermore, the physical essence of character cleaning is that the embedded text engine eliminates protocol delimiters and solidifies the binary representation. By unifying character case, it prevents parsing ambiguity and sets up interrupt vectors to intercept illegal sequences, thus providing clean input for cryptographic operations.

[0089] It should be noted that the fixed-length standardization conversion process is based on the real-time bit width detection value of the intermediate device identifier. The control logic unit performs a three-state branch operation to obtain the standard device identifier.

[0090] Furthermore, the physical essence of fixed-length normalization conversion is to achieve rigid alignment of the input bit width of the cryptographic engine, compress the latency to within 2μs through hardware parallelization, and use memory address boundary control to resist cache side-channel attacks.

[0091] Furthermore, the three-state branch operation is as follows: when the bit width is equal to 128 bits, it is output directly; when it is less than 128 bits, a zero-value page is inserted in the high bits of memory; when it is greater than 128 bits, the CPU bit slicing instruction is triggered to truncate the first 128 bits. Finally, the data is adjusted to the processor word boundary based on the SRAM boundary alignment module to generate a standard device identifier.

[0092] S2, Execute a distributed challenge-response protocol on the dynamic session key to obtain the dynamic token of the authentication response device;

[0093] In this embodiment of the invention, the step of executing a distributed challenge-response protocol on the dynamic session key to obtain the dynamic token of the authentication response device includes:

[0094] S401, Input the dynamic session key into a preset random number generator to obtain the initial challenge value of the authentication request device;

[0095] S402, Perform a bit-width expansion mapping operation on the initial challenge value to obtain an expanded challenge vector;

[0096] S403, perform an XOR obfuscation operation on the authentication request device based on the dynamic session key and the extended challenge vector to obtain the request-side dynamic token of the authentication request device;

[0097] S404, after receiving the initial challenge value, the authentication response device performs steps S402-S403 to obtain the local dynamic token of the authentication response device;

[0098] S405, perform token exchange between the requesting end dynamic token and the local dynamic token to obtain the dynamic token of the authentication response device.

[0099] It should be noted that the extended mapping operation is based on the initial challenge value. The data bit width is extended by the processor-specific copy instruction. The initial challenge value is repeatedly filled 16 times in a continuous 128-bit register space, so that the single-byte input initial challenge value is extended to a 16-byte output.

[0100] It should be noted that the XOR obfuscation operation converts the dynamic session key and the extended challenge vector into 128-bit binary sequences respectively, to obtain the dynamic session key binary string and the extended challenge vector binary string;

[0101] The same sequence number bits of the dynamic session key binary string and the extended challenge vector binary string are XORed to obtain the token bit string;

[0102] The token bit string is concatenated in the output order to obtain either the requesting dynamic token or the local dynamic token.

[0103] It should be noted that token exchange is a process in which the authentication requesting device broadcasts its dynamic token to the radio frequency channel via a point-to-point wireless physical link. After receiving the dynamic token, the authentication response device reconstructs the operation chain in its local security environment and parses the dynamic token through an automatic response mechanism to obtain the dynamic token of the authentication response device.

[0104] S3, perform consistency verification on the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device;

[0105] In this embodiment of the invention, the step of performing consistency verification on the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device includes:

[0106] S501, perform binary conversion on the dynamic token and the expected token respectively to obtain a dynamic token binary string and an expected token binary string;

[0107] S502, calculate the difference metric between the dynamic token binary string and the expected token binary string;

[0108] S503, perform a zero threshold judgment on the difference metric value to obtain the two-way authentication status of the authentication request device.

[0109] It should be noted that the difference metric is calculated using a bit-level consistency verification algorithm, the mathematical expression of which is as follows:

[0110]

[0111] In the formula, This is a measure of difference. This represents the value of the nth bit in the dynamic token's binary string. Let n be the bit value of the expected token binary string. The dynamic token is a binary string. The expected token binary string, For bit indexing.

[0112] Furthermore, the essence of the bit-level consistency verification algorithm is to perform parallel bit operations through an embedded comparator unit, complete a full 128-bit comparison in a single clock cycle, generate a difference flag, and calculate the total difference value through a carry chain accumulator.

[0113] Furthermore, the difference metric, representing the total number of differing bits between the two token binary strings, is a bit-level inconsistency quantification calculated by a hardware accumulator, used to measure the degree of token deviation.

[0114] The dynamic token binary string is a 128-bit binary sequence representation of the dynamic token, which is the stored value of the local token generated by the authentication response device in the register;

[0115] The expected token binary string is a 128-bit binary sequence representation of the expected token, which is the cached value of the request token generated by the authentication request device in memory;

[0116] Bit index, ranging from 0 to 127, represents the bit sequence number in the binary string and is the iteration variable of the processor's loop counter.

[0117] It should be noted that the zero threshold judgment operation uses a zero value detector circuit to compare the difference measurement value with the zero threshold. If D=0, a high level is output to indicate a valid state; otherwise, a low level is output to indicate an invalid state, and the result is stored in the status register.

[0118] S4, perform validity identification on the two-way authentication status. If the two-way authentication status is invalid, proceed to step S5. If the two-way authentication status is valid, proceed to step S6.

[0119] In this embodiment of the invention, the step of validating the two-way authentication status, wherein when the two-way authentication status is invalid, step S5 is executed, and when the two-way authentication status is valid, step S6 is executed, includes:

[0120] S601, Read the status value from the two-way authentication status;

[0121] S602, perform a validity check on the state value to obtain a state flag;

[0122] S603, based on the state flag, perform a branch decision operation on the state value. If the result of the branch decision operation is an invalid flag value, then trigger step S5. If the result of the branch decision operation is a valid flag value, then trigger step S6.

[0123] It should be noted that the read status value refers to the binary level signal stored in the two-way authentication status. A high level indicates a valid status with a corresponding status value of 1, and a low level indicates an invalid status with a corresponding status value of 0.

[0124] It should be noted that the validity determination compares the status value with preset valid flag values ​​and invalid flag values, where the valid flag value is 1 and the invalid flag value is 0.

[0125] Furthermore, the essence of validity judgment is to compare the status value with the valid flag value and the invalid flag value in real time through the embedded comparator unit, and generate a status flag within a single clock cycle based on the comparison result.

[0126] Furthermore, the validity judgment algorithm utilizes hardware-level parallel processing to avoid software latency, complies with the resource constraints of IoT devices, and prevents misjudgments through anti-interference design.

[0127] It should be noted that the branch decision operation is based on the status flag, which triggers the corresponding execution task. When the status flag is 0, the authentication failure handling module is activated to execute step S5. When the authentication status is 1, the authentication message generation module is activated to execute step S6.

[0128] S5, extract the failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features;

[0129] In this embodiment of the invention, the step of tracing the failure records of the authentication request device to obtain authentication defect characteristics includes:

[0130] S701, extract failure records from the results of the validity identification to obtain the time-series failure dataset of the authentication request device;

[0131] S702, based on a preset defect tracing algorithm, defect indicators are calculated on the time series failure dataset to obtain the defect quantification index of the authentication request device, wherein the mathematical expression of the defect tracing algorithm is as follows;

[0132]

[0133] In the formula, For the quantification of defects, The number of failed records. Index for failure records, The time decay weighting coefficient for the k-th failed record. This is the difference metric for the k-th failed record;

[0134] S703, perform defect feature extraction on the defect quantification index to obtain the authentication defect features of the authentication request device.

[0135] It should be noted that the time series failure dataset is a collection of failed records extracted from all validity identification results containing timestamps.

[0136] It should be noted that the essence of the defect tracing algorithm is to perform pipelined calculations through an embedded digital signal processor, complete the processing of N records within a 2ms period, prioritize the processing of the latest events, and optimize numerical stability through logarithmic transformation.

[0137] Furthermore, the defect quantification index represents the aggregate severity of the certification defect. It is a scalar of the normalized weighted deviation value output by the hardware accumulator and is used to quantify the intensity of the root cause of failure.

[0138] The number of failure records comes from the count value of the failure event counter stored in the log cache register;

[0139] The time decay weighting factor is an exponential decay factor based on time difference, which gives higher weight to recent failures to reflect real-time threats.

[0140] Furthermore, the time decay weighting coefficient is obtained by exponentially calculating the time difference between the exponential decay factor and the two failed records, where the value of the exponential decay factor is 0.05.

[0141] It should be noted that defect feature extraction is based on defect quantification indicators and is performed by a three-stage voltage comparator hardware. Comparator 1: When the defect quantification indicator is less than 1.5V, it outputs a high level, mapped to "00", indicating channel interference. Comparator 2: When the defect quantification indicator is greater than 1.5V and less than 3V, it outputs a high level, mapped to "01", indicating token tampering. Comparator 3: When the defect quantification indicator is greater than 3.0V, it outputs a high level, mapped to "10", indicating identifier forgery. The final mapping result is converted into a 2-bit signal by the encoder circuit and stored in the feature register.

[0142] In this embodiment of the invention, optimizing the distributed challenge-response protocol based on the authentication defect characteristics includes:

[0143] S801, parse the authentication defect features to obtain the defect type of the authentication requesting device;

[0144] S802, the defect type is optimized based on a preset protocol parameter dynamic adjustment algorithm to obtain an optimized parameter set for the authentication defect features;

[0145] S803, the optimized parameter set is injected into the protocol register of the distributed challenge-response protocol.

[0146] It should be noted that parsing the authentication defect features refers to hard-wiring the 2-bit feature code to map it to the threat level. When the input is mapped to "00", it indicates channel interference. Comparator 2: When the defect quantization index is greater than 1.5V and less than 3V, it outputs a high level, mapped to "01", indicating token tampering. Comparator 3: When the defect quantization index is greater than 3.0V, it outputs a high level, mapped to "10", indicating identifier forgery.

[0147] It should be noted that the preset protocol parameter dynamic adjustment algorithm is as follows:

[0148]

[0149] In the formula, To challenge the length of the value, For the number of retransmissions, For safety strength level, Basic bit length, This is the bit length adjustment coefficient. Defect level, For the retransmission base, For risk sensitivity, For the minimum security level, This is a quantitative indicator for defects.

[0150] Furthermore, the challenge value bit length represents the extended bit width of the initial challenge value, which is configured via a shift register;

[0151] The retransmission count represents the maximum number of retries if token exchange fails;

[0152] The security strength level indicates the number of iterations for XOR conflation, and there are three levels in total.

[0153] The base bit length represents the bit width when the default radio frequency channel is stable;

[0154] The bit length adjustment coefficient represents the hardware multiplier gain parameter, used to amplify the effects of defects;

[0155] The defect level represents the authentication defect feature mapping value, where a defect level of 0 indicates interference, a defect level of 1 indicates tampering, a defect level of 2 indicates forgery, and a defect level of 3 indicates serious forgery.

[0156] Risk sensitivity is an exponential growth coefficient, which strengthens the response to high-risk defects.

[0157] It should be noted that the process of injecting the optimized parameter set into the protocol register of the distributed challenge-response protocol is to combine the challenge value bit length, retransmission count, and security strength level into an optimized parameter set, and then write the optimized parameter set into the state machine configuration register of the distributed challenge-response protocol.

[0158] Furthermore, the essence of parameter injection is to use hardware triggers to synchronously update the protocol state machine. When a change in register value is detected, the protocol automatically resets the current session and applies the new parameters.

[0159] S6, Generate an authentication confirmation message based on the two-way authentication status.

[0160] In this embodiment of the invention, generating an authentication confirmation message based on the two-way authentication status includes:

[0161] S901, Extract the session identifier associated with the valid two-way authentication status in the two-way authentication status;

[0162] S902, convert the session identifier into the original confirmation message of the authentication request device;

[0163] S903, perform lightweight encryption on the original confirmation message to obtain an authentication confirmation message.

[0164] It should be noted that the conversion of the original acknowledgment message is carried out using a 128-bit shift register chain operation. The 32-bit timestamp is loaded from the RTC module to register bits 0-31, the 48-bit response device MAC is loaded from the ID cache to bits 32-79, the 48-bit request device MAC is loaded from the ID cache to bits 80-127, and the 8-bit version number is loaded from the ROM firmware to overwrite bits 120-127, so as to obtain the 128-bit original acknowledgment message.

[0165] It should be noted that lightweight encryption involves concatenating the dynamic session key and the initial challenge value into a 136-bit data string, inputting it into the SHA-256 engine to perform one-way hashing to generate a 256-bit digest, extracting the high 128 bits as the key stream using the truncation circuit, and then performing a bitwise XOR operation between the original message and the key stream based on the key stream encryption unit to complete lightweight encryption.

[0166] like Figure 2 The diagram shown is a functional block diagram of a lightweight two-way authentication system for IoT device identification provided in an embodiment of the present invention.

[0167] The lightweight two-way authentication system 100 for IoT device identification described in this invention can be installed in an electronic device. Depending on the functions implemented, the lightweight two-way authentication system 100 for IoT device identification may include an identifier mapping module 101, a distributed token generation module 102, a two-way authentication module 103, an authentication validity identification module 204, an authentication failure handling module 105, and an authentication message generation module 106. The module described in this invention can also be referred to as a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0168] In this embodiment, the functions of each module / unit are as follows:

[0169] The identifier mapping module is used to map the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key;

[0170] The distributed token generation module is used to execute a distributed challenge-response protocol on the dynamic session key to obtain the dynamic token of the authentication response device.

[0171] The two-way authentication module is used to perform consistency verification between the dynamic token and the expected token of the authentication request device in order to obtain the two-way authentication status of the authentication request device.

[0172] The authentication validity identification module is used to identify the validity of the two-way authentication status. When the two-way authentication status is invalid, step S5 is executed, and when the two-way authentication status is valid, step S6 is executed.

[0173] The authentication failure processing module is used to extract failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features.

[0174] The authentication message generation module is used to generate an authentication confirmation message based on the two-way authentication status.

[0175] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0176] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0177] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0178] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0179] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0180] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A lightweight two-way authentication method for IoT device identification, characterized in that, The method includes: S1, mapping the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key, including: The device identifiers of the authentication response device and the authentication request device are standardized to obtain standard device identifiers for the authentication response device and the authentication request device. The standard device identifier is input into a preset hash function to obtain the encrypted device identifier of the standard device identifier; The encrypted device identifier is subjected to a one-way encrypted mapping process to obtain the initial session key of the standard device identifier; The initial session key is reduced in length to obtain a dynamic session key; S2, Execute a distributed challenge-response protocol on the dynamic session key to obtain the dynamic token of the authentication response device, including: The dynamic session key is input into a preset random number generator to obtain the initial challenge value of the authentication request device; Perform a bit-width expansion mapping operation on the initial challenge value to obtain an expanded challenge vector; Based on the dynamic session key and the extended challenge vector, an XOR obfuscation operation is performed on the authentication request device to obtain the request-side dynamic token of the authentication request device. After receiving the initial challenge value, the authentication response device performs steps S402-S403 to obtain the local dynamic token of the authentication response device. The requesting dynamic token and the local dynamic token are exchanged to obtain the dynamic token of the authentication response device; S3, perform consistency verification on the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device; S4, perform validity identification on the two-way authentication status. When the two-way authentication status is invalid, proceed to step S5. When the two-way authentication status is valid, proceed to step S6, including: Read the status value from the two-way authentication status; The validity of the state value is determined to obtain a state flag; Based on the state flag, a branch decision operation is performed on the state value. If the result of the branch decision operation is an invalid flag value, step S5 is triggered. If the result of the branch decision operation is a valid flag value, step S6 is triggered, including: Failure records are extracted from the results of the validity identification to obtain the time-series failure dataset of the authentication request device; Based on a preset defect tracing algorithm, defect indicators are calculated on the time series failure dataset to obtain the defect quantification indicators of the authentication request device. The mathematical expression of the defect tracing algorithm is as follows: ； In the formula, For the quantification of defects, The number of failed records. Index for failure records, The time decay weighting coefficient for the k-th failed record. This is the difference metric for the k-th failed record; Defect features are extracted from the defect quantification indicators to obtain the authentication defect features of the authentication requesting device; S5, extract the failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features; S6, Generate an authentication confirmation message based on the two-way authentication status.

2. The lightweight two-way authentication method for IoT device identification as described in claim 1, characterized in that, The standardization process for the device identifiers of the authentication response device and the authentication request device to obtain standard device identifiers for the authentication response device and the authentication request device includes: Load the original device identifiers of the authentication response device and the authentication request device; Perform character cleaning operation on the original device identifier to generate an intermediate device identifier between the authentication response device and the authentication request device; The intermediate device identifier is subjected to a fixed-length normalization conversion process to obtain the standard device identifiers of the authentication response device and the authentication request device.

3. The lightweight two-way authentication method for IoT device identification as described in claim 1, characterized in that, The step of verifying the consistency between the dynamic token and the expected token of the authentication request device to obtain the two-way authentication status of the authentication request device includes: The dynamic token and the expected token are converted into binary to obtain a dynamic token binary string and an expected token binary string, respectively. Calculate the difference metric between the dynamic token binary string and the expected token binary string; A zero threshold judgment is performed on the difference metric value to obtain the two-way authentication status of the authentication request device.

4. The lightweight two-way authentication method for IoT device identification as described in claim 1, characterized in that, The optimization of the distributed challenge-response protocol based on the authentication defect characteristics includes: The authentication defect characteristics are analyzed to obtain the defect type of the authentication requesting device; The defect type is optimized based on a preset protocol parameter dynamic adjustment algorithm to obtain an optimized parameter set for the authentication defect features; The optimized parameter set is injected into the protocol register of the distributed challenge-response protocol.

5. The lightweight two-way authentication method for IoT device identification as described in claim 1, characterized in that, The generation of the authentication confirmation message based on the two-way authentication status includes: Extract the session identifier associated with the valid two-way authentication status from the two-way authentication status; The session identifier is converted into the original confirmation message of the authentication request device; The original confirmation message is lightly encrypted to obtain an authentication confirmation message.

6. A lightweight two-way authentication system for identifying Internet of Things (IoT) devices, characterized in that, The system includes: The identifier mapping module is used to map the encrypted device identifiers of the authentication response device and the authentication request device to a dynamic session key, including: The device identifiers of the authentication response device and the authentication request device are standardized to obtain standard device identifiers for the authentication response device and the authentication request device. The standard device identifier is input into a preset hash function to obtain the encrypted device identifier of the standard device identifier; The encrypted device identifier is subjected to a one-way encrypted mapping process to obtain the initial session key of the standard device identifier; The initial session key is reduced in length to obtain a dynamic session key; A distributed token generation module, used to execute a distributed challenge-response protocol on the dynamic session key to obtain a dynamic token from the authentication response device, includes: The dynamic session key is input into a preset random number generator to obtain the initial challenge value of the authentication request device; Perform a bit-width expansion mapping operation on the initial challenge value to obtain an expanded challenge vector; Based on the dynamic session key and the extended challenge vector, an XOR obfuscation operation is performed on the authentication request device to obtain the request-side dynamic token of the authentication request device. After receiving the initial challenge value, the authentication response device performs steps S402-S403 to obtain the local dynamic token of the authentication response device. The requesting dynamic token and the local dynamic token are exchanged to obtain the dynamic token of the authentication response device; A two-way authentication module is used to verify the consistency between the dynamic token and the expected token of the authentication request device in order to obtain the two-way authentication status of the authentication request device. The authentication validity identification module is used to identify the validity of the two-way authentication status. When the two-way authentication status is invalid, step S5 is executed; when the two-way authentication status is valid, step S6 is executed, including: Read the status value from the two-way authentication status; The validity of the state value is determined to obtain a state flag; Based on the state flag, a branch decision operation is performed on the state value. If the result of the branch decision operation is an invalid flag value, step S5 is triggered. If the result of the branch decision operation is a valid flag value, step S6 is triggered, including: Failure records are extracted from the results of the validity identification to obtain the time-series failure dataset of the authentication request device; Based on a preset defect tracing algorithm, defect indicators are calculated on the time series failure dataset to obtain the defect quantification indicators of the authentication request device. The mathematical expression of the defect tracing algorithm is as follows: ； In the formula, For the quantification of defects, The number of failed records. Index for failure records, The time decay weighting coefficient for the k-th failed record. This is the difference metric for the k-th failed record; Defect features are extracted from the defect quantification indicators to obtain the authentication defect features of the authentication requesting device; The authentication failure handling module is used to extract failure records from the validity identification results, trace the failure records of the authentication request device based on the failure records to obtain authentication defect features, and optimize the distributed challenge-response protocol based on the authentication defect features. The authentication message generation module is used to generate an authentication confirmation message based on the two-way authentication status.

Images