Method, apparatus and device for security authentication

Abstract

This application discloses a method, apparatus, and device for security authentication, relating to the field of security protection technology. Before establishing a communication connection between the main control unit and the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on a software identity certificate. The upper-layer software verifies the legitimacy of the hardware circuit's identity based on a hardware identity certificate, and sends a random challenge value to the main control unit. The main control unit generates corresponding real-time response information based on the PUF circuit. Due to the physical non-cloning characteristic of the PUF circuit, cloned or simulated counterfeit hardware circuits cannot reproduce the correct real-time response information. Therefore, the upper-layer software can verify the authenticity of the hardware circuit's identity based on the real-time response information, preventing the hardware circuit from being a counterfeit product. Since the upper-layer software and hardware circuit are both legitimate, and the hardware circuit is authentic, a communication connection is established between the upper-layer software and the main control unit only when their identities are legitimate, preventing the access of unauthorized hardware / software.

Description

Technical Field

[0001] This application relates to the field of security protection technology, and in particular to methods, apparatus and equipment for security authentication. Background Technology

[0002] Currently, most software and hardware security authentication mechanisms perform identity verification after communication between the software and hardware is established. This allows malicious hardware / software to launch attacks during the window of opportunity. Furthermore, hardware verification only performs identity authentication and cannot effectively prevent counterfeit hardware such as cloning or emulation. Summary of the Invention

[0003] The main purpose of this application is to provide a method, apparatus and device for secure authentication, which aims to prevent the access of malicious hardware / software, and at the same time effectively prevent the access of counterfeit hardware such as clones or emulators.

[0004] To achieve the above objectives, this application proposes a security authentication method applied to an electronic device comprising hardware circuitry and upper-layer software. The hardware circuitry includes a main control unit and a PUF (Physically Unclonable Function) circuit with physical unclonable functionality. The method includes: before establishing a communication connection between the main control unit and the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on a software identity certificate sent by the upper-layer software; the upper-layer software verifies the legitimacy of the hardware circuit's identity based on a hardware identity certificate sent by the main control unit; the upper-layer software sends a random challenge value to the main control unit; the main control unit generates real-time response information corresponding to the random challenge value based on the PUF circuit; the upper-layer software verifies the authenticity of the hardware circuit's identity based on the real-time response information; and, if both the upper-layer software and the hardware circuit are legitimate, and the hardware circuit is authentic, a communication connection is established between the upper-layer software and the main control unit.

[0005] In this embodiment, before establishing a communication connection between the main control unit and the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on the software's identity certificate; the upper-layer software verifies the legitimacy of the hardware circuit's identity based on the hardware's identity certificate, and sends a random challenge value to the main control unit. The main control unit generates corresponding real-time response information based on the PUF circuit. Due to the physical non-cloning characteristic of the PUF circuit, cloned or simulated counterfeit hardware circuits cannot reproduce the correct real-time response information. Therefore, the upper-layer software can verify the authenticity of the hardware circuit's identity based on the real-time response information, preventing the hardware circuit from being a counterfeit product. Since the upper-layer software and the hardware circuit are both legitimate and the hardware circuit is authentic, a communication connection is established between the upper-layer software and the main control unit, eliminating the window period and preventing the access of unauthorized hardware / software.

[0006] In one embodiment, before the upper-layer software verifies the legitimacy of the hardware circuit's identity based on the hardware identity certificate sent by the main control unit, the method further includes: when the hardware circuit is powered on, the main control unit generates an unclonable hardware fingerprint based on the random response value generated by the PUF circuit and a pre-stored unique hardware identifier; the real-time response information includes the unclonable hardware fingerprint and the real-time response value generated by the PUF circuit; the upper-layer software verifies the authenticity of the hardware circuit's identity based on the real-time response value and the unclonable hardware fingerprint. This embodiment increases the difficulty for attackers to forge a complete hardware identity chain by associating the dynamic challenge response of the PUF circuit with the unclonable hardware fingerprint (HF).

[0007] In one embodiment, the real-time response information further includes the current timestamp of the hardware circuit; the method further includes: the upper-layer software verifying the authenticity of the hardware circuit's production date by verifying the time deviation between the current timestamp of the hardware circuit and the local timestamp of the upper-layer software; and establishing a communication connection between the upper-layer software and the main control unit if the identities of the upper-layer software and the hardware circuit are legitimate, the production date of the hardware circuit is authentic, and the identity of the hardware circuit is authentic. In this embodiment, even if an attacker intercepts a valid challenge-response data packet, it cannot be resent in future authentications because the timestamp has expired; thus ensuring that each authentication is a real-time interaction with the hardware entity, rather than a dialogue with a record or simulator.

[0008] In one embodiment, the real-time response information is obtained by digitally signing the real-time response value, the unclonable hardware fingerprint, and the current timestamp of the hardware circuit using a pre-stored hardware private key. The method further includes: the upper-layer software verifying the legality of the real-time response information based on a pre-stored hardware public key; if the real-time response information is verified to be legal, the upper-layer software performs the following steps: verifying the authenticity of the hardware circuit's identity based on the real-time response value and the unclonable hardware fingerprint; and verifying the authenticity of the hardware circuit's production date by verifying the time deviation between the current timestamp of the hardware circuit and the upper-layer software's local timestamp. In this embodiment, the hardware private key ensures that the response data has not been tampered with since it was issued by the hardware; the physical proof of the PUF is strongly bound to the cryptographic identity (key pair) of the hardware, forming a dual trust of "physical characteristics + cryptographic credentials".

[0009] In one embodiment, the main control unit has a one-time programmable area storing a root key; the hardware identity certificate is obtained by signing pre-stored hardware identity information with the root key; the upper-layer software verifies the identity legitimacy of the hardware circuit based on the hardware identity certificate sent by the main control unit, and the upper-layer software performs the following steps: the upper-layer software verifies the signature legitimacy of the hardware identity certificate based on the pre-stored root certificate; if the signature of the hardware identity certificate is legitimate, the upper-layer software verifies the identity legitimacy of the hardware circuit based on the hardware identity information.

[0010] In one embodiment, the main control unit stores a root key; the hardware circuit further includes one or more of a conductive circuit, a voltage detection module, a temperature detection module, and a current detection module; the method further includes: destroying the root key when the main control unit detects that one or more of the resistance of the conductive circuit, the voltage of the voltage detection module, the temperature of the temperature detection module, and the current of the current detection module exceed the corresponding reference range. This embodiment extends security protection to the physical layer, enabling proactive detection of physical attacks such as shell cracking and extreme environments; and when facing physical intrusion, it adopts a "self-destruction" strategy for core secrets (root key), ensuring that even if an attacker obtains the physical device, they cannot obtain the most critical root key required to establish trust, greatly increasing the cost and risk of attack.

[0011] In one embodiment, before the main control unit establishes a communication connection with the upper-layer software, the method further includes: the main control unit verifying the code integrity of the upper-layer software based on the code hash value sent by the upper-layer software; and establishing a communication connection between the upper-layer software and the main control unit if the identities of the upper-layer software and the hardware circuit are legitimate, the code of the upper-layer software is complete, and the identity of the hardware circuit is authentic. This embodiment uses code hash value verification to prevent legitimate software from being implanted with malicious code or damaged after distribution, storage, or operation, achieving finer-grained software security verification.

[0012] In one embodiment, the main control unit stores a root key. After establishing a communication connection between the upper-layer software and the main control unit, the method further includes: the main control unit generating an internal challenge value at preset intervals; the PUF circuit generating an internal response value corresponding to the internal challenge value; and the upper-layer software verifying the authenticity of the hardware circuit based on the internal response value. If the identity of the hardware circuit is found to be authentic, the root key is destroyed. This embodiment provides full monitoring during hardware and software communication, enabling the detection of hardware replacement or real-time physical attacks occurring after successful authentication. It can effectively detect "post-authentication replacement" attacks during device operation, ensuring that the communication object is always the original, unaltered hardware entity.

[0013] In one embodiment, after establishing a communication connection between the upper-layer software and the main control unit, the method further includes encrypting the communication between the upper-layer software and the main control unit based on a post-quantum encryption algorithm. This embodiment addresses the problem that existing authentication schemes typically focus only on the authentication itself while ignoring the potential obsolescence of communication encryption algorithms, providing end-to-end long-term security protection.

[0014] Furthermore, to achieve the above objectives, this application also proposes a security authentication device, comprising: a hardware module, a PUF circuit with physically unclonable functionality, and a software module; the hardware module is used to verify the legitimacy of the software module's identity based on a software identity certificate sent by the software module before establishing a communication connection between the hardware module and the upper-layer software; the software module is used to verify the legitimacy of the hardware module's identity based on a hardware identity certificate sent by the hardware module before establishing a communication connection between the hardware module and the software module; the software module is also used to send a random challenge value to the hardware module; the hardware module is also used to generate real-time response information corresponding to the random challenge value based on the PUF circuit; the software module is also used to verify the authenticity of the hardware module's identity based on the real-time response information; the hardware module and the software module are also used to establish a communication connection when the identities of the software module and the hardware circuit are legitimate, and the identity of the hardware module is authentic.

[0015] In addition, to achieve the above objectives, this application also proposes a security authentication device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the security authentication method as described above. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the security authentication method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the security authentication method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the security authentication method of this application; Figure 4 This is a flowchart illustrating Embodiment 4 of the security authentication method of this application; Figure 5 This is a schematic diagram of the module structure of the security authentication device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the security authentication method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0022] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0025] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0026] Currently, most software and hardware security authentication mechanisms perform identity verification after communication between the software and hardware is established. This allows malicious hardware / software to launch attacks during the window of opportunity. Furthermore, hardware verification only performs identity authentication and cannot effectively prevent counterfeit hardware such as cloning or emulation.

[0027] To address this, this application proposes a security authentication method applied to an electronic device comprising hardware circuitry and upper-layer software. The hardware circuitry includes a main control unit and a PUF (Physically Unclonable Function) circuit with physical unclonable functionality. The method includes: before establishing a communication connection between the main control unit and the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on a software identity certificate sent by the upper-layer software; the upper-layer software verifies the legitimacy of the hardware circuit's identity based on a hardware identity certificate sent by the main control unit; the upper-layer software sends a random challenge value to the main control unit; the main control unit generates real-time response information corresponding to the random challenge value based on the PUF circuit; the upper-layer software verifies the authenticity of the hardware circuit's identity based on the real-time response information; and, if both the upper-layer software and the hardware circuit are legitimate, and the hardware circuit is authentic, a communication connection is established between the upper-layer software and the main control unit.

[0028] In this embodiment, before establishing a communication connection between the main control unit and the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on the software's identity certificate; the upper-layer software verifies the legitimacy of the hardware circuit's identity based on the hardware's identity certificate, and sends a random challenge value to the main control unit. The main control unit generates corresponding real-time response information based on the PUF circuit. Due to the physical non-cloning characteristic of the PUF circuit, cloned or simulated counterfeit hardware circuits cannot reproduce the correct real-time response information. Therefore, the upper-layer software can verify the authenticity of the hardware circuit's identity based on the real-time response information, preventing the hardware circuit from being a counterfeit product. Since the communication connection between the upper-layer software and the main control unit is established only when the identities of the upper-layer software and the hardware circuit are legitimate and the identity of the hardware circuit is authentic, the window period is eliminated, preventing the access of unauthorized hardware / software.

[0029] It should be noted that the execution entity in this embodiment can be an electronic device including hardware circuitry and upper-layer software. Examples of such electronic devices include smart meters, IoT gateways, and industrial controllers. The hardware circuitry includes a main control unit and a circuit with a Physically Unclonable Function (PUF). The main control unit can be a Microcontroller Unit (MCU), also known as a single-chip microcomputer.

[0030] PUF circuits generate unique challenge-response pairs for each device by extracting microscopic differences generated during device manufacturing (such as transistor threshold voltage and signal delay). This identification, similar to biometrics, ensures the device's uniqueness globally, enabling device authentication and anti-counterfeiting. Because the PUF circuit's response relies on physically uncopyable randomness, any attempt to obtain the key through microprobing or intrusive means will disrupt its physical structure, causing the response to fail, thus achieving self-destructive protection. This characteristic makes it effective against cloning and forgery attacks in scenarios such as Internet of Things (IoT) device authentication and firmware protection.

[0031] The following uses an electronic device as an example to illustrate this embodiment and the following embodiments.

[0032] Based on the above, this application provides a method for security authentication, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the security authentication method of this application. In this embodiment, the security authentication method includes steps S101 to S108: Step S101: The upper-layer software sends the software identity certificate to the main control unit.

[0033] The upper-layer software can send a first connection request to the main control unit, which includes a software identity certificate. The software identity certificate is obtained by the upper-layer software through vendor signature based on the software's unique identifier SID and the hash value of the software's public key Spuk.

[0034] In step S102, the main control unit verifies the legitimacy of the upper-layer software's identity based on the software identity certificate. If the upper-layer software's identity is verified to be legitimate, step S103 is executed; otherwise, the process ends.

[0035] After receiving the software identity certificate, the main control unit verifies the validity of the vendor's signature through the pre-stored root certificate to confirm the legitimacy of the software's origin; and verifies whether the hash value of the software public key Spuk is within the locally stored software whitelist by querying the locally stored software whitelist to prevent unauthorized software from accessing the system.

[0036] Optionally, the software ID may also include information such as the software package name and the software's unique identifier SID. In addition to the hash value of the software public key Spuk mentioned above, the software package name, the software's unique identifier SID, and other information can be used to verify whether the upper-layer software is authorized software. This will not be elaborated on in this embodiment.

[0037] Step S103: The main control unit sends the hardware identity certificate to the upper-layer software.

[0038] Once the main control unit determines that the software source is legitimate and that it is authorized software, the main control unit sends a second connection request to the upper-layer software. The second connection request includes a hardware identity certificate.

[0039] It is feasible to store the root key in the One-Time Programmable (OTP) area of ​​the main control unit. OTP is a type of one-time programmable non-volatile memory, mainly used in microcontrollers, embedded systems, and industrial electronic products. Its core characteristic is that data cannot be irreversibly modified after being written, and permanent storage is achieved through the physical structure of fuses or antifuse.

[0040] The hardware identity certificate is obtained by the main control unit signing the pre-stored hardware identity information using the root key. The hardware identity information may include information such as the hardware unique identifier, hardware version, and manufacturer.

[0041] In step S104, the upper-layer software verifies the identity and legitimacy of the hardware circuit based on the hardware identity certificate. If the hardware circuit's identity is verified to be legitimate, proceed to step S105; otherwise, the process ends.

[0042] After receiving the hardware identity certificate, the upper-layer software verifies the signature validity of the hardware identity certificate based on the pre-stored root certificate. Since the root key exists in the OTP area and is permanently stored, it cannot be read or modified. Therefore, the upper-layer software can distinguish whether the hardware identity certificate has been forged or replaced through signature validity verification.

[0043] If the hardware identity certificate is signed correctly, the upper-layer software trusts the hardware identity information in the certificate and then verifies the legitimacy of the hardware circuit based on this information. Specifically, the upper-layer software can compare the hardware identity information with pre-stored hardware identity information to verify the legitimacy of the hardware circuit.

[0044] Step S105: The upper-layer software sends a random challenge value to the main control unit.

[0045] The upper-level software generates a random challenge value C (e.g., 0x1A3B5C7D) and sends it to the main control unit. The number of bits in the random challenge value C is the same as the number of bits in the input data of the PUF circuit, for example, both are 128 bits.

[0046] In step S106, the main control unit generates real-time response information corresponding to the random challenge value based on the PUF circuit and sends it to the upper-layer software.

[0047] The PUF circuit receives the random challenge value C and generates a unique real-time response value R. If the upper-layer software generates a random challenge value C (128 bits), which is a binary sequence of 0s and 1s, the PUF circuit receives this random challenge value and generates a corresponding real-time response value R = PUF(C). The length of the real-time response value R strictly matches the length of the random challenge value C. This real-time response value R is a 128-bit binary bit string corresponding to the random challenge value C. The main control unit generates real-time response information based on the real-time response value R and sends the real-time response information to the upper-layer software.

[0048] In step S107, the upper-layer software verifies the authenticity of the hardware circuit based on the real-time response information. If the hardware circuit's authenticity is verified, proceed to step S108; otherwise, the process ends.

[0049] The upper-layer software verifies the authenticity of the hardware circuit based on real-time response information. Due to the physical non-cloning nature of PUF circuits, counterfeit hardware circuits that are cloned or simulated cannot reproduce the correct real-time response information. Therefore, the upper-layer software can verify the authenticity of the hardware circuit based on real-time response information, thus preventing the hardware circuit from being a fake.

[0050] Step S108: A communication connection is established between the upper-layer software and the main control unit.

[0051] Because a communication connection is established between the upper-layer software and the main control unit only when the identities of the upper-layer software and hardware circuits are legitimate and the identity of the hardware circuits is genuine, the window period is eliminated, thereby preventing the access of unauthorized hardware / software.

[0052] In one feasible implementation, the hardware circuit further includes one or more of the following: a conductive loop, a voltage detection module, a temperature detection module, and a current detection module; the method in this embodiment further includes: destroying the root key when the main control unit detects that one or more of the following exceed the corresponding reference range: the resistance of the conductive loop, the voltage of the voltage detection module, the temperature of the temperature detection module, and the current of the current detection module.

[0053] Hardware circuits integrate conductive loops, which can be printed around critical chips and housing interfaces. When a chip or housing interface is physically damaged, the resistance of the conductive loop increases. Therefore, by monitoring the resistance of the conductive loop, it is possible to determine whether the hardware circuit has been physically damaged. For example, the resistance of the conductive loop is normally <5Ω. If a sudden increase in the resistance of the conductive loop to >1MΩ is detected, the hardware circuit is likely damaged (e.g., the housing has been opened).

[0054] The hardware circuit may also integrate one or more of the following modules: voltage detection module, temperature detection module, and current detection module. When the voltage, temperature, or current exceeds the corresponding reference range, such as the voltage exceeding ±10% of the original voltage, the temperature exceeding -20℃ to 85℃, or the current exceeding ±10% of the original current, the hardware circuit is considered to be in an abnormal operating environment, and the hardware circuit is likely to be damaged.

[0055] Once the above-mentioned abnormal situation is detected, the main control unit immediately triggers the protection mechanism to permanently destroy (break) the root key in the OTP area, and may also trigger an alarm, terminate the session or lock the device.

[0056] Alternatively, once the above-mentioned abnormal situation is detected, the main control unit can first send a termination signal, display an alarm prompt and a prompt sound, and the hardware enters a locked state (requiring physical key reset). After continuously for 3 minutes, the root key (Secret Key, SK) is destroyed.

[0057] This embodiment extends security protection to the physical layer, enabling proactive detection of physical attack methods such as shell cracking and extreme environments. Furthermore, when faced with physical intrusion, it adopts a strategy of "self-destructing" core secrets (root key) to ensure that even if an attacker obtains the physical device, they cannot acquire the most critical root key required to establish trust, greatly increasing the cost and risk of attacks.

[0058] In one feasible implementation, after establishing a communication connection between the upper-layer software and the main control unit, the method of this embodiment further includes: the main control unit generating an internal challenge value at preset intervals, the PUF circuit generating an internal response value corresponding to the internal challenge value, the upper-layer software verifying the authenticity of the hardware circuit's identity based on the internal response value, and destroying the root key if the hardware circuit's identity is found to be authentic.

[0059] Specifically, after the upper-layer software establishes a communication connection with the main control unit and begins normal operation, the main control unit starts a background task that is automatically executed every preset interval (e.g., 30 seconds). Each time it executes, the main control unit internally generates an internal challenge value C' (without external communication), and the PUF circuit generates a corresponding internal response value R'. The main control unit compares R' with a pre-stored baseline response value for C'. If the comparison fails (similarity too low), it indicates that the hardware's physical characteristics may have undergone abnormal changes during operation (e.g., side-channel attacks, environmental interference, or hot-plugging of chips). Once such a runtime anomaly is detected, the main control unit destroys the root key SK and may also trigger an alarm, terminate the session, or lock the device.

[0060] Alternatively, once such runtime anomalies are detected, the main control unit can first send a termination signal, display an alarm prompt and sound a notification, and the hardware enters a locked state (requiring physical key reset). After this process continues uninterrupted for 3 minutes, the root key SK is then destroyed.

[0061] In this embodiment, the entire process of hardware and software communication is monitored, which can detect hardware replacement or real-time physical attacks that occur after successful authentication; it can effectively detect "post-authentication replacement" attacks during device operation, ensuring that the communication object is always the original, untampered hardware entity.

[0062] One feasible implementation method, such as Figure 2 As shown, before step S104, the following steps are also included: Step SA1: With the hardware circuit powered on, the main control unit generates an unclonable hardware fingerprint based on the random response value generated by the PUF circuit and the pre-stored unique hardware identifier.

[0063] When the hardware circuit is powered on, the PUF circuit generates a random response value PUF_R based on physical randomness. The main control unit combines the random response value PUF_R with hardware identity information (such as the main control unit's unique hardware identifier UID) to generate an unclonable hardware fingerprint HF using an algorithm. For example, the SM3 cryptographic hash algorithm can be used to generate the unclonable hardware fingerprint HF, represented as HF=SM3(PUF_R+UID).

[0064] By binding a static hardware unique identifier (UID) to a dynamically changing random response value (PUF_R) each time power is applied, a unique and random unclonable hardware fingerprint (HF) is generated, making it impossible for a cloner to predict or copy the complete identity of the device.

[0065] Accordingly, step S106 includes: the main control unit generating real-time response information based on the real-time response value generated by the PUF circuit and the unclonable hardware fingerprint. The real-time response information includes the real-time response value and the unclonable hardware fingerprint.

[0066] Step S107 includes: the upper-layer software verifies the authenticity of the hardware circuit based on the real-time response value and the non-clonable hardware fingerprint.

[0067] Since hardware identity certificates are generated based on unclonable hardware fingerprints, which are unclonable, counterfeit hardware circuits that are cloned or simulated cannot pass the verification of unclonable hardware fingerprints, thus avoiding the possibility of the hardware being cloned or counterfeited before power-on; while the dynamic challenge response of the PUF circuit can avoid the possibility of the hardware being cloned or counterfeited during the hardware authentication process.

[0068] In this embodiment, by associating the dynamic challenge response of the PUF circuit with the unclonable hardware fingerprint HF, the difficulty for an attacker to forge a complete hardware identity chain is increased.

[0069] In one feasible implementation, the real-time response information includes not only the real-time response value and the non-clonable hardware fingerprint, but also the current timestamp of the hardware circuit.

[0070] In this embodiment, the hardware circuit uses the real-time response value generated by the PUF circuit, the unclonable hardware fingerprint, and the current timestamp of the hardware circuit together to generate real-time response information.

[0071] This implementation example Figure 3 As shown, after step S107, if the identity of the hardware circuit is verified, step SB2 is executed; otherwise, the process ends.

[0072] In step SB2, the upper-layer software verifies the authenticity of the hardware circuit's production date by checking the time deviation between the hardware circuit's current timestamp and the upper-layer software's local timestamp. If the hardware circuit's production date is verified to be authentic, step S108 is executed.

[0073] After receiving the real-time response information, the upper-layer software extracts the current timestamp T of the hardware circuitry before, during, or after verifying the real-time response value and the unclonable hardware fingerprint, and compares it with its own local timestamp. If the time deviation is within a preset threshold (e.g., ≤10 seconds), the response is considered fresh, and the hardware production date (or last authentication time) is reliable; if the deviation is too large, it is judged as a possible replay attack, and authentication is rejected.

[0074] In this embodiment, even if an attacker intercepts a valid challenge-response data packet, they cannot resend it in future authentications because the timestamp has expired; thus ensuring that each authentication is a real-time interaction with the hardware entity, rather than a dialogue with a record or simulator.

[0075] It is worth noting that the step SB2 shown in the attached figure can be executed after step S107 only as an example. However, in actual applications, step SB2 can be executed before step S107, or step SB2 and step S107 can be executed simultaneously. This embodiment does not impose any limitations.

[0076] In one feasible implementation, the real-time response information is obtained by digitally signing the real-time response value, the unclonable hardware fingerprint, and the current timestamp of the hardware circuit using a pre-stored hardware private key.

[0077] The method in this embodiment further includes: the upper-layer software verifies the legitimacy of the real-time response information based on the hardware public key.

[0078] When verifying the legitimacy of the real-time response information, the upper-layer software executes the following steps: the upper-layer software verifies the authenticity of the hardware circuit's identity based on the real-time response value and the non-clonable hardware fingerprint; and the upper-layer software verifies the authenticity of the hardware circuit's production date by verifying the time deviation between the hardware circuit's current timestamp and the upper-layer software's local timestamp.

[0079] In this embodiment, the main control unit uses its securely stored hardware private key (Hprk) to digitally sign the data consisting of the unclonable hardware fingerprint HF, the real-time response value R, and the current timestamp T of the hardware circuit, to obtain the signature value S, which is the key real-time response information.

[0080] Upon receiving the signature S, the upper-layer software first verifies the signature S using the pre-stored hardware public key via Hpuk to ensure its legitimacy. Only after successful verification does the upper-layer software confirm that the real-time response information indeed originates from a legitimate hardware private key and that the data has not been tampered with during transmission. Under these conditions, the upper-layer software will then further perform verification of the hardware circuit's current timestamp T and physical authenticity based on the non-clonable hardware fingerprint HF and the real-time response value R.

[0081] In this embodiment, the hardware private key ensures that the response data has not been tampered with since it was sent by the hardware; the physical proof of the PUF is strongly bound to the cryptographic identity (key pair) of the hardware, forming a dual trust of "physical characteristics + cryptographic credentials".

[0082] One feasible implementation method, such as Figure 4 As shown, step S101 includes: the upper-layer software sending the software identity certificate and code hash value to the main control unit. Before the main control unit establishes a communication connection with the upper-layer software, the method in this embodiment is as follows: Figure 4 As shown, it also includes: If the identity of the upper-layer software is verified to be legitimate, in step SC1, the main control unit verifies the code integrity of the upper-layer software based on the code hash value sent by the upper-layer software. If the code integrity is verified, step S103 is executed; otherwise, the process ends.

[0083] In this embodiment, the upper-layer software provides a software identity certificate and also needs to provide the hash value of its key executable code (e.g., calculated using SHA-256). The main control unit pre-stores the verified baseline code hash value of this legitimate software version. The main control unit compares the received hash value with the baseline value. If the deviation exceeds a threshold (e.g., 0.01%), it determines that the software may have been tampered with, infected, or has been modified without authorization. Even if its certificate is legitimate, the main control unit will refuse communication. Thus, the prerequisites for establishing a communication connection become: legitimate software identity, complete software code, and legitimate and authentic hardware identity.

[0084] In this embodiment, code hash value verification is used to prevent legitimate software from being implanted with malicious code or damaged after distribution, storage, or operation, thus achieving more granular software security verification.

[0085] It is worth noting that the above step SC1 is executed after step S102 only as an example. In actual applications, step SC1 can be executed simultaneously with step S102, or step SC1 can be executed before step S102. This embodiment does not impose any limitations.

[0086] In one feasible implementation, after establishing a communication connection between the upper-layer software and the main control unit, the method of this embodiment further includes: encrypting the communication between the upper-layer software and the main control unit based on a post-quantum encryption algorithm.

[0087] After all bidirectional authentications between the upper-layer software and the main control unit are successful and a communication connection is established between them, the upper-layer software and the main control unit use a post-quantum encryption algorithm (such as CRYPTO-KEM) to negotiate the session key SK for subsequent communication.

[0088] The negotiation process securely exchanges random numbers using the verified public keys (Spuk, Hpuk) of both parties and derives the shared key. Specifically, the main control unit generates a random number R1, encrypts it with the software public key Spuk to obtain E1=Enc(Spuk,R1), and sends it to the software; the upper-layer software generates a random number R2, encrypts it with the hardware public key Hpuk to obtain E2=Enc(Hpuk,R2), and sends it to the hardware.

[0089] Both parties calculate SK = KDF(R1 + R2 + HF + SID) for subsequent communication encryption. Thereafter, all application data transmitted over the established connection will be encrypted and decrypted using this session key.

[0090] This embodiment addresses the problem that existing authentication schemes typically focus only on the authentication itself while ignoring the potential obsolescence of communication encryption algorithms, providing end-to-end long-term security protection.

[0091] The core of the software and hardware two-way security authentication method of this invention lies in forcibly completing two-way identity verification before communication is established, and preventing hardware cracking through the hardware's Physical Unclonable Function (PUF) characteristic, dynamic challenge-response, and layered anti-tampering mechanism. Specifically, it includes the following steps: (1) Hardware pre-configuration and initialization (basic anti-hacking infrastructure) 1.1 Hardware Root Trust Implantation During the hardware production phase, an immutable root key (RK) is written into the one-time programmable (OTP) area, and a physically unclonable function (PUF) circuit (such as a PUF based on SRAM noise) is integrated. The main control unit or a separate hardware security module (HSM) stores the root certificate, software whitelist (including public key hashes of legitimate software), and PUF baseline response value.

[0092] 1.2 Hardware Identity Generation After the hardware is powered on, the PUF circuit generates a response value (PUF_R) based on physical randomness. Combined with the hardware unique identifier (UID), it generates an unclonable hardware fingerprint (HF) = SM3(PUF_R + UID) using the SM3 algorithm. The hardware associates the unclonable hardware fingerprint HF with the root key in the hardware security module HSM to generate a hardware identity certificate (containing HF, hardware public key Hpuk, and root certificate signature).

[0093] (2) Two-way identity verification process before communication 2.1 Software Identity Verification: The software sends a software identity certificate (including the software public key Spuk hash value, the software unique identifier SID, and...). The vendor signature is sent to the main control unit; the main control unit verifies the validity of the vendor signature of the software identity certificate through the pre-set root certificate to confirm the legitimate source of the software; and verifies whether the software public key Spuk hash value is in the software whitelist by querying the local software whitelist to prevent unauthorized software from accessing the software.

[0094] 2.2 Software integrity verification: (whether it has been tampered with) The software also sends the code segment hash value (calculated using SHA-256 segmentation) to the main control unit; the main control unit compares the received code segment hash value with the preset baseline hash value, and if the deviation is >0.01%, it refuses to establish a communication connection and records the exception.

[0095] Hardware verification is performed once the software identity is legitimate and the software integrity verification passes.

[0096] 2.3 Hardware Certificate Verification The hardware sends a hardware identity certificate (including the hardware unique identifier UID, hardware version, and manufacturer signed with the root key) to the upper-layer software. The upper-layer software verifies the signature's legitimacy using the pre-installed root certificate, confirming that the hardware is a legitimately manufactured device.

[0097] 2.4 Dynamic PUF Challenge - Response The upper-layer software generates a random challenge value C (128 bits) and sends it to the hardware. The hardware generates a real-time response R=PUF(C) for C through the PUF circuit. It combines the non-clonable hardware fingerprint HF with the current timestamp T of the hardware circuit and signs it with the hardware private key Hprk: S=Sign(Hprk,HF+C+R+T). The hardware returns R, S, and T to the upper-layer software.

[0098] Upper-layer software verification: (1) Verify the legality of S using the user's hardware public key Hpuk; (2) Check that the deviation between T and the local timestamp is ≤10 seconds to prevent replay and avoid abnormal production dates; (3) Calculate the similarity (≥95%) between the PUF baseline response and the real-time response R to confirm that the hardware has not been cloned (the physical randomness of PUF cannot be reproduced by cracking the hardware).

[0099] 2.5 Determination of Two-Way Authentication Results A communication connection is allowed only if both the hardware authentication software and the software authenticate the hardware.

[0100] If any step fails, the communication request will be terminated immediately, the number of failures will be recorded by the hardware, and a 10-minute cooling-off mechanism will be activated after 3 consecutive failures.

[0101] (3) Communication encryption and dynamic protection (continuous anti-cracking) After successful two-way authentication, the session key SK is negotiated using the post-quantum encryption algorithm CRYPTO-KEM. The hardware generates a random number R1, encrypts it using the software public key Spuk to obtain E1=Enc(Spuk,R1), and sends it to the software. The software generates a random number R2, encrypts it using the hardware public key Hpuk to obtain E2=Enc(Hpuk,R2), and sends it to the hardware. Both parties calculate SK=KDF(R1+R2+HF+SID) for subsequent communication encryption.

[0102] It is feasible to automatically update the session key every hour, and the update process transmits the new key parameters through encryption using the old SK; when the software detects abnormal hardware behavior (such as a sudden increase in response latency), it can actively trigger a key update.

[0103] (4) Real-time detection of hardware hacking during communication: During communication, the hardware performs a self-test every 30 seconds: the PUF circuit randomly generates an internal challenge C' to verify the consistency of the response R' with the baseline value, thereby preventing the hardware from being cloned during operation.

[0104] (5) The anti-tampering module detects the resistance and physical parameters of the conductive circuit; A conductive circuit is laid on the hardware PCB board. Under normal conditions, the circuit resistance is <5Ω. When a sudden increase in resistance to >1MΩ is detected (the casing is opened), the main control unit or an independent hardware security module is triggered to melt the OTP area and permanently destroy the root key.

[0105] An integrated voltage / temperature anomaly detection module is used. When physical parameters exceeding the normal range (voltage ±10%, temperature -20℃ to 85℃) are detected, the main control unit or an independent hardware security module is immediately triggered to melt down the OTP area and permanently destroy the root key.

[0106] Compared with the prior art, the present invention has the following beneficial effects. (1) Forced two-way authentication before communication: identity verification is completed before establishing a connection, eliminating the attack window period and reducing the access rate of illegal devices / software to below 0.0001%.

[0107] (2) Significantly enhanced hardware anti-hacking capabilities: Combined with the physical unclonability of PUF (cloning success rate <10%) - ¹ 8 Dynamic challenge-response and physical anti-tampering measures fundamentally resist hardware cloning and reverse engineering.

[0108] (3) Multi-layered anti-attack mechanism: timestamp to prevent replay, post-quantum encryption to prevent computing power attacks, and anomaly self-detection to prevent runtime cracking, improving the overall attack defense rate by 99.9%.

[0109] (4) Compatibility and practicality: It is compatible with ARM / RISC-V / x86 platforms, with a certification latency of <500ms, which can meet the real-time requirements of industrial control, smart terminals and other scenarios.

[0110] The following example illustrates the security authentication method of this application, using an MCU such as STM32L562 as the main control unit, a PUF circuit as the SRAMPUF within the main control unit, and an APP as the upper-layer software on the main control board: The main control unit's OTP area has a pre-set root key and PUF reference value. The hardware circuit also includes a conductive loop (surrounding the casing) and a temperature sensor. The main control board's APP displays the pre-stored hardware root certificate and software whitelist.

[0111] The APP requests to connect to the device MCU. The device MCU (hardware) requests the APP to send its software certificate and code hash. The device MCU verifies the APP's certificate signature and hash value to confirm the software's legitimacy. The APP requests the device to send its hardware certificate and HF to verify the certificate's validity. The APP generates a challenge value C=0x1A3B5C7D... and sends it to the device MCU. The device generates a response R through the PUF circuit, signs it with its hardware private key (S=Sign(Hprk,HF+C+R+T)), and returns R, S, and T. The APP verifies that S is valid, T is fresh (deviation < 5 seconds), and R has a 98% similarity to the benchmark value, confirming that the hardware has not been cracked. After two-way authentication is successful, the APP negotiates the session key SK and establishes encrypted communication (AES-256-GCM). During communication, the device checks the PUF response and two-way binding value every 30 seconds. If it detects that the device hardware module has been removed or replaced, the main control board displays an alarm prompt and a sound, which continues uninterrupted for 3 minutes before immediately destroying SK and self-destructing the device MCU program.

[0112] This application also provides a security authentication device, such as Figure 5 As shown, the device includes: a hardware module 10, a PUF circuit 20 with physically unclonable functionality, and a software module 30. The hardware module 10 is used to verify the legitimacy of the software module 30's identity based on a software identity certificate sent by the software module 30 before establishing a communication connection with the upper-layer software. The software module 30 is used to verify the legitimacy of the hardware module 10's identity based on a hardware identity certificate sent by the hardware module 10 before establishing a communication connection with the software module 30. The software module 30 is also used to send a random challenge value to the hardware module 10. The hardware module 10 is also used to generate real-time response information corresponding to the random challenge value based on the PUF circuit 20. The software module 30 is also used to verify the authenticity of the hardware module 10's identity based on the real-time response information. The hardware module 10 and the software module 30 are also used to establish a communication connection when the identities of the software module 30 and the hardware module 10 are legitimate, and the identity of the hardware module 10 is authentic.

[0113] It is feasible that the one-time programmable area of ​​the hardware module 10 stores the root key; the software module 30 is used to verify the signature legality of the hardware identity certificate based on the pre-stored root certificate; the software module 30 is also used to verify the identity legality of the hardware module 10 based on the hardware identity information if the signature of the hardware identity certificate is legal.

[0114] The hardware module 10 stores a root key; the security authentication device further includes one or more of a conductive circuit, a voltage detection module, a temperature detection module, and a current detection module; the hardware module 10 is also used to destroy the root key when one or more of the resistance of the conductive circuit, the voltage of the voltage detection module, the temperature of the temperature detection module, and the current of the current detection module exceed the corresponding reference range.

[0115] The beneficial effects of the security authentication device provided in this application are the same as those of the security authentication method provided in the above embodiments, and other technical features in the security authentication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0116] This application provides a security authentication device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the security authentication method described above.

[0117] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the security authentication device in the embodiments of this application. The security authentication device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The security authentication device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0118] like Figure 6As shown, the security authentication device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the security authentication device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the security authentication device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows security authentication devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0119] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0120] The beneficial effects of the security authentication device provided in this application are the same as those of the security authentication method provided in the above embodiments, and other technical features in the security authentication device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0121] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0122] The above description is merely a specific 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 scope of the technology 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.

[0123] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the security authentication method described in the above embodiments.

[0124] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0125] The aforementioned computer-readable storage medium may be included in the security authentication device; or it may exist independently and not be assembled into the security authentication device.

[0126] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a security authentication device, enable the security authentication device to implement the security authentication method in any of the above embodiments.

[0127] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0129] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0130] The beneficial effects of the computer-readable storage medium provided in this application are the same as those of the security authentication method provided in the above embodiments, and will not be repeated here.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the security authentication method described above. The beneficial effects of the computer program product provided in this application are the same as those of the security authentication method provided in the above embodiments, and will not be repeated here.

[0132] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for security authentication, characterized in that, The method is applied to an electronic device comprising hardware circuitry and upper-layer software, wherein the hardware circuitry includes a main control unit and a PUF circuit with physically unclonable functionality; the method includes: Before the main control unit establishes a communication connection with the upper-layer software, the main control unit verifies the legitimacy of the upper-layer software's identity based on the software identity certificate sent by the upper-layer software. The upper-layer software verifies the identity and legitimacy of the hardware circuit based on the hardware identity certificate sent by the main control unit. The upper-layer software sends a random challenge value to the main control unit, the main control unit generates real-time response information corresponding to the random challenge value based on the PUF circuit, and the upper-layer software verifies the authenticity of the hardware circuit based on the real-time response information; If the identities of the upper-layer software and the hardware circuit are legitimate, and the identity of the hardware circuit is authentic, a communication connection is established between the upper-layer software and the main control unit.

2. The method as described in claim 1, characterized in that, Before the upper-layer software verifies the identity and legitimacy of the hardware circuit based on the hardware identity certificate sent by the main control unit, it also includes: When the hardware circuit is powered on, the main control unit generates an unclonable hardware fingerprint based on the random response value generated by the PUF circuit and the pre-stored unique hardware identifier. The real-time response information includes the unclonable hardware fingerprint and the real-time response value generated by the PUF circuit. The upper-layer software verifies the authenticity of the hardware circuit based on the real-time response value and the non-clonable hardware fingerprint.

3. The method as described in claim 2, characterized in that, The real-time response information also includes the current timestamp of the hardware circuit; The method further includes: the upper-layer software verifies the authenticity of the production date of the hardware circuit by verifying the time deviation between the current timestamp of the hardware circuit and the local timestamp of the upper-layer software; A communication connection is established between the upper-layer software and the main control unit if the identities of the upper-layer software and the hardware circuit are legitimate, the production date of the hardware circuit is authentic, and the identity of the hardware circuit is authentic.

4. The method as described in claim 3, characterized in that, The real-time response information is obtained by digitally signing the real-time response value, the unclonable hardware fingerprint, and the current timestamp of the hardware circuit using a pre-stored hardware private key. The method further includes: The upper-layer software verifies the legitimacy of the real-time response information based on a pre-stored hardware public key. If the real-time response information is verified to be valid, the upper-layer software performs the following steps: The upper-layer software verifies the authenticity of the hardware circuit based on the real-time response value and the unclonable hardware fingerprint. The upper-layer software verifies the authenticity of the hardware circuit's production date by verifying the time deviation between the hardware circuit's current timestamp and the upper-layer software's local timestamp.

5. The method as described in claim 1, characterized in that, The main control unit has a one-time programmable area that stores a root key; the hardware identity certificate is obtained by signing the pre-stored hardware identity information with the root key. The upper-layer software verifies the identity and legitimacy of the hardware circuit based on the hardware identity certificate sent by the main control unit. The upper-layer software performs the following steps: The upper-layer software verifies the signature validity of the hardware identity certificate based on the pre-stored root certificate. If the signature of the hardware identity certificate is valid, the upper-layer software verifies the identity of the hardware circuit based on the hardware identity information.

6. The method as described in claim 1, characterized in that, The main control unit stores the root key; The hardware circuit also includes one or more of the following: a conductive circuit, a voltage detection module, a temperature detection module, and a current detection module; The method further includes: destroying the root key when the main control unit detects that one or more of the following exceed the corresponding reference range: the resistance of the conductive circuit, the voltage of the voltage detection module, the temperature of the temperature detection module, and the current of the current detection module.

7. The method according to any one of claims 1-6, characterized in that, Before the main control unit establishes a communication connection with the upper-layer software, the method further includes: The main control unit verifies the code integrity of the upper-layer software based on the code hash value sent by the upper-layer software. A communication connection is established between the upper-layer software and the main control unit when the identities of the upper-layer software and the hardware circuit are legitimate, the code of the upper-layer software is complete, and the identity of the hardware circuit is authentic.

8. The method according to any one of claims 1-6, characterized in that, The main control unit stores a root key. After a communication connection is established between the upper-layer software and the main control unit, the method further includes: The main control unit generates an internal challenge value at preset intervals, the PUF circuit generates an internal response value corresponding to the internal challenge value, and the upper-layer software verifies the identity of the hardware circuit based on the internal response value. If the identity of the hardware circuit is found to be illegitimate, the root key is destroyed.

9. The method according to any one of claims 1-6, characterized in that, After establishing a communication connection between the upper-layer software and the main control unit, the method further includes: The communication between the upper-layer software and the main control unit is encrypted using a post-quantum encryption algorithm.

10. A security authentication device, characterized in that, The device includes: a hardware module, a PUF circuit with physically unclonable functionality, and a software module; The hardware module is used to verify the identity of the software module based on the software identity certificate sent by the software module before establishing a communication connection between the hardware module and the software module. The software module is used to verify the identity of the hardware module based on the hardware identity certificate sent by the hardware module before the hardware module establishes a communication connection with the software module. The software module is also used to send random challenge values ​​to the hardware module; The hardware module is also used to generate real-time response information corresponding to the random challenge value based on the PUF circuit; The software module is also used to verify the authenticity of the hardware module's identity based on the real-time response information; The hardware module and the software module are also used to establish a communication connection when the identities of the software module and the hardware circuit are legitimate and the identity of the hardware module is genuine.

11. The apparatus as claimed in claim 10, characterized in that, The root key is stored in the one-time programmable area of ​​the hardware module; The software module is used to verify the signature validity of the hardware identity certificate based on the pre-stored root certificate. The software module is also used to verify the identity of the hardware module based on the hardware identity information, provided that the signature of the hardware identity certificate is valid.

12. The apparatus as claimed in claim 10, characterized in that, The hardware module stores the root key; the security authentication device further includes one or more of the following: a conductive circuit, a voltage detection module, a temperature detection module, and a current detection module. The hardware module is also used to destroy the root key if one or more of the following are detected to exceed the corresponding reference range: the resistance of the conductive circuit, the voltage of the voltage detection module, the temperature of the temperature detection module, and the current of the current detection module.

13. A security authentication device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the security authentication method as described in any one of claims 1 to 9.

Images