Device authentication and key derivation method based on FPGA physical binding and electronic device
By dynamically generating working keys by reading the unique physical identifier sequence of the FPGA chip and the external key, the security risks of device authentication and key management in the prior art are solved, the correspondence between hardware binding features and logical functions is realized, and the security of the device is improved.
Patent Information
- Application Number
- CN202610787743.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-03
- Publication Date
- 2026-07-03
Smart Images

Figure CN122333442A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network hardware security technology, and in particular to a device authentication and key derivation method and electronic device based on FPGA physical binding. Background Technology
[0002] In existing field-programmable gate array (FPGA) device designs, authentication and key management during device startup typically employ a scheme where fixed keys or identity credentials are statically stored in non-volatile storage media. When the device powers on and loads configuration data, the system reads the statically stored credentials through internal control logic and performs logical checks to verify the device's identity. Once the logical verification is successful, the data path is unlocked, allowing the device to proceed with subsequent data processing.
[0003] However, this approach, which relies on static storage and logical layer verification, presents security risks in practical applications. Because there is no physical binding between configuration data, static keys, and the chip hardware entity, attackers can extract the configuration data and static keys through external reading methods and directly copy them to other hardware chips of the same model.
[0004] When the cloned device is powered on, the original verification program can still read the correct static credentials and pass the verification successfully, thereby gaining access to the protected data path. This makes it difficult for existing network hardware devices to effectively prevent illegal cloning and unauthorized data access. Summary of the Invention
[0005] This invention aims to at least partially address one of the technical problems in related technologies. Therefore, the objective of this invention is to propose a device authentication and key derivation method and electronic device based on FPGA physical binding, to improve the security of protected data paths in the device.
[0006] To achieve the above objectives, a first aspect of the present invention proposes a device authentication and key derivation method based on FPGA physical binding, comprising: In response to the device being powered on, the protected data path is disabled; The unique physical identifier sequence of the chip is read by calling the underlying hardware primitives of the field-programmable gate array; The authentication result is generated by comparing the unique physical identifier sequence with the preset authentication information. When the authentication result indicates that the authentication is successful, a working key is generated based on the unique physical identifier sequence and the external input key, and the working key is used to restore the protected logic to work. When the authentication result indicates that the authentication failed or abnormal tampering was detected, the protected data path is kept in a prohibited state and a security response is executed.
[0007] To achieve the above objectives, a second aspect of the present invention provides an electronic device, including a network communication interface and a field-programmable gate array (FPGA) chip; the FPGA chip is internally configured with: an identifier extraction module, an authentication comparison module, a key derivation module, a protected logic module, and a security control module; the FPGA chip is configured to execute the above-described FPGA-based physical binding device authentication and key derivation method during the startup and operation phases.
[0008] The technical solution provided by this invention controls the protected data path to a prohibited state during the initial power-on phase of the device and performs authentication by comparing the unique physical identifier sequence at the chip's underlying layer with preset information. In actual operation, this solution dynamically generates a working key by combining the chip-bound physical identifier sequence with an external input key to restore the protected logic, thereby reducing reliance on traditional static key storage mechanisms. When the device's configuration data is copied to other unauthorized chips, due to the differences in the underlying physical identifiers of different chips, the system struggles to generate a matching authentication result and a correct working key, thus maintaining the prohibited state of the data path and triggering a security response. This mechanism establishes a correspondence between the hardware operating logic and specific chip-bound characteristics, reducing the risk of configuration data being illegally accessed outside the original physical hardware environment and improving the security of the device's protected data path. Attached Figure Description
[0009] Figure 1 This is a schematic diagram illustrating the implementation of the FPGA-based physical binding device authentication and key derivation method provided by the present invention. Detailed Implementation
[0010] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.
[0011] The following description, with reference to the accompanying drawings, illustrates an embodiment of the FPGA-based physical binding device authentication and key derivation method and electronic device of the present invention.
[0012] This embodiment provides a device authentication and key derivation method based on FPGA physical bonding. This method is primarily deployed in electronic devices based on Field-Programmable Gate Array (FPGA) architectures. In some electronic devices, FPGAs possess parallel computing capabilities and logic reconfiguration features, making them applicable to network devices, encryption devices, and communication devices. For FPGAs employing Static Random Access Memory (SRAM) architectures, their internal logic typically needs to load hardware configuration data (bitstream) from external non-volatile memory (such as SPI Flash) upon power-up after power-down. This loading process carries the risk of being eavesdropped on by the bus or having configuration data copied.
[0013] A key technical aspect of this embodiment is that the unique physical identifier sequence, either fixed at the time of chip manufacturing or obtained from the chip's physical characteristics, is bound to the startup authentication and working key derivation process of the protected logic. This establishes a device identity verification foundation on the hardware side, reducing reliance on external static credentials.
[0014] Specifically, the method covered in this embodiment includes the following detailed execution stages: Phase 1: Power-on isolation and extraction of the unique physical identifier sequence at the bottom layer.
[0015] In the initial stage of device startup, to reduce the risk of unauthorized data communication or external load injection caused by uncertified logic modules starting up prematurely, in response to the device power-on command, the system's underlying hardware control logic can be started before the upper-layer application or communication protocol stack, thus keeping the protected data path in a prohibited state.
[0016] In practical applications of network communication equipment, the protected data path typically involves the data exchange channel between the high-speed network interface controller and internal memory. Specific methods for implementing this disabled state include: the system control module enabling or disabling reset signals or disable signals of specific peripheral interconnect buses (e.g., PCIe bus) and the Media Access Control (MAC) layer via hardware logic. When these control signals are enabled, the corresponding hardware controller is restricted to an initial sleep, reset, or non-forwarding state. In this state, link negotiation requests or direct memory access (DMA) requests initiated by the external network can be restricted or discarded, thereby reducing the risk of unauthorized data exchange before authentication is complete. This hardware-level data path restriction reduces the risk of abnormal software-level jumps directly enabling the protected controller.
[0017] Once external data paths are isolated or restricted, the system begins to establish its own hardware identity. The system reads the chip's unique physical identifier sequence by calling the low-level hardware primitives of the field-programmable gate array.
[0018] The unique physical identifier sequence can be a device identifier, chip serial number, or DeviceDNA embedded in the FPGA chip at the factory, or an identifier sequence obtained by stabilizing a physically non-clonable function response. This sequence is associated with a specific chip and reflects device binding characteristics. Because different chips have different device identifiers or physical responses, even if an attacker copies the configuration data, it is difficult to obtain the same authentication input on another unauthorized chip, thereby increasing the binding strength between the configuration data and the specific hardware entity.
[0019] In some FPGA architectures, this underlying sequence can be accessed through specific hardware primitives. For example, in some Xilinx architectures, the device identifier can be read through the DNA_PORT primitive. Driven by the system clock, the internal control logic provides a shift enable signal to this primitive module and obtains the unique physical identifier sequence fixed at the factory by serial shifting bit by bit. This sequence typically remains stable throughout the chip's lifecycle and can serve as the hardware identity basis for the scheme in this embodiment.
[0020] Phase Two: Physical Identification Verification and Trust Status Establishment.
[0021] After successfully extracting the unique physical identifier sequence, the system can use hardware logic to compare the unique physical identifier sequence with preset authentication information to generate an authentication result. This stage is used to confirm whether the currently loaded hardware configuration data matches the current physical chip.
[0022] To achieve secure comparison, during the device's R&D, production, and configuration phases, a secure configuration server can extract the unique physical identifier sequence of legitimate chips through a trusted channel. To mitigate the risk of this plaintext sequence being leaked in the configuration data, the server performs a pre-defined one-way hash operation on the unique physical identifier sequence to generate a fixed-length authentication digest. Subsequently, this authentication digest, as pre-set authentication information, can be synthesized, mapped, and embedded in the FPGA's hardware logic gate array or configuration data stream in read-only constant form.
[0023] During the actual authentication and comparison process at the device terminal, a secure finite state machine (FSM) can be constructed internally, operating independently of the central processing unit (CPU). This state machine executes a hardware-based module of the one-way hash algorithm corresponding to the configuration phase on the unique physical identifier sequence read serially in real time, such as the SHA-256 algorithm, to obtain a real-time digest. Subsequently, the hardware comparison circuit compares this real-time digest bit-by-bit with the pre-set authentication information embedded in the logic. Due to the avalanche effect of hash algorithms, bit differences in the underlying physical identifiers may cause significant changes in the final generated real-time digest.
[0024] After comparison, if the real-time summary matches the preset authentication information, the system's internal circuitry outputs a high level or a specific logic flag, generating an authentication result indicating successful authentication. If the two do not match, for example, if the configuration file is burned into another unauthorized FPGA chip, the real-time summary and preset authentication information will not match due to changes in the underlying physical identifier. The comparison circuit will output a low level or an error flag, generating an authentication result indicating failed authentication. This hardware-driven binding mechanism reduces the risk of cloning and theft after the hardware-software binding relationship is broken.
[0025] Phase 3: Hybrid seed generation and nonlinear working key derivation.
[0026] When the authentication result in the second stage indicates successful authentication, the system enters the most critical dynamic key derivation process. The system generates a working key based on the unique physical identifier sequence and the external input key.
[0027] Traditional devices may store working keys or master keys used for encrypting and decrypting core data in ROM or external storage media in static plaintext or simple obfuscation form, which poses a risk of extraction. This embodiment reduces the reliance on persistent key storage and adopts a field-based dynamic derivation mechanism. The external input key can come from multiple sources, such as management passwords entered by the user through the terminal, the initial master session key injected by the Trusted Platform Module (TPM) via the I2C bus, or challenge-response credentials issued by an external remote server through an encrypted channel.
[0028] In the specific algorithm flow for generating the working key based on the physical identifier and external key, the system can employ specially configured hardware logic circuits to reduce the risk of software microcode injection attacks affecting the key derivation process. The specific implementation steps are as follows: First, within the FPGA logic, a shift register network performs a cyclic shift operation on the unique physical identifier sequence according to preset shift parameters. At the hardware level, this cyclic shift can be implemented through cross-connects or shift registers to change the bit order of the original physical feature sequence, reducing the risk of inferring the underlying physical sequence through known plaintext analysis. Second, the system performs a bitwise XOR operation between the external input key obtained through the interface and the shifted unique physical identifier sequence. Through this operation, the system fuses the device's chip-binding characteristics with logical authentication credentials, increasing the difficulty of inference under differential power analysis (DPA) attacks.
[0029] Subsequently, the system further performs a modular addition operation with a preset offset on the data generated by the XOR mixture to generate a mixing seed. This modular addition operation introduces an arithmetic nonlinear mapping to increase the complexity of the reverse derivation. Finally, the system starts its internal pipelined hash engine, inputting the aforementioned mixing seed into the engine to perform hash operations. After a predetermined clock cycle, the pipelined hash engine outputs fixed-length data as the generated working key.
[0030] This series of derivation processes, which obtains multi-level transformations from the bottom layer, ensures that the working key mainly exists in the volatile registers inside the FPGA during the operation phase, rather than being fixed in plaintext in external non-volatile storage units. This reduces the risk of recovering the working key by reading the non-volatile storage medium after a power outage.
[0031] Phase 4: Protected logic recovery based on the working key.
[0032] After the correct working key is derived, the system uses the working key to restore the protected logic to work.
[0033] In one implementation, the protected logic can be a core logic netlist that has undergone logic obfuscation. During the netlist synthesis stage of Electronic Design Automation (EDA), security design tools can modify the original core business logic of the device (e.g., the netlist structure responsible for critical modules such as Ethernet packet parsing and routing table lookup) and insert obfuscation units, such as controlled XOR gates and key multiplexers. The control terminals of these obfuscation units constitute the logic unlocking interface of the netlist, enabling the original business circuits to rely on specific key data for decoding.
[0034] During operation, the control unit uses the working key calculated in the previous stage as the unlocking bitstream and injects it in real time into the control terminal of the core logic netlist to perform decoding operations. Since this working key is derived from a specific unique physical identifier sequence, it is easier to derive the bitstream matching the netlist obfuscation pattern on the original FPGA chip. If the device operates in an unauthorized environment (incorrect physical identifier) or is injected with an incorrect external input key, the working key injected into the core logic netlist will not match the expected one. In this case, the obfuscation unit inside the netlist can guide the signal into an incorrect transmission path, resulting in a logic cascading error.
[0035] In the event of a mismatch in working keys, the core logic netlist can output out-of-order data, causing anomalies in bus arbitration, state transition instructions, or data buffer control, thereby maintaining the prohibited state of the protected data path and reducing the risk of restoring core logic functions through simple bypass methods.
[0036] Phase 5: Safety state machine monitoring and anomaly detection.
[0037] The above process is used to achieve secure authentication and dynamic unlocking when the device is powered on. During subsequent operation, the device may still face abnormal states caused by factors such as fault injection, electromagnetic interference, or single event upset (SEU). For example, the registers of the safety finite state machine may be disturbed, causing it to abnormally jump from the "unauthenticated" state to the "authenticated" state.
[0038] To address this, this method constructs a hardware anomaly detection mechanism. Specifically, the system does not rely solely on a single state machine, but rather constructs multiple (e.g., three) parallel, independent state machine replicas. These state machine replicas are logically identical and can be distributed across different physical areas during the placement and routing phase. This spatial redundancy (TMR) design reduces the probability of multiple replicas flipping simultaneously due to local physical interference. Multiple independent state machine replicas synchronously monitor device operating parameters, including physical identifier comparison results and status monitoring of device debugging interfaces (such as the JTAG Joint Test Working Group interface). The monitoring logic analyzes the test clock transitions and mode selection instruction sequences of the JTAG interface and generates anomaly records when unauthorized scan access characteristics are identified.
[0039] During runtime, the system uses a hardware majority voter to vote on the output states of multiple independent state machine replicas, such as a two-out-of-three logic. When a single-event upset or environmental noise causes a single point of failure in one replica, the majority voter can output the voting state based on the other normal replicas and feed this voting state back to the abnormal state machine replica for register rewriting. This self-correction mechanism enhances the system's anti-interference capability in complex environments. When the majority voter determines that the duration or number of errors exceeds a preset safety threshold, such as continuous illegal probes to the JTAG interface or multiple state machine replicas simultaneously experiencing uncorrectable error states, the system detects abnormal tampering and issues an alarm and blocking signal.
[0040] Phase 6: Security Response and Lockdown Procedures.
[0041] When the authentication result indicates that the authentication failed (due to a comparison failure during the startup phase) or abnormal tampering is detected during the operation phase, the system can take corresponding security blocking measures within a preset time to reduce the risk of leakage of core data and keys. The system will maintain the prohibited state of the protected data path and execute a hierarchical security response.
[0042] The first step is to clean up the volatile storage environment. Within a preset clock cycle after receiving a security signal indicating an anomaly, the system can concurrently activate the reset pins of the sensitive registers and internal caches to perform a register clearing operation. This operation clears the working key, intermediate state nodes of hash operations, and related configuration variables of the decoding core netlist stored in volatile memory (SRAM), thereby reducing the risk of recovering the key or state through volatile residual data after an anomaly occurs.
[0043] Subsequently, a lock flag writing operation is performed. The system writes a preset lock flag into the power-down retained or protected secure storage medium in the device via the internal bus, for example, writing a lock status code to a specific address range. In actual devices, the power-down retained or protected secure storage medium can be selected from different types of memory, including but not limited to any one or a combination of the following: on-chip battery-backed random access memory (BBRAM) that relies on battery power to maintain data, on-chip secure flash memory with tamper-proof characteristics, one-time programmable fuses (eFuse), and on-board external electrically erasable programmable read-only memory (EEPROM) protected by encrypted links or authentication protocols.
[0044] After the locking flag is written to the power-down retained or protected secure storage medium, the device's underlying boot loader can read the locking flag during the initial power-on self-test phase. When the device, after triggering a security response, is powered off and restarted, if the locking flag is detected, the system boot loader can suspend the subsequent loading process, refuse to continue loading core configuration data to the FPGA, and trigger an abnormal alarm indication.
[0045] In equipment manufacturing or network infrastructure scenarios with high security requirements, as an optional implementation of the present invention, the security response may further include restrictive locking of the underlying interface, provided the chip architecture supports it and the policy allows. For example, in a chip architecture that supports programmable fuses, the system can write security configuration bits that disable debugging or readback through the eFuse control interface provided by the manufacturer; or in a chip architecture that supports internal configuration access, configuration clearing, reloading the security state, or disabling the debug access path can be triggered through the internal configuration access port (ICAP). These optional enhanced implementations can extend the security response from the logic control layer to the chip configuration control layer to adapt to the protection requirements of devices with higher security levels.
[0046] In summary, the method of this embodiment combines the physical identifier bound to the FPGA chip with nonlinear key derivation, netlist logic obfuscation, and parallel state machine monitoring technology. This can reduce the risk of traditional static keys being stripped and stolen at the logic function level, and form a constraint mechanism based on the unique identifier of the device on the hardware side, thereby providing a reliable foundation for the secure startup and operation of electronic devices.
[0047] To implement the device authentication and key derivation methods in the aforementioned embodiments, this embodiment proposes a corresponding electronic device.
[0048] This electronic device is typically a network communication hardware device with high security protection requirements, such as a security firewall, border gateway, industrial IoT controller, or signal processing base station with high security requirements.
[0049] Specifically, the electronic device in this embodiment includes a network communication interface and a field-programmable gate array (FPGA) chip, which serves as the core of system control and data processing. The network communication interface is mainly responsible for receiving and sending various network data packets and may include multiple gigabit or 10-gigabit Ethernet physical layer chips (PHY) and high-speed optical module interfaces.
[0050] In this device architecture, the field-programmable gate array (FPGA) chip not only handles service data forwarding and protocol parsing, but its internal programmable logic resources can also be divided into a general interface domain and a protected secure computing domain during the design synthesis phase. Specifically, the following main hardware modules can be configured and instantiated within the FPGA chip: (1) Identifier Extraction Module: This module is responsible for reading the unique physical identifier sequence reflecting the chip's binding characteristics in a serial timing sequence at the initial stage of power-on by calling the chip's underlying device identifier primitives or non-clonable feature array interface. This module can have anti-glitch filtering capabilities to improve the reliability of the extracted sequence.
[0051] (2) Authentication and comparison module: This module contains constant authentication information (i.e., pre-set authentication information) that is pre-integrated into the netlist structure, and has a built-in data processing unit (such as a one-way hash operator). It is responsible for converting the extracted real-time physical sequence into digest information and performing hardware-level Boolean verification with the solidified information, thereby outputting a level enable signal to determine whether the data path can be unlocked.
[0052] (3) Key Derivation Module: This module includes a multi-level shift register, an XOR logic gate array, and a modular adder network, and a pipelined hash hardware engine is cascaded at the end. This module receives a unique physical identifier sequence and an auxiliary key from an external source, and dynamically synthesizes a working key stored in a volatile register through nonlinear perturbation and hashing operations of the hardware logic.
[0053] (4) Protected Logic Module: This module covers the core service netlists of the device (such as high-speed route lookup tree, deep packet inspection engine, etc.). These service netlists can be obfuscated in advance by secure EDA tools and introduced into key gate units. When the matching working key bit stream output by the above key derivation module is received, the internal wiring path of this module can restore the normal Boolean logic function.
[0054] (5) Security Control Module: This module undertakes system-level monitoring and handling tasks. Its core architecture can adopt a parallel state machine array with multi-modal redundancy (such as triple modular redundancy TMR). It is not only responsible for abnormal transition detection and majority voting self-healing of debug pins (such as JTAG test clock, data output port, etc.), but also responsible for triggering the underlying reset network to clear the key register in parallel when abnormal tampering behavior is determined, and controlling the I2C / SPI controller to write the lock status code to the onboard or on-chip power-down retained or protected security storage medium.
[0055] Through the coordinated operation of the aforementioned internal hardware logic modules, this electronic device can execute the steps of the FPGA-based physical binding device authentication and key derivation method during startup self-test and continuous operation. This design establishes a binding relationship between the software configuration flow and the hardware entity during the authentication and key derivation process, enhancing the device's hardware and software anti-counterfeiting and anti-tampering capabilities in complex network environments.
[0056] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.
Claims
1. A method for device authentication and key derivation based on FPGA physical binding, characterized in that, include: In response to the device being powered on, the protected data path is disabled; The unique physical identifier sequence of the chip is read by calling the underlying hardware primitives of the field-programmable gate array; The authentication result is generated by comparing the unique physical identifier sequence with the preset authentication information. When the authentication result indicates that the authentication is successful, a working key is generated based on the unique physical identifier sequence and the external input key, and the working key is used to restore the protected logic to work. When the authentication result indicates that the authentication failed or abnormal tampering was detected, the protected data path is kept in a prohibited state and a security response is executed.
2. The method of claim 1, wherein, The response to powering on the device and disabling the protected data path includes: Enable the reset signal or disable signal of the peripheral interconnect bus and media access control layer to restrict the protected data path; The step of calling the underlying hardware primitives of the field-programmable gate array to read the unique physical identifier sequence of the chip includes: obtaining, through serial reading, a sequence with device binding characteristics that is fixed at the underlying layer when the chip leaves the factory, as the unique physical identifier sequence.
3. The method of claim 1, wherein, The pre-set authentication information is generated in the following manner: Extract the unique physical identifier sequence of the legitimate chip and perform a one-way hash operation to generate an authentication digest. Then, embed the authentication digest as the preset authentication information into the logic circuit or configuration data of the field-programmable gate array. The step of comparing the unique physical identifier sequence with the preset authentication information to generate an authentication result includes: performing the same one-way hash operation on the read unique physical identifier sequence in real time to obtain a real-time digest, and comparing the real-time digest with the preset authentication information. If they match, an authentication result indicating successful authentication is generated; otherwise, an authentication result indicating unsuccessful authentication is generated.
4. The method of claim 1, wherein, The step of generating a working key based on the unique physical identifier sequence and the external input key includes: The unique physical identifier sequence is cyclically shifted according to preset displacement parameters; The external input key is XORed with the shifted unique physical identifier sequence, and then modulo-added with a preset offset to generate a hybrid seed. The mixed seed is input into the pipelined hash engine to perform hashing operations and output the working key.
5. The method of claim 1, wherein, The step of using the working key to restore the protected logic to work includes: The protected logic is a core logic netlist that has been logically obfuscated during the design phase and is configured to rely on the correct working key for logic decoding. The calculated working key is injected into the core logic netlist in real time to perform decoding operations; If the working key is incorrect, the core logic netlist outputs out-of-order data to maintain the prohibited state of the protected data path.
6. The method of claim 1, wherein, The method for detecting abnormal tampering behavior includes: Multiple parallel independent state machine replicas are constructed to synchronously monitor the running status of device interfaces and debug interfaces in real time. The output states of multiple independent state machine replicas are voted on by a majority voter. When a single point of failure is detected, the state that was voted correct is fed back to the copy of the state machine that had the failure for forced state rewriting. When the majority voter determines that a continuous abnormal detection or tampering action has occurred, it is determined that the abnormal tampering behavior has been detected.
7. The method of claim 6, wherein, Synchronous real-time monitoring of the operating status of the debugging interface includes: By utilizing the multiple parallel independent state machine replicas, the level transition sequence of the test clock TCK pin and the test mode selection TMS pin of the Joint Test Working Group JTAG interface is monitored in real time to identify unauthorized scan probes or debug access behaviors.
8. The method according to claim 1, characterized in that, The execution security response includes: After receiving a security signal indicating an anomaly, a register clearing operation is performed to clear the working key and related logical state stored in volatile memory; And write a lock flag into the power-off retention or protected security storage medium in the device.
9. The method according to claim 8, characterized in that, The power-loss retention or protected security storage medium includes any one or a combination of the following: On-chip battery backup random access memory, on-chip secure flash memory, one-time programmable fuse area, and on-board electrically erasable programmable read-only memory protected by links; After the lock flag is written to the power-loss retained or protected security storage medium, the device may refuse to continue loading core configuration data in response to a power-off restart operation.
10. An electronic device, characterized in that, This includes network communication interfaces and field-programmable gate array (FPGA) chips; The field-programmable gate array chip is internally configured with: The module includes an identifier extraction module, an authentication comparison module, a key derivation module, a protected logic module, and a security control module. The field-programmable gate array chip is configured to execute the FPGA-based physical binding device authentication and key derivation method as described in any one of claims 1-9 during the startup and operation phases.
