A device authentication method, system, device and storage medium

Abstract

The application discloses a device authentication method, system, device and storage medium, relates to the technical field of information security, and solves the specific problem of device identity authentication in a resource-constrained scene such as the Internet of Things. A challenge-response data set is established through a pre-registration mechanism, so that an authenticator can complete verification without knowing the internal symmetric key of the device, thereby significantly reducing the key management complexity and leakage risk. Through the design of locally generating and keeping the key by the device, pre-storing a limited number of challenge-response pairs, and comparing the hash value instead of the plaintext response value, the anti-replay attack capability is ensured, and the calculation, storage overhead and communication load of the device end are effectively controlled. A new challenge-response data set is independently established, so that the device can still realize safe identity verification in a closed network or a specific application environment, the mandatory dependence on the key management system of the device manufacturer is reduced, and the flexibility and applicability of the authentication mechanism are enhanced.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a device authentication method, system, device, and storage medium. Background Technology

[0002] In the current era of rapid development of IoT technology, device authentication is a core component for ensuring the security of IoT systems, and the choice of its technical solution directly affects the system's security, energy consumption, and resource adaptability. Currently, the mainstream authentication technologies for IoT devices are mainly divided into two categories: public-key cryptography and symmetric cryptography. Meanwhile, Physically Unclonable Authentication (PUF) technology based on hardware physical characteristics is also being applied in specific scenarios. Public-key cryptography relies on classic algorithms such as RSA and ECC, or quantum-resistant signature algorithms such as Dilithium, to achieve identity verification through digital signatures. It does not require pre-shared keys and supports non-repudiation; for example, a device can prove its identity by using its public-private key pair to sign a message with its private key. Symmetric cryptography relies on algorithms such as AES and HMAC, requiring the device and the authenticator to share a symmetric key in advance. Authentication is completed through encryption or message authentication codes, offering advantages such as high computational speed and low energy consumption. Pre-shared key authentication is a typical application. PUF authentication technology utilizes microscopic physical differences in the hardware manufacturing process to form a "physical fingerprint," achieving authentication based on a "challenge-response pair (CRP)" mechanism. It does not require pre-stored fixed keys and is suitable for scenarios with strong anti-cloning requirements.

[0003] However, existing IoT device authentication technologies still have many problems and are difficult to fully adapt to the needs of various IoT scenarios. For public-key cryptography, its algorithm computational complexity is high, and the key and parameter sizes are large, placing stringent requirements on the CPU and memory resources of the device. When running on extremely low-power IoT devices, it will significantly increase energy consumption and shorten battery life. Moreover, traditional public-key algorithms are threatened by quantum computing, and quantum-resistant public-key algorithms currently have even worse performance and larger parameter sizes, making them difficult to implement on resource-constrained devices. Although symmetric cryptography has advantages in energy consumption and resource overhead, it has obvious key management risks and manufacturer dependence issues: symmetric keys are usually generated and written to the device by an external key management system. Centralized key storage or seed keys are prone to leakage, and there are also security risks in the key delivery and verification process. At the same time, the verifier must rely on the manufacturer to provide keys or authentication service interfaces. If the manufacturer refuses to provide them or the verifier cannot receive relevant information, authentication cannot be performed. Furthermore, due to the key-sharing nature of this technology, it lacks non-repudiation, making it difficult to trace the responsible party for security incidents. Although PUF authentication technology does not require pre-stored keys, it relies too heavily on the physical characteristics of hardware. Its "physical fingerprint" is easily affected by environmental factors, resulting in insufficient stability. Furthermore, it has high requirements for hardware manufacturing processes, limiting its applicable scenarios and failing to fully cover the diverse authentication needs of IoT devices. Summary of the Invention

[0004] The main objective of this invention is to provide a device authentication method, system, device, and storage medium. It addresses the specific challenges of device authentication in resource-constrained scenarios such as the Internet of Things (IoT). By establishing a challenge-response dataset through a pre-registration mechanism, the authenticator can complete verification without knowing the device's internal symmetric key, significantly reducing key management complexity and leakage risk. It avoids the use of computationally expensive asymmetric cryptographic algorithms, achieving a targeted balance between security and resource consumption. Through designs such as locally generating and storing keys on the device, pre-storing a limited number of challenge-response pairs, and comparing hash values ​​instead of plaintext response values, it effectively controls the computational, storage, and communication load on the device while ensuring resistance to replay attacks. By independently establishing a new challenge-response dataset, the device can still achieve secure authentication in closed networks or specific application environments, reducing the mandatory dependence on the device manufacturer's key management system and enhancing the flexibility and applicability of the authentication mechanism.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0006] According to a first aspect of the embodiments of this application, a device authentication method is provided, the method comprising:

[0007] In response to an authentication request for the target device, the authentication server obtains the identifier of the target device;

[0008] Based on the identifier, a challenge value is determined from a pre-established challenge-response dataset corresponding to the identifier and sent to the target device; wherein, the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device through cryptographic operations on the challenge value based on an internally generated symmetric key;

[0009] The verification data received from the target device is generated by the target device after performing the cryptographic operation based on the challenge value and the symmetric key.

[0010] The verification data is compared with the response value corresponding to the challenge value determined in the challenge response dataset, and the identity of the target device is determined based on the comparison result.

[0011] Optionally, after determining that the target device is authentic, the method further includes:

[0012] The authentication server generates a first random number and encrypts the first random number using the response value in the challenge response dataset that corresponds to the determined challenge value, and sends the encrypted first data to the target device.

[0013] The target device uses the response value to decrypt the first encrypted data to obtain the first random number; and generates a second random number, uses the response value to encrypt the second random number, and sends the encrypted second encrypted data to the authentication server;

[0014] The authentication server uses the response value to decrypt the second encrypted data to obtain the second random number;

[0015] The authentication server and the target device each generate the same session key based on the first random number and the second random number, using a predefined key derivation function.

[0016] Optionally, the method for pre-building the challenge-response dataset includes:

[0017] The authentication server sends several preset challenge values ​​to the target device, so that the target device uses the symmetric key to encrypt or calculate a message authentication code for each preset challenge value, generates a corresponding response value, and sends it to the authentication server; the preset challenge values ​​are generated independently and randomly, or generated by key distribution based on the seed key of the authentication server and the identifier of the target device;

[0018] The identifier of the target device is associated with and stored in a challenge-response dataset consisting of several preset challenge values ​​and corresponding response values.

[0019] Optionally, based on the identifier, the challenge value is determined from a pre-established challenge-response dataset corresponding to the identifier, including:

[0020] Retrieve the value of the current index pointer associated with the challenge response dataset;

[0021] Based on the value of the current index pointer, select the corresponding challenge value from the challenge response dataset;

[0022] After completing this selection, the value of the current index pointer is incremented by 1; when the value of the current index pointer exceeds the total number of data pairs in the challenge response dataset, the current index pointer is reset to the initial value.

[0023] Optionally, each data pair in the challenge-response dataset is attached with a timestamp label to record the last time the data pair was used; the data pair includes a challenge value and a corresponding response value; the step of determining the challenge value from the pre-established challenge-response dataset corresponding to the identifier includes:

[0024] Get the current system time;

[0025] From the challenge response dataset, select all data pairs that satisfy the condition that the difference between the current system time and the timestamp tag record is greater than a preset threshold to form a first candidate set;

[0026] Randomly select a data pair from the first candidate set and update the timestamp label of the selected data pair to the current system time.

[0027] Optionally, each data pair in the challenge response dataset is attached with a usage status label, which includes unused and used; based on the identifier, the challenge value is determined from the pre-established challenge response dataset corresponding to the identifier, including:

[0028] From the challenge response dataset, all data pairs whose usage status labels indicate that they are not used are selected to form a second candidate set;

[0029] Randomly select a data pair from the second candidate set and update the usage status label of the selected data pair to "used".

[0030] Optionally, the verification data is the hash value of the response value calculated by the target device; comparing the verification data with the response value corresponding to the challenge value determined in the challenge response dataset includes:

[0031] Calculate the hash value of the response value corresponding to the determined challenge value in the challenge response dataset;

[0032] The hash value is matched and verified with the received verification data. If the verification matches, the comparison is considered successful; otherwise, the comparison is considered unsuccessful.

[0033] According to a second aspect of the embodiments of this application, a device authentication system is provided, the system comprising:

[0034] The message acquisition module is used to obtain the identifier of the target device in response to an authentication request for the target device;

[0035] The challenge value determination module is used to determine a challenge value from a pre-established challenge-response dataset corresponding to the identifier based on the identifier and send it to the target device; wherein, the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device by performing cryptographic operations on the challenge value based on an internally generated symmetric key;

[0036] The message receiving module is used to receive the verification data of the target device, wherein the verification data is generated by the target device after performing the cryptographic operation based on the challenge value and the symmetric key;

[0037] The comparison module is used to compare the verification data with the response value corresponding to the challenge value determined in the challenge response dataset, and to determine whether the identity of the target device is genuine based on the comparison result.

[0038] According to a third aspect of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0039] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having computer-readable instructions stored thereon, the computer-readable instructions being executable by a processor to implement the method described in the first aspect above.

[0040] In summary, this application provides a device authentication method, system, device, and storage medium. In response to an authentication request for a target device, the authentication server obtains the identifier of the target device; based on the identifier, it determines a challenge value from a pre-established challenge-response dataset corresponding to the identifier and sends it to the target device; wherein the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device through cryptographic operations on the challenge value based on an internally generated symmetric key; the server receives verification data from the target device, wherein the verification data is generated by the target device through the cryptographic operations on the challenge value and the symmetric key; the verification data is compared with the response value corresponding to the challenge value determined in the challenge-response dataset, and the authenticity of the target device's identity is determined based on the comparison result. This application solves a specific problem of device identity authentication in resource-constrained scenarios such as the Internet of Things. By establishing a challenge-response dataset through a pre-registration mechanism, the authenticator can complete the verification without knowing the device's internal symmetric key, thereby significantly reducing the complexity of key management and the risk of leakage. It avoids the use of computationally intensive asymmetric cryptographic algorithms, specifically balancing security and resource consumption. By generating and storing keys locally on the device, pre-storing a limited number of challenge-response pairs, and comparing hash values ​​instead of plaintext response values, the design effectively controls the computational, storage, and communication load on the device while ensuring resistance to replay attacks. By independently establishing a new challenge-response dataset, the device can still achieve secure authentication in closed networks or specific application environments, reducing the mandatory dependence on the device manufacturer's key management system and enhancing the flexibility and applicability of the authentication mechanism. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0042] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0043] Figure 1 This is a schematic diagram of a device authentication method provided in an embodiment of this application;

[0044] Figure 2 The process of establishing a challenge-response dataset during equipment production provided in this application embodiment;

[0045] Figure 3 This is a schematic diagram illustrating the process of establishing a challenge-response dataset for a black-box device, as provided in an embodiment of this application.

[0046] Figure 4 A schematic diagram of the device authentication process provided in this application embodiment;

[0047] Figure 5 A schematic diagram illustrating the process of device authentication and session key negotiation provided in this application embodiment;

[0048] Figure 6 This is a schematic diagram of a device authentication system provided in an embodiment of this application;

[0049] Figure 7 This paper shows a structural diagram of an electronic device provided in an embodiment of this application;

[0050] Figure 8 A diagram of a computer-readable storage medium provided in an embodiment of this application is shown.

[0051] 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

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0053] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0054] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0055] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0056] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0057] Figure 1 This application illustrates a device authentication method provided in an embodiment, the method comprising:

[0058] Step 101: In response to the authentication request for the target device, the authentication server obtains the identifier of the target device;

[0059] Step 102: Based on the identifier, determine the challenge value from the pre-established challenge-response dataset corresponding to the identifier and send it to the target device; wherein, the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device by performing cryptographic operations on the challenge value based on an internally generated symmetric key;

[0060] Step 103: Receive the verification data from the target device, wherein the verification data is generated by the target device after performing the cryptographic operation based on the challenge value and the symmetric key;

[0061] Step 104: Compare the verification data with the response value corresponding to the challenge value determined in the challenge response dataset, and determine whether the identity of the target device is genuine based on the comparison result.

[0062] In one possible implementation, the method for pre-establishing the challenge-response dataset includes: the authentication server sending a number of preset challenge values ​​to the target device, so that the target device uses the symmetric key to encrypt or calculate a message authentication code for each preset challenge value, generates a corresponding response value, and sends it to the authentication server; the preset challenge values ​​are generated independently and randomly, or generated by key distribution based on the seed key of the authentication server and the identifier of the target device; the identifier of the target device is associated with and stored in the challenge-response dataset consisting of the number of preset challenge values ​​and the corresponding response values.

[0063] By pre-generating and storing challenge-response pairs, the authentication server can quickly verify the device's identity during subsequent authentication processes without requiring real-time computation or reliance on plaintext storage of device keys, thus significantly reducing authentication latency and server computational overhead. This approach is particularly suitable for resource-constrained IoT devices, as it offloads computationally intensive operations (such as encryption or MAC calculations) to the registration phase, reducing energy consumption and communication burden during authentication, while enhancing resistance to replay attacks through the randomness of challenge values ​​or the dispersed generation of keys.

[0064] This implementation offers flexible security configuration through two challenge value generation strategies: independent random generation or key distribution based on a seed key and device identifier. Random generation ensures the unpredictability of challenge values, while key distribution allows the authentication server to derive challenge values ​​based on unique device identifiers, enabling manageable scalable deployment. Furthermore, the authentication server stores only the response value, not the device key, reducing the risk of key leakage, adhering to the principle of least privilege, and ensuring both high security and operational efficiency throughout the authentication process. Overall, by providing offline authentication support through a pre-built dataset, it offers a reliable device authentication solution for closed networks or low-power scenarios. It not only reduces reliance on online authentication but also ensures data integrity and confidentiality through cryptographic means, laying a solid foundation for subsequent session key negotiation or other secure interactions.

[0065] In one possible implementation, in step 102, determining a challenge value from a pre-established challenge-response dataset corresponding to the identifier, based on the identifier, includes: obtaining the value of the current index pointer associated with the challenge-response dataset; selecting a corresponding challenge value from the challenge-response dataset according to the value of the current index pointer; incrementing the value of the current index pointer by 1 after completing this selection; and resetting the current index pointer to its initial value when the value of the current index pointer exceeds the total number of data pairs in the challenge-response dataset.

[0066] In one embodiment of the device authentication method, step 102 involves determining a challenge value from a pre-established challenge-response dataset. This process specifically includes the following sub-steps to achieve efficient and ordered challenge value selection, ensuring the reliability of the authentication process and resistance to replay attacks: The authentication service first reads the current index pointer maintained by the challenge-response dataset associated with the target device identifier. This pointer is an integer value, initially typically set to 1 (pointing to the first data pair), and stored in the authentication service's database or memory to track the position of the currently used data pair. The authentication service uses the value of the current index pointer as an index to directly retrieve the corresponding challenge value from the challenge-response dataset. For example, if the pointer value is 3, the challenge value from the third challenge-response pair in the dataset is selected. After completing this challenge value selection and sending it to the device, the authentication service increments the value of the current index pointer by 1 (i.e., an increment operation) to point to the next data pair, preparing for subsequent authentication requests. If the incremented index pointer value exceeds the total number of data pairs in the challenge-response dataset (e.g., the pointer value becomes N+1, where N is the total number of datasets), the authentication service resets the pointer to a preset initial value (e.g., 1), thereby achieving cyclical use of data pairs. This ensures that authentication can continue without exhausting challenge values, even with a limited dataset size.

[0067] In one possible implementation, in step 102, each data pair in the challenge-response dataset is attached with a timestamp tag to record the last time the data pair was used; the data pair includes a challenge value and a corresponding response value; determining the challenge value from the pre-established challenge-response dataset corresponding to the identifier based on the identifier includes: obtaining the current system time; filtering out all data pairs from the challenge-response dataset that satisfy the condition that the difference between the current system time and the time recorded by the timestamp tag is greater than a preset threshold, forming a first candidate set; randomly selecting a data pair from the first candidate set, and updating the timestamp tag of the selected data pair to the current system time.

[0068] In one implementation of the device authentication method, step 102 manages the usage status of the challenge-response dataset using timestamp tags, implementing a time-window-based anti-replay attack strategy. This mechanism ensures the secure reuse of challenge values ​​through dynamic filtering and random selection. In the challenge-response dataset, each data pair (containing a challenge value and its corresponding response value) is appended with a timestamp tag, initially empty or the registration time. This tag is used to accurately record the last usage time of the data pair. After obtaining the current system time, the authentication service iterates through the dataset and filters data pairs that meet the following condition: current system time - timestamp tag recording time > preset threshold T; where the threshold T can be configured according to security requirements (e.g., 30 days). Data pairs that have never been used (with empty timestamps) meet the condition by default. A data pair is randomly selected from the first candidate set after filtering to ensure the unpredictability of the challenge value. After selection, the timestamp tag of the data pair is immediately updated to the current system time, marking this usage record.

[0069] The threshold T can be dynamically adjusted based on the device's risk level. For example, when abnormal access is detected, the time window is automatically shortened to improve the security level. By using the time threshold, the reuse of challenge values ​​within a short period of time is prevented, so even if an attacker intercepts authentication data, they cannot replay it within the effective time window. If the candidate set of the time window strategy is empty (i.e., all data pairs have been used within the threshold), it can automatically switch to a sequential traversal strategy to ensure that the authentication process is not interrupted.

[0070] In one possible implementation, in step 102, each data pair in the challenge response dataset is attached with a usage status label, which includes unused and used; based on the identifier, the challenge value is determined from the pre-established challenge response dataset corresponding to the identifier, including: filtering out all data pairs whose usage status labels indicate that they are unused from the challenge response dataset to form a second candidate set; randomly selecting a data pair from the second candidate set and updating the usage status label of the selected data pair to used.

[0071] In one implementation of the device authentication method, step 102 implements a strict anti-replay attack strategy by managing the lifecycle of the challenge-response dataset using status labels ("unused" / "used"). This mechanism ensures that each challenge value is used only once through status filtering and random selection. During the challenge-response dataset construction phase, each data pair (containing a challenge value and its corresponding response value) is marked as "unused," forming an initially available authentication resource pool. After locating the dataset based on the target device identifier, the authentication service first filters all data pairs with the status label "unused," forming a second candidate set. This step ensures that only unused legitimate challenge values ​​participate in the selection. A data pair is randomly selected from the second candidate set (e.g., through a pseudo-random algorithm), and its status label is immediately updated to "used" after determining that the challenge value will be used. This action is atomic, preventing state conflicts in concurrent authentication scenarios.

[0072] In one possible implementation, in step 104, the verification data is the hash value of the response value calculated by the target device; comparing the verification data with the response value corresponding to the determined challenge value in the challenge response dataset includes: calculating the hash value of the response value corresponding to the determined challenge value in the challenge response dataset; matching and verifying the hash value with the received verification data, if the verification matches, the comparison is deemed successful, if the verification does not match, the comparison is deemed unsuccessful.

[0073] In one implementation of the device authentication method, step 104 completes device authentication through a hash value comparison mechanism. This method ensures the security of the verification process through a cryptographic hash function. Specifically, it includes two key steps: response value hash calculation and two-way matching verification. After receiving the challenge value, the target device uses its internal symmetric key to perform cryptographic operations to generate a response value (R'), and then calculates the hash value of this response value (such as the SHA-256 result) as verification data. This ensures that the plaintext of the response value is not exposed in the communication link, effectively preventing man-in-the-middle attackers from directly obtaining valid response information. Based on the determined challenge value, the authentication service extracts the corresponding response value (R) from the locally stored challenge-response dataset and calculates the hash value of this response value. Here, the response value (R) is a baseline value pre-calculated and stored during the registration phase, serving as a reference standard for verification. The authentication service precisely matches the received verification data (the hash value returned by the device) with the locally calculated response value hash value. A match indicates that the response value (R') returned by the device completely matches the pre-stored response value (R), thus deducing that the device holds the correct symmetric key, determining the device's authenticity, and passing authentication. Inconsistent verification indicates that the response value does not match the expected value, which determines that the device does not possess a legitimate key or is a counterfeit device, resulting in authentication failure.

[0074] By transmitting hash values ​​instead of plaintext response values, attackers cannot directly obtain valid response information even if the communication process is eavesdropped on. The one-way nature of hash functions prevents the response value from being reverse-engineered, significantly improving resistance to replay attacks. The device only needs to perform a hash calculation once, and the authentication service only needs to perform a simple hash comparison. Compared to complex asymmetric cryptographic operations such as digital signature verification, this greatly reduces computational overhead, making it particularly suitable for resource-constrained IoT devices.

[0075] In one possible implementation, after step 104, the method further includes: the authentication server sends a challenge value to the target device and then starts timing; if no verification data is received from the target device within a preset response time threshold, the authentication of the target device is directly determined to have failed.

[0076] After the authentication server sends the challenge value to the target device, it immediately starts a timer to begin precise timing. The timer can be implemented using a system-level high-precision clock or a dedicated hardware timing unit to ensure the accuracy of time measurement. The preset response time threshold is configured according to the actual application scenario (typically 3-15 seconds). If no verification data is received when the timer reaches the preset threshold, the current authentication session is immediately terminated, and an authentication failure record is generated. This decision is final and does not require waiting for subsequent data packets.

[0077] In one possible implementation, after step 104, after determining the authenticity of the target device, the method further includes: the authentication server generating a first random number, encrypting the first random number using the response value in the challenge-response dataset corresponding to the determined challenge value, and sending the encrypted first encrypted data to the target device; the target device decrypting the first encrypted data using the response value to obtain the first random number; generating a second random number, encrypting the second random number using the response value, and sending the encrypted second encrypted data to the authentication server; the authentication server decrypting the second encrypted data using the response value to obtain the second random number; and the authentication server and the target device generating the same session key based on the first random number and the second random number using a predefined key derivation function.

[0078] In one implementation of the device authentication method, step 104 (i.e., after successful device authentication) integrates a session key negotiation phase. This extension aims to achieve seamless integration of authentication and key exchange by reusing cryptographic materials from the challenge-response data to efficiently generate temporary session keys while ensuring identity authenticity. This process enhances the confidentiality and integrity of subsequent communications and is suitable for IoT scenarios requiring the establishment of secure channels.

[0079] The authentication server first generates a high-entropy first random number (e.g., a 128-bit random value) as the seed material for the session key. Then, it encrypts this random number using the response value (R) corresponding to the sent challenge value from the challenge-response dataset (e.g., using AES-256 encryption), generating the first encrypted data (EncA). This step ensures the random number is protected during transmission and can only be decrypted by a device holding the correct key. Upon receiving the first encrypted data (EncA), the target device decrypts it using its response value (R'), which it calculates in real-time based on the challenge value, to restore the first random number. The device then independently generates a second random number (also with high-entropy characteristics) and encrypts it using the response value (R'), generating the second encrypted data (EncB) and returning it to the authentication server. This process achieves bidirectional entropy exchange and avoids plaintext key transmission throughout. The authentication server decrypts the second encrypted data (EncB) using the pre-stored response value (R) to obtain the second random number. At this point, both parties possess the first and second random numbers. Using a predefined key derivation function (such as HKDF or PBKDF2), the authentication server and the target device generate the same session key based on these two random numbers (e.g., by concatenating and hashing: sk=Hash(A||B)).

[0080] This application's embodiments implement a symmetric key authentication mechanism for device identity authentication and session key negotiation by pre-stored challenge-response datasets. Unlike existing technologies, in this mechanism, the device authentication key is not generated by the manufacturer's key management system and then imported into the device; instead, it is generated internally within the device, and no external system needs to know the content of the symmetric key. This supports rebuilding the device authentication mechanism without manufacturer involvement. It is suitable for devices such as ultra-low power, long-battery-life IoT sensors; and for achieving secure device authentication in scenarios where the device manufacturer cannot provide authentication keys or authentication services. The aim is to provide an authentication mechanism for verifying the authenticity of device identity and negotiating session keys, solving the following technical problems:

[0081] 1. Low energy consumption: Use low-energy symmetric cryptography on low-power devices to extend device battery life.

[0082] 2. Low resource consumption: Using symmetric cryptography on resource-constrained devices reduces the overhead of key data storage and authentication data communication.

[0083] 3. Post-quantum cryptography security: Select a symmetric cryptography algorithm and key length that support post-quantum cryptography security.

[0084] 4. Reduce key exposure: Reduce the exposure of symmetric keys in external systems and avoid the risk of leakage caused by centralized key management; the verifier does not need to directly obtain or store device keys, reducing the complexity and security risks of sharing keys between different systems.

[0085] 5. Anti-replay security: Anti-replay attack is achieved by determining the challenge value from multiple pre-stored challenge-response data pairs; the amount of pre-stored data can be flexibly adjusted according to the required security strength, reducing storage and management costs while meeting security requirements.

[0086] 6. Support for authentication of black-box devices: In some cases, due to reasons such as closed networks, data isolation, or even commercial factors, although there are authentication keys in the device, the authenticator cannot obtain these keys from the manufacturer, nor can it call the manufacturer's authentication service interface; in this case, this application can provide a device authentication mechanism that does not require the manufacturer's participation.

[0087] To more clearly demonstrate its specific workflow and the interaction process between the parties, the following will describe the implementation step by step with reference to the authentication process diagram shown in the attached figures.

[0088] The symmetric key authentication mechanism based on pre-stored challenge-response data proposed in this application's embodiments has the core idea of ​​follows: During the device's production process, the authentication service pre-determines multiple sets of challenge values. The device uses its own generated symmetric key to process the challenge values ​​and obtain response values. The authentication service records each set of challenge values ​​and its corresponding response value. During device use: When device legitimacy authentication is required, the authentication service sends a pre-stored challenge value to the device and verifies whether the response value returned by the device is correct. When session key negotiation is required, the authentication service sends a pre-stored challenge value to the device, and both the authentication service and the device generate session keys based on the response values ​​corresponding to that challenge value.

[0089] The technical solutions in this application involve the following roles:

[0090] 1. Manufacturer: In some application scenarios, the device manufacturer (producing hardware) and the device distributor (personalizing devices and generating device keys) are different entities. Here, we do not strictly distinguish between these two roles and refer to them collectively as "manufacturer". This article refers to all production and personalization processes of both the manufacturer and the distributor as the "production process".

[0091] 2. Device: An entity that possesses a unique identifier and device authentication key.

[0092] 3. Authentication Service: During the production phase, the authentication service establishes a challenge-response dataset for each device; during the usage phase, the authentication service verifies the authenticity of the device and negotiates a session key with the device. Device authenticity means that a device can prove that it possesses an authentication key, and that this key correctly corresponds to the unique identifier it presents.

[0093] Figure 2This illustrates the process of establishing a challenge-response dataset during equipment manufacturing. In the equipment manufacturing phase, the authentication service collaborates with the equipment to establish this dataset, which forms the basis for subsequent equipment authentication and session key negotiation. Specifically, the process includes the following steps:

[0094] Step 1: The device generates a symmetric key K. During the production process, the device generates a symmetric key K, which possesses post-quantum cryptographic security and is stored only internally within the device, never exported to any external entity (including the manufacturer). Optional key types include AES-256, HMAC-SHA256, and AES-256-CMAC keys, etc. The key length design must consider security redundancy under quantum attacks.

[0095] Step 2: The authentication service reads the device's unique identifier (DevID); the authentication service sends a request to the device to "read the device's unique identifier", and the device returns its own unique identifier, DevID, which is used for subsequent association and storage of the dataset.

[0096] Step 3: Generate and interact with "challenge value response value" pairs;

[0097] Step 3-1: The authentication service generates a challenge value Ci. There are two methods: Method a: Each Ci is an independent random data set; Method b: Key distribution is performed using the "authentication service seed key + device DevID" to obtain a device-specific challenge value seed, which is then further distributed using the challenge value index number to obtain Ci. The challenge value length is typically 16 bytes (e.g., to accommodate AES algorithm block sizes) to balance entropy requirements with energy consumption and communication resource overhead.

[0098] Step 3-2: The device calculates the response value Ri. After receiving the challenge value Ci, the device performs encryption or MAC calculation on Ci using the internal key K: If an encryption algorithm is used, Ri = ENC(K, Ci) (such as AES encryption); if a message authentication code algorithm is used, Ri = MAC(K, Ci) (such as HMAC-SHA256, AES-CMAC).

[0099] Step 3-3: Device returns response value Ri. The device returns the calculated response value Ri to the authentication service.

[0100] Step 4: The authentication service stores the challenge-response dataset; after collecting all "Ci-Ri" data pairs, the authentication service binds and stores them with the device's unique identifier, DevID. This dataset is the device's "identity fingerprint," which the authentication service must securely store, ensuring its confidentiality and integrity. It cannot be modified after generation, and only the authentication service has access to it.

[0101] In summary, this process, through its design of "device-developed keys + multiple challenge-response pairs," ensures key security (by preventing external export) while providing a verifiable "digital fingerprint" for subsequent authentication, thus mitigating the centralized key management risks of traditional symmetric key authentication. The number of data pairs in a device's challenge-response dataset can be flexibly configured during production based on the device's characteristics and security requirements. For example:

[0102] Scenario A: High-Security Target, High-Frequency Authentication Scenario Background: The device has a 10-year lifespan and is designed to perform device authentication once per hour, with each authentication using a different challenge value (to prevent replay attacks and meet high security requirements). Data Pair Quantity Calculation: Total hours over 10 years = (10 × 365 × 24 = 87600), therefore 87,600 challenge-response data pairs are required. Storage Overhead Analysis: If each challenge value and response value is stored directly (16 bytes each): Total storage = (87600 × (16 + 16)) bytes = (87600 × 32) bytes ≈ 2.7MB. If the challenge value is derived based on "seed + index number" (only the seed and response value are stored): Total storage = 16 (seed) + (87600 × 16) (response value) ≈ 1.3MB. Applicable scenarios: Devices with extremely high security requirements (such as industrial control equipment and medical IoT terminals) that require frequent authentication and absolutely avoid replay attacks.

[0103] Scenario b: Medium security target, low-frequency authentication scenario. Background: The device only performs authentication during low-frequency management and configuration. The security target is "medium," requiring only that the challenge value not be reused in the recent period. Data pair calculation: Selecting (N=100) challenge-response data pairs is sufficient to support the authentication requirements in a low-frequency scenario. Storage overhead analysis: Storing 100 challenge-response pairs (16 bytes each): Total storage = (100 times (16+16)) bytes = 3200 bytes ≈ 3KB. Applicable scenario: For devices with moderate security requirements and low authentication frequency (such as the management and configuration phase of consumer-grade smart home devices), basic authentication requirements are met with minimal storage overhead.

[0104] The configuration of the challenge-response dataset size represents a trade-off between security requirements and resource overhead: higher security requirements and more frequent authentication necessitate a larger number of data pairs, leading to increased storage costs; conversely, moderate security requirements and lower authentication frequencies reduce the number of data pairs, significantly lowering storage resource consumption. This flexibility allows the solution to adapt to diverse IoT scenarios, ranging from high-security industrial equipment to low-power consumer devices.

[0105] The device does not export its internal key K to the authentication service or other entities. The authentication service verifies the device's identity by pre-stored "challenge value-response value" datasets. The device calculates the response value of the challenge value using its internal key K, and the authentication service only needs to compare it with the pre-stored response value to complete the authentication. The entire process does not require obtaining the key K, logically eliminating the possibility of the key being exposed. This fundamentally avoids the pain point of centralized key management being prone to leakage in traditional symmetric key authentication, while also creating synergistic advantages in security, resource consumption, and scenario adaptability.

[0106] Figure 3 This demonstrates the process of building a challenge-response dataset for a black-box device. It illustrates the workflow for an application to reconstruct a challenge-response dataset for a black-box device without manufacturer involvement. The core scenario involves adapting the device to a situation where the symmetric key has already been programmed using existing technology, but the application cannot obtain the key or the manufacturer's services. The source of the symmetric key and... Figure 2 Unlike the self-developed keys used in other devices, the symmetric key used in this process is a pre-programmed symmetric key K (i.e., a key written into the device by the manufacturer during the production phase). The specific process includes the following steps:

[0107] Step 1: The application runs its own authentication service. The application deploys its own authentication service in a secure and controllable environment to replace the original manufacturer's authentication role.

[0108] Step 2: Read Device Unique Identifier (DevID) The authentication service sends a "Read Device Unique Identifier" request to the device, and the device returns the DevID, which is used for subsequent association and storage of the dataset.

[0109] Step 3: Generate and interact with the "Challenge Value-Response Value" pair (loop process). The authentication service generates a challenge value Ci (generation method is the same as above). Figure 2 (The key can be randomly generated or derived from a seed). After receiving Ci, the device performs encryption or MAC calculation using the internally pre-loaded symmetric key K to generate a response value Ri and returns it to the authentication service. This process is repeated multiple times (represented by the dotted line i=i+1) until a sufficient number of "Ci-Ri" pairs are collected.

[0110] Step 4: Storing the Challenge Response Dataset. The authentication service will bind and store the collected "Ci-Ri" data pairs with the device's DevID, serving as an "identity fingerprint" for subsequent authentication. Applications must store this data confidentially, ensuring its confidentiality and integrity.

[0111] Figure 4 This demonstrates the device authentication process, showcasing a challenge-response authentication workflow for verifying device identity. The process involves comparing a pre-stored challenge-response dataset with the device's real-time calculation results to confirm the device's authenticity. Specifically, the workflow includes the following steps:

[0112] Step 1: Read Device Unique Identifier (DevID); The authentication service sends a "Read Device Unique Identifier" request to the device, and the device returns its own DevID. This step is used by the authentication service to locate the challenge-response dataset corresponding to the device.

[0113] Step 2: Select and send challenge value C; the authentication service will perform the following operations:

[0114] Step 2-1: Locate the challenge response dataset associated with the DevID;

[0115] Step 2-2: Select a challenge response (CR) data pair from the total N data pairs in the dataset. The selection methods include: 1. Random selection: Randomly select one of the N data pairs; 2. Traverse by index order: Traverse the N data pairs sequentially according to their index order, incrementing the index number by 1 each time; 3. Randomly select from "unused" data pairs and mark them as "used": Each data pair also stores an additional label to indicate whether it has been used. Randomly select one of the "unused" data pairs and set the label of the selected data pair to "used"; 4. Randomly select from data pairs where "last usage time exceeds threshold T" and update the time: Each data pair also stores an additional label for "last usage time". Based on the preset time window threshold T, randomly select one of the data pairs that meet the condition "current time - last usage time > T" and set the label of the selected data pair to the current time.

[0116] Steps 2-3: Send the challenge value C from the selected data pair to the device.

[0117] Step 3: The device generates and returns the hash of the response value; After receiving the challenge value C, the device generates the response value R' based on the internal symmetric key K using the same algorithm (encryption or MAC calculation) as in the "dataset establishment stage", then calculates the hash of R' (using a collision-resistant hash algorithm such as SHA-256), and returns the hash(R') to the authentication service.

[0118] Step 4: The authentication service compares the hash and returns the result. The authentication service performs the following operations:

[0119] Step 4-1: Calculate the hash(Hash(R)) of the response value R in the pre-stored data pair.

[0120] Step 4-2: Compare Hash(R) and Hash(R') to see if they match: If they match, the device identity is determined to be genuine and authentication is successful; if they do not match, authentication fails.

[0121] Optionally, the authentication result can be returned to the device, and a "response timeout detection" can be added (authentication fails if the time threshold is exceeded).

[0122] The above process completes one device authentication. By using pre-stored challenge-response data, the device only needs to perform symmetric encryption or MAC calculation during authentication, without needing to perform complex private key operations. During the authentication communication, the challenge value C is public, and the response value R is transmitted in hash form, without the plaintext of R appearing.

[0123] The number of pre-stored data pairs and the method for determining the challenge value for each authentication affect the security of the authentication. For example, pre-stored enough data pairs and setting each data pair to be used only once can completely eliminate replay attacks; pre-stored a limited number of data pairs and allow repeated use, but can be combined with additional mechanisms such as time windows to reduce the risk of replay attacks. For example, the authentication service can be configured to not allow each challenge value to be reused within 30 days.

[0124] The number of pre-stored data pairs and the method for determining the challenge value can be configured according to the required security level of the system. For example, if the goal is to reduce the probability of an attacker guessing or successfully replaying the attack to a sufficiently low level, a sufficient number of data pairs should be pre-stored and reuse should be prohibited. In scenarios that are cost-sensitive and have low security requirements, fewer data pairs can be stored, and the risk of replay attacks can be mitigated by limiting the time window for reuse.

[0125] Using the above method, the device only needs to perform symmetric encryption / MAC calculation and hash operation, without the need for complex public key algorithms, making it suitable for resource-constrained IoT devices. Selection strategies such as "single-use data pair" and "time window restriction" effectively prevent attackers from replaying historical response values. The challenge value C is publicly transmitted, and the response value is transmitted in hash form, avoiding plaintext leakage of the response value and reducing the risk of communication eavesdropping.

[0126] In summary, this process, through the design of "pre-stored dataset comparison + hash transmission + flexible challenge value selection strategy", ensures authentication security while taking into account device resource consumption and scenario adaptability.

[0127] Figure 5 This demonstrates the process of device authentication and session key negotiation, providing an integrated workflow for device identity authentication and session key negotiation. It verifies device identity through a challenge-response mechanism while securely exchanging random entropy to generate a session key. The specific process includes the following:

[0128] Step 1: Read the device unique identifier (DevID); The authentication service sends a request to the device to read the device unique identifier. The device returns the DevID, which is used to locate the challenge-response dataset corresponding to the device.

[0129] Step 2: Select the challenge-response data pair and prepare the cryptographic entropy; the authentication service performs the following operations:

[0130] Step 2-1: Retrieve the challenge response datasets bound to DevID and select a data pair (CR);

[0131] Step 2-2: Generate a random number A (server entropy), encrypt A with the pre-stored response value R, and obtain the ciphertext EncA;

[0132] Steps 2-3: Send the challenge value C and the ciphertext EncA to the device.

[0133] Step 3: The device generates a response value hash and decrypts the server entropy; the device performs the following operations:

[0134] Step 3-1: Based on the challenge value C and the internal symmetric key K, generate the response value R' and calculate its hash value Hash(R');

[0135] Step 3-2: Decrypt EncA with R' to obtain A' (server entropy on the client side);

[0136] Step 3-3: Generate a random number B (client entropy), encrypt B with R' to obtain the ciphertext EncB;

[0137] Steps 3-4: Send Hash(R') and EncB to the authentication service.

[0138] Step 4: The authentication service verifies the identity and decrypts the client entropy; the authentication service performs the following operations:

[0139] Step 4-1: Calculate the hash value of the pre-stored response value R and compare it with the hash (R') returned by the device: if they do not match, authentication fails and the process terminates; if they match, continue to the next step.

[0140] Step 4-2: Decrypt EncB using the pre-stored response value R to obtain B' (client entropy on the server side).

[0141] Step 5: Both parties generate session keys and establish secure communication;

[0142] Step 5-1: Authentication service: Based on A and B', generate a session key sk using a hash function (e.g., sk=Hash(A||B'));

[0143] Step 5-2: Device: Based on A' and B, generate a session key sk using the same hash function (e.g., sk=Hash(A'||B)); both parties establish secure communication using the session key sk.

[0144] In the above process, the random entropy used to generate the session key is A and B, generated by the authentication service and the device respectively. Based on a specific challenge value C, both parties use their own known response value (corresponding to C) R to protect and exchange the random entropy. The plaintext of A, B, and R does not appear in the communication process.

[0145] Device authentication and session key generation are completed in a single interaction, improving efficiency and reducing communication overhead. The plaintext of random numbers A and B is never exposed during communication; it is protected by encryption using the response value R / R' to prevent entropy eavesdropping. Each negotiated A and B are randomly generated, ensuring the freshness of the session key and preventing key reuse attacks. In summary, this process, through its design of "response value protecting random entropy + hash-generated session key," securely and efficiently negotiates a session key while completing device authentication, providing a foundation for subsequent secure communication.

[0146] The method provided in this application eliminates the need for pre-shared keys. The authentication service verifies the device using a pre-stored challenge-response dataset, without requiring the acquisition of the device's internal key, thus simplifying key sharing management in traditional symmetric key mechanisms. The key remains within the device; the internal key is used only for local calculation of the response value and encryption entropy and is never exported, completely avoiding the risk of key leakage. Post-quantum security and black-box compatibility are achieved through a combination of high-security symmetric algorithms (such as AES-256) to ensure post-quantum security, while also supporting compatibility with black-box devices (through process-based authentication mechanism reconstruction). These features are implemented in the session key negotiation process by protecting random entropy through the response value.

[0147] In summary, this application provides a device authentication method. In response to an authentication request for a target device, an authentication server obtains the identifier of the target device; based on the identifier, it determines a challenge value from a pre-established challenge-response dataset corresponding to the identifier and sends it to the target device; wherein the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device performing cryptographic operations on the challenge value based on an internally generated symmetric key; the server receives verification data from the target device, wherein the verification data is generated by the target device performing the cryptographic operations based on the challenge value and the symmetric key; the verification data is compared with the response value corresponding to the challenge value determined in the challenge-response dataset, and the authenticity of the target device's identity is determined based on the comparison result. This application solves a specific problem of device identity authentication in resource-constrained scenarios such as the Internet of Things. By establishing a challenge-response dataset through a pre-registration mechanism, the authenticator can complete the verification without knowing the device's internal symmetric key, thereby significantly reducing the complexity of key management and the risk of leakage. It avoids the use of computationally intensive asymmetric cryptographic algorithms, specifically balancing security and resource overhead. By generating and storing keys locally on the device, pre-storing a limited number of challenge-response pairs, and comparing hash values ​​instead of plaintext response values, the design effectively controls the computational, storage, and communication load on the device while ensuring resistance to replay attacks. By independently establishing a new challenge-response dataset, the device can still achieve secure authentication in closed networks or specific application environments, reducing the mandatory dependence on the device manufacturer's key management system and enhancing the flexibility and applicability of the authentication mechanism.

[0148] Based on the same technical concept, embodiments of this application also provide a device authentication system, such as... Figure 6 As shown, the system includes:

[0149] Message acquisition module 601 is used to acquire the identifier of the target device in response to an authentication request for the target device;

[0150] The challenge value determination module 602 is used to determine a challenge value from a pre-established challenge-response dataset corresponding to the identifier based on the identifier and send it to the target device; wherein, the challenge-response dataset contains at least one pair of challenge values ​​and corresponding response values, and the response value is generated by the target device by performing cryptographic operations on the challenge value based on an internally generated symmetric key;

[0151] The message receiving module 603 is used to receive the verification data of the target device, wherein the verification data is generated by the target device after performing the cryptographic operation based on the challenge value and the symmetric key;

[0152] The comparison module 604 is used to compare the verification data with the response value corresponding to the challenge value determined in the challenge response dataset, and to determine whether the identity of the target device is genuine based on the comparison result.

[0153] This application also provides an electronic device corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 7 The diagram illustrates an electronic device provided by some embodiments of this application. The electronic device 20 may include: a processor 200, a memory 201, a bus 202, and a communication interface 203, wherein the processor 200, the communication interface 203, and the memory 201 are connected via the bus 202; the memory 201 stores a computer program that can run on the processor 200, and when the processor 200 runs the computer program, it executes the method provided by any of the foregoing embodiments of this application.

[0154] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one physical port (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0155] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs. After receiving an execution instruction, the processor 200 executes the program. The method disclosed in any of the foregoing embodiments of this application can be applied to the processor 200, or implemented by the processor 200.

[0156] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.

[0157] The electronic devices and methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0158] This application also provides a computer-readable storage medium corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 8 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored, which, when run by a processor, executes the methods provided in any of the foregoing embodiments.

[0159] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0160] The computer-readable storage medium provided in the above embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0161] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0162] The above description is merely a preferred embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0163] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. All equivalent structural transformations made under the concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A device authentication method characterized by comprising: The method comprises: The authentication server acquires an identifier of the target device in response to an authentication request of the target device; Based on the identifier, a challenge value is determined from a pre-established challenge-response data set corresponding to the identifier and sent to the target device; wherein the challenge-response data set contains at least one pair of challenge value and corresponding response value, and the response value is generated by the target device based on an internally generated symmetric key and a cryptographic operation on the challenge value; The authentication data of the target device is received, wherein the authentication data is generated by the target device based on a response value obtained by the cryptographic operation on the challenge value and the symmetric key; The authentication data is compared with the response value corresponding to the determined challenge value in the challenge-response data set, and whether the identity of the target device is authentic is determined according to the comparison result; Wherein, based on the identifier, the challenge value is determined from the pre-established challenge-response data set corresponding to the identifier, which comprises: acquiring the value of the current index pointer associated with the challenge-response data set; selecting the corresponding challenge value from the challenge-response data set according to the value of the current index pointer; incrementing the value of the current index pointer by 1 after completing this selection; when the value of the current index pointer exceeds the total number of data pairs in the challenge-response data set, resetting the current index pointer to the initial value.

2. The method of claim 1, wherein, After determining that the identity of the target device is authentic, the method further comprises: The authentication server generates a first random number and encrypts the first random number using the response value corresponding to the determined challenge value in the challenge-response data set, and sends the encrypted first encrypted data to the target device; The target device decrypts the first encrypted data using the response value to obtain the first random number, generates a second random number, encrypts the second random number using the response value, and sends the encrypted second encrypted data to the authentication server; The authentication server decrypts the second encrypted data using the response value to obtain the second random number; The authentication server and the target device generate the same session key based on the first random number and the second random number using a pre-defined key derivation function.

3. The method of claim 1, wherein, The pre-establishment method of the challenge-response data set comprises: The authentication server sends a plurality of preset challenge values to the target device, so that the target device generates corresponding response values by performing encryption or message authentication code calculation using the symmetric key for each preset challenge value and sends the response values to the authentication server; the preset challenge values are independently randomly generated or generated based on key dispersion of a seed key of the authentication server and an identifier of the target device; The identifier of the target device is associated with the challenge-response data set composed of the plurality of preset challenge values and corresponding response values and stored.

4. The method of claim 1, wherein, Each data pair in the challenge-response data set is attached with a timestamp label for recording the last use time of the data pair; the data pair includes a challenge value and a corresponding response value. The challenge value is determined from a pre-established challenge-response data set corresponding to the identifier, including: obtaining a current system time; filtering all data pairs satisfying a condition that a difference between the current system time and a time stamp recorded in the time stamp is greater than a preset threshold from the challenge-response data set to form a first candidate set; randomly selecting a data pair from the first candidate set and updating a time stamp of the selected data pair to the current system time.

5. The method of claim 1, wherein, Each data pair in the challenge-response data set is attached with a use status label, and the use status label includes unused and used; The challenge value is determined from a pre-established challenge-response data set corresponding to the identifier, including: filtering all data pairs with the use status label indicating unused from the challenge-response data set to form a second candidate set; randomly selecting a data pair from the second candidate set and updating the use status label of the selected data pair to used.

6. The method of claim 1, wherein, The verification data is a hash value of a response value calculated by the target device; The verification data is compared with a response value corresponding to the determined challenge value in the challenge-response data set, including: calculating a hash value of the response value corresponding to the determined challenge value in the challenge-response data set; matching and verifying the hash value with the received verification data, and verifying that the comparison is passed when the hash value and the received verification data are consistent, and verifying that the comparison fails when the hash value and the received verification data are inconsistent.

7. An apparatus authentication system characterized by comprising: The system includes: a message acquisition module configured to acquire an identifier of a target device in response to an authentication request for the target device; a challenge value determination module configured to determine a challenge value from a pre-established challenge-response data set corresponding to the identifier and send the challenge value to the target device, wherein the challenge-response data set contains at least one pair of challenge value and corresponding response value, and the response value is generated by performing a cryptographic operation on the challenge value based on an internally generated symmetric key by the target device; wherein the challenge value is determined from the pre-established challenge-response data set corresponding to the identifier, including: acquiring a value of a current index pointer associated with the challenge-response data set; selecting a corresponding challenge value from the challenge-response data set according to the value of the current index pointer; incrementing the value of the current index pointer by 1 after completing the selection; and resetting the current index pointer to an initial value when the value of the current index pointer exceeds the total number of data pairs in the challenge-response data set; a message receiving module configured to receive verification data of the target device, wherein the verification data is generated by the target device based on a response value obtained by performing the cryptographic operation on the challenge value and the symmetric key; a comparison module configured to compare the verification data with a response value corresponding to the determined challenge value in the challenge-response data set, and determine whether the identity of the target device is real according to a comparison result.

8. An electronic device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the computer program, performs to implement the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, A computer program product having stored thereon computer readable instructions executable by a processor to implement the method of any one of claims 1-6.

Images