Device verification method and electronic device

Abstract

This application discloses a device verification method and electronic device, relating to the field of device verification technology. The device verification method includes: in response to the authentication structure file signature conforming to the protocol specification requirements of the authentication platform, parsing the authentication structure to obtain the terminal entity certificate, the encrypted device private key, and the target verification code; verifying the encrypted device private key based on the unique identifier of the target device; in response to successful verification, decrypting the encrypted device private key to obtain the plaintext device private key; verifying the digital signature of the terminal entity certificate using the authentication platform's root certificate public key; in response to successful verification, generating a random number; obtaining the signature result of the response data packet; and if the authentication platform's root certificate public key of the terminal entity certificate verifies the signature result, determining that the target device has been successfully verified. This solves the technical problem in related technologies where attackers simulate legitimate verification responses and forge successful verification, thereby improving the reliability of device verification.

Description

Technical Field

[0001] This application relates to the field of equipment verification technology, and in particular to an equipment verification method and electronic device. Background Technology

[0002] In critical sectors such as servers, data centers, and industrial control, the security of storage devices is paramount. Device authentication technology aims to verify the legitimacy of devices, preventing data breaches, system failures, or security attacks caused by the use of counterfeit, tampered, or unauthorized branded devices.

[0003] Currently, the mainstream device verification scheme is a firmware-level identifier authentication technology. Its entire authentication process is executed at the driver layer of the host operating system kernel. This heavily relies on the host's software environment. Attackers can use FPGAs (FPGAs) to listen to the response data packets of legitimate devices and hardcode them into a fake device. When the host requests device information, the fake device only needs to return the pre-recorded legitimate response data packet as is, easily passing the host's triple verification, resulting in a significant decrease in the reliability of device verification. Summary of the Invention

[0004] This application provides a device verification method and an electronic device to at least solve the technical problem in the related art that attackers can simulate legitimate verification responses and forge verification success.

[0005] This application provides a device verification method applied to an authentication platform processor. The device verification method includes:

[0006] In response to system startup, the system retrieves the file signature of the authentication structure from the target firmware reserved area of ​​the target device; in response to the file signature conforming to the protocol specifications of the authentication platform, it parses the authentication structure to obtain the terminal entity certificate, the encrypted device private key, and the target verification code; it obtains the unique identifier of the target device and verifies the encrypted device private key based on the unique identifier of the target device; in response to the encrypted device private key being verified, it decrypts the encrypted device private key to obtain the plaintext device private key; it verifies the digital signature of the terminal entity certificate using the pre-set authentication platform root certificate public key; in response to the digital signature verification of the terminal entity certificate being verified, it generates a random number; in response to receiving a response data packet, which includes the plaintext device private key and the signature result generated based on the random number, it verifies the signature result based on the authentication platform root certificate public key of the terminal entity certificate; in response to the signature result verification being verified, it is determined that the target device has been verified.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the device verification method described below.

[0008] In response to system startup, the system retrieves the file signature of the authentication structure from the target firmware reserved area of ​​the target device; in response to the file signature conforming to the protocol specifications of the authentication platform, it parses the authentication structure to obtain the terminal entity certificate, the encrypted device private key, and the target verification code; it obtains the unique identifier of the target device and verifies the encrypted device private key based on the unique identifier of the target device; in response to the encrypted device private key being verified, it decrypts the encrypted device private key to obtain the plaintext device private key; it verifies the digital signature of the terminal entity certificate using the pre-set authentication platform root certificate public key; in response to the digital signature verification of the terminal entity certificate being verified, it generates a random number; in response to receiving a response data packet, which includes the plaintext device private key and the signature result generated based on the random number, it verifies the signature result based on the authentication platform root certificate public key of the terminal entity certificate; in response to the signature result verification being verified, it is determined that the target device has been verified.

[0009] The device verification method provided in this application can, in response to system startup, obtain the file signature of the authentication structure from the target firmware reserved area of ​​the target device; in response to the file signature conforming to the protocol specification requirements of the authentication platform, parse the authentication structure to obtain the terminal entity certificate, the encrypted device private key, and the target verification code; obtain the unique identifier of the target device, and verify the encrypted device private key based on the unique identifier of the target device; in response to the encrypted device private key verification passing, decrypt the encrypted device private key to obtain the plaintext device private key; verify the digital signature of the terminal entity certificate using the pre-set authentication platform root certificate public key; in response to the digital signature verification passing, generate a random number; in response to receiving a response data packet, the response data packet including the plaintext device private key and the signature result generated based on the random number, verify the signature result based on the authentication platform root certificate public key of the terminal entity certificate; in response to the signature result verification passing, determine that the target device has been verified.

[0010] Thus, the entire device verification process in this application is executed within the authentication platform processor, with the execution environment independent of the main operating system. Malware at the host operating system level cannot spy on, interfere with, or tamper with the authentication process, thereby shrinking the attack surface from the massive operating system kernel and solidifying it into a small piece of rigorously designed hardware chip. This ensures that the device verification logic itself is not interfered with by malware. By encrypting and verifying based on the unique identifier of the target device, the device identity is deeply bound to the physical hardware. Even if an attacker clones the entire authentication structure to another device, the unique identifier of each device is different, making it impossible to correctly decrypt the private key and generate a valid verification response. This solves the technical problem of static authentication data being easily cloned in related technologies. This application constructs a complete trust chain, using the root certificate public key built into the authentication platform processor as the root of trust. By verifying the digital signature of the terminal entity certificate through the root certificate, it confirms that the certificate was issued by a trusted authority and that its content has not been tampered with, thereby trusting the public key in the certificate. By verifying the signature result corresponding to the random number through the public key of the terminal entity certificate, it confirms that the responder has the corresponding private key, thereby trusting the device's identity. Only when the signature result verification result is passed can it be proven that the device has a legitimate private key that is bound to the unique identifier of the target device. The trust chain constructed in this way ensures that the trustworthiness of each link originates from the previous link, ensuring end-to-end trust from hardware to the application layer. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic flowchart illustrating a device verification method provided in an embodiment of this application;

[0013] Figure 2 A schematic flowchart illustrating a device verification method provided in another embodiment of this application;

[0014] Figure 3 A schematic flowchart of a device verification method provided in another embodiment of this application;

[0015] Figure 4 A schematic flowchart of a device verification method provided in another embodiment of this application;

[0016] Figure 5 This is an internal structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0019] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] In related technologies, current device anti-counterfeiting technology achieves authentication by embedding a manufacturer-specific identifier at the firmware layer. Its core mechanism involves writing the encrypted manufacturer logo (identifier) ​​information into the non-volatile storage area of ​​the device controller, typically located in the 0xAB~0xAF reserved sectors of the Flash chip. This identifier employs a multi-layered encryption structure: a 4-byte header (fixed value 0xAA55), an 8-byte unique manufacturer ID, a 256-byte digital signature based on ECDSA-SHA256, and a 4-byte CRC32 verification code. During production, OEM-authorized devices perform the flashing process via the SATA debug interface. The digital signature uses the manufacturer's private key to encrypt the ID, while the public key is pre-installed in the host driver. Upon system startup, the IDENTIFY_DEVICE command (opcode 0xEC) from the SATA specification is sent to request device information. The device firmware extracts the identifier data from the reserved area and fills it into bytes 108-127 of the return packet. The host verification process includes three verification steps: first, checking the fixed value in the header to confirm the identifier's existence; second, decrypting the signature using the pre-installed public key to verify the ID's authenticity; and finally, matching the CRC checksum to ensure data integrity. This solution has extremely low implementation costs, high verification efficiency, and is compatible with all devices using SATA 2.0 and above. However, it presents significant security vulnerabilities:

[0021] Suppose an FPGA development board or dedicated tool is used to monitor the communication between a legitimate host and a legitimate device, capturing complete device data response packets containing encrypted identifiers. These captured legitimate response packets are then hard-coded into the FPGA's logic. When a fake device connects to the host and receives the 0xEC command, the FPGA directly returns the previously captured legitimate data packet to the host unchanged. Upon receiving this response, the host driver executes a verification process: The response packet originates from the real device, and the ID obtained by decrypting the signature using a preset public key matches the received ID, resulting in successful verification. Therefore, in related technologies, attackers who have failed CPU processor authentication can use the FPGA to simulate legitimate responses.

[0022] In other words, these technologies assume the host operating system and its drivers are trustworthy. Under these circumstances, if an attacker can implant a malicious driver or hijack a legitimate driver, they can bypass all verification logic and directly forge a verified status. Furthermore, the public key is stored on the device, which attackers can easily read and even replace. The verification code runs on the host CPU's regular operating system, completely exposed to malware, kernel vulnerabilities, and attackers. Device information query commands and their responses are transmitted in plaintext on the SATA bus, making them highly susceptible to eavesdropping and replay. Therefore, the chain of trust in these technologies is broken.

[0023] like Figure 1 As shown, an embodiment of this application provides a device verification method applied to an authentication platform processor. The method specifically includes the following steps:

[0024] Step 101: In response to system startup, obtain the file signature of the authentication structure from the target firmware reserved area of ​​the target device.

[0025] The executing entity of this application is the authentication platform processor, specifically the ART trusted authentication module under the AMD processor platform. AMD processors themselves belong to a trusted execution environment, and the device verification methods in this application are all applied to AMD processors to ensure that security-sensitive data is within the security boundary and that device verification is completed using data within the security boundary.

[0026] The target device in this application can be a hard drive, and the target firmware reserved area can be a predefined reserved area, which can be an area that will not be erased or rewritten during firmware upgrade operations. For example, a contiguous and sufficiently large reserved area can be pre-defined in the device firmware image (firmware_image.bin), and the address of this area is usually fixed (such as 0x5000) as the target firmware reserved area.

[0027] Please see Figure 2This application first needs to determine whether to enable the device verification process when the server boots up. The decision to enable the device verification process requires deep integration of actual customer needs and comprehensive considerations from the production side. The core objective is to provide customers with flexible and matching options, maximizing the balance between security and cost in different scenarios. Customer needs are the primary driving force behind the configuration of anti-counterfeiting features. For customers in industries that are sensitive to data processing, the device verification process is not only a strong recommendation but also a mandatory entry barrier. Enabling these features effectively resists risks such as physical theft, malicious firmware implantation, and supply chain "packet swapping," providing a trusted verification chain from the hardware layer to the data layer, which is an indispensable cornerstone for building their security system. On the production side, based on technical capabilities and cost structures, forcibly enabling all advanced anti-counterfeiting features may exceed their actual needs simply to test the performance of a certain device, potentially reducing product competitiveness. This model transforms the simple "on / off" decision into a "tiered selection" that meets diverse market demands. It ensures that high-value customers receive the top-tier protection they need, while providing more options for those without such needs. It also enables the production end to carry out efficient and controllable large-scale production based on predefined standardized modules, achieving a win-win situation for both customer satisfaction and production efficiency.

[0028] If it is determined that the device verification process does not need to be started, the normal boot process is executed. If it is determined that the device verification process needs to be started, the device verification system is started and the device verification process is executed.

[0029] In response to system startup, before obtaining the file signature of the authentication structure from the target firmware reserved area of ​​the target device, the process includes: obtaining a device key package, the device key being authorized by the authentication platform processor, the device key package including the terminal entity certificate signed by the authentication platform root certificate and the encrypted private key file corresponding to the terminal entity certificate; obtaining the unique identifier of the target device; and controlling the embedding of the device key package and the unique identifier of the target device into the target firmware reserved area to form the authentication structure.

[0030] This application acquires a device key package upon system startup. This device key package is an encrypted RSA-2048 device key package obtained from an AMD-authorized Certificate Authority (CA). This key package should contain: Terminal entity certificate: An X.509 certificate signed by the AMD root certificate, containing the device's public key and device identification information. Encrypted private key file: An RSA-2048 private key paired with the public key in the certificate, which is encrypted using a high-strength algorithm (such as AES-256). The received key package should be immediately transferred to a secure, offline development environment for further processing to prevent the private key from being leaked during the preparation phase.

[0031] Compared to obtaining root certificates through OEM manufacturers or third-party certificate authorities, the root certificate in this application is either an AMD root certificate or a certificate issued by an AMD-authorized CA, which makes device verification deeply integrated into the AMD security processor, ensuring the consistency and unbypassability of the verification process.

[0032] Specifically, the control embeds the device key packet and the unique identifier of the target device into the target firmware reserved area to form an authentication structure, including:

[0033] The process involves: obtaining a first encryption key, which is a shared key agreed upon with the authentication platform processor; decrypting the device key packet based on the first encryption key to obtain a plaintext device key packet, which includes a plaintext terminal entity certificate and a plaintext device private key; encrypting the plaintext device private key using a first derived key to obtain an encrypted device private key, thereby binding the encrypted device private key to the target device firmware; wherein the first derived key is generated based on the unique identifier of the target device and is used for key packaging encryption; calculating the target verification code based on the encrypted device private key using a second derived key, wherein the second derived key is generated based on the unique identifier of the target device and is used to calculate the target verification code; and controlling the writing of the plaintext terminal entity certificate, the encrypted device private key, and the target verification code into the reserved area of ​​the target firmware according to a preset field structure to form an authentication structure.

[0034] A dedicated key injection tool can be used to input a device key package obtained from AMD and the unique identifier of the target device. This unique device identifier includes, for example, a serial number, vendor code, hardware version number, pre-installed certificate, or digital signature.

[0035] This application employs a three-layer encryption injection mechanism. First, the first layer of encryption utilizes AES-256-GCM local decryption and authentication. Specifically, a pre-shared, secure local key encryption key (KEK) is used to decrypt the device key packet, yielding a plaintext device key packet containing the plaintext terminal entity certificate and the plaintext device private key. GCM mode simultaneously provides confidentiality and integrity verification, ensuring the key packet remains untampered with locally. The second layer of encryption involves secondary encryption based on the target device's unique identifier to extract the plaintext device private key from the plaintext key packet. Specifically, a first derived key derived from the target device's unique identifier is used to perform secondary encryption on the plaintext device private key, resulting in an encrypted device private key.

[0036] The third layer of encryption generates a target verification code. Based on the second derived key, it calculates the HMAC-SHA256 verification code (target verification code) of the entire encrypted device private key to ensure that it cannot be tampered with after firmware injection. The second derived key can use another key derived from a key that uniquely identifies the target device.

[0037] Write the plaintext terminal entity certificate, the encrypted device private key, and the calculated target verification code into the target firmware reserved area according to the preset field structure.

[0038] For example, the preset field structure may include writing fields such as protocol version, total structure length, encrypted private key offset, authentication return value, reserved bytes, certificate length, encrypted private key length, HMAC verification code, device certificate, and encrypted private key, along with their corresponding data, into a binary data stream. Specifically, the protocol version is written with a fixed magic word, i.e., the ASCII code of the string 'A' 'R' 'T' '1'; the total structure length defines the size of the entire structure, and the encrypted private key offset is the position after the HMAC and certificate; the authentication return value is initially a default value, waiting to be written after ART authentication; reserved bytes can be filled according to specifications for future expansion; the certificate length defines the actual byte length of the certificate; the encrypted private key length defines the actual byte length of the encrypted private key; the HMAC verification code is a pre-calculated 32-byte HMAC value; the device certificate can be plaintext X.509 certificate data; and the encrypted private key is private key data encrypted with the unique identifier of the target device. Finally, these data are packaged into contiguous binary blocks according to the field order and burned into the reserved area of ​​the target firmware.

[0039] In one specific implementation, the preset field structure can be: the first 4 bytes set to 0xART1_AMD to identify the protocol version; 2 bytes define the total length of the structure; 2 bytes represent the offset position of the encrypted private key; and 1 byte represents the return value after ART authentication on the AMD platform. The constructed authentication structure is shown in Table 1.

[0040] Table 1

[0041]

[0042] By binding the encryption and decryption of the device's private key to a unique identifier corresponding to each device, even if an attacker clones the entire firmware, the attacker will not be able to decrypt the correct private key because the unique identifier of the new device is different. In other words, compared with the data packet verification method of related technologies, this application verifies a physical hardware entity, which can effectively deal with packet loss and forgery.

[0043] Step 102: In response to the file signature conforming to the protocol specifications of the authentication platform, parse the authentication structure to obtain the terminal entity certificate, the encrypted device private key, and the target verification code.

[0044] Specifically, in response to the file signature conforming to the protocol specifications of the authentication platform, the following steps are taken: in response to the system enabling the device verification function and setting the authentication platform root certificate public key in the target firmware reserved area, the authentication platform processor sends an instruction to the connected device to obtain the file signature of the authentication structure from the target firmware reserved area; in response to the file signature conforming to the protocol specifications of the authentication platform, the file signature authentication is considered successful, and the authentication platform processor reads the authentication structure into secure memory based on the file signature.

[0045] Please see Figure 3 This is in response to the fact that the device anti-counterfeiting function has been enabled in the system BIOS / UEFI and the AMD root certificate public key (authentication platform root certificate public key) is pre-installed in the firmware.

[0046] The authentication platform processor sends instructions to the connected device to retrieve the file signature of the authentication structure from a predetermined address in the device firmware. The file signature is a specific, unique constant value stored at the beginning of a file or data block, used to identify the format, type, or ownership of that data block. For example, the file signature could be "ART1," where ART represents the protocol specification and 1 represents a version of the protocol specification. This file signature is used to verify whether the authentication structure conforms to the target protocol version of AMD ART. If the file signature cannot be obtained, the device is considered not to support AMDART authentication. If the obtained protocol specification version is inconsistent and cannot be identified, an unsupported protocol version error can be returned. If the file signature authentication passes, it means the data format is valid and has been packaged into contiguous binary blocks according to defined rules. The authentication platform processor can then correctly and quickly parse all subsequent data based on fields such as total length and private key offset.

[0047] In response to successful file signature authentication, the authentication platform processor can read the authentication structure into secure memory based on the file signature. In practical applications, attackers can dynamically and in real-time modify the contents of the device firmware mapped to system memory during the authentication process (e.g., through operating system kernel vulnerabilities or DMA attacks). The authentication platform processor directly reads data from the memory address where the device firmware resides. An attacker can replace the certificate content in memory with a malicious but valid certificate after the authentication platform processor has read the certificate but before it has read the private key. This could cause the authentication platform processor to use an incorrect public key to verify the signature, thereby bypassing authentication. This application sets up the method of reading the authentication structure into secure memory, so that the authentication platform processor copies the complete and continuous structure from the (relatively insecure) device firmware area to the authentication platform processor's internal storage or its strictly protected secure memory at the beginning. Subsequently, all authentication operations (HMAC verification, certificate parsing, signature verification) are based on this "snapshot". Since the secure memory cannot be accessed by external systems or software, attackers lose the opportunity to tamper with data during the authentication process.

[0048] Step 103: Obtain the unique identifier of the target device, and verify the encrypted device private key based on the unique identifier of the target device; in response to the successful verification of the encrypted device private key, decrypt the encrypted device private key to obtain the plaintext device private key.

[0049] Specifically, obtaining the unique identifier of the target device and verifying the encrypted device private key based on the unique identifier of the target device includes: obtaining the target derived key, which is generated based on the unique identifier of the target device and predefined context information; calculating the authentication verification code of the encrypted device private key based on the target derived key; comparing the authentication verification code with the target verification code; and if the authentication verification code matches the target verification code, the encrypted device private key is considered to have been verified successfully.

[0050] The authentication platform processor reads the unique identifier of the target device through low-level instructions. Using this unique identifier, a target derived key is derived using the same KDF (Key Derivation Function, such as HMAC-SHA256(Target Device Unique Identifier, "ART_HMAC_Integrity_Key")). The predefined context information here is a fixed string or byte sequence agreed upon in advance during the system design phase. Its main purpose is to ensure: key derivation for specific purposes and cross-platform consistency; even using the same input key material (the target device's unique identifier), different parameters will result in completely different keys output by the KDF. The production end (OEM injection tool) and the verification end (target platform processor) must use exactly the same parameters to derive identical keys from the same target device's unique identifier, thus enabling successful encryption and verification. That is, two different derivation functions are derived based on the same target device's unique identifier and different parameters. The HMAC-SHA256 verification code is recalculated using the extracted encrypted device private key to obtain the authentication verification code. The authentication verification code is compared with the target verification code read from the authentication structure for integrity verification. If they do not match, authentication fails immediately, the authentication platform processor triggers a subsequent circuit breaker mechanism (such as shutting down the device power), and the process terminates.

[0051] Step 104: Verify the digital signature of the terminal entity certificate using the pre-set authentication platform root certificate public key; in response to the successful verification of the digital signature of the terminal entity certificate, generate a random number.

[0052] Specifically, verifying the digital signature of the terminal entity certificate using the pre-built authentication platform root certificate public key includes: in response to receiving a verification data packet, parsing the verification data packet to obtain the terminal entity certificate and the signature result, wherein the terminal entity certificate includes the digital signature to be verified; obtaining the authentication platform root certificate public key built into the authentication platform; verifying the digital signature to be verified based on the authentication platform root certificate public key; and considering the terminal entity certificate valid if the authentication platform root certificate public key verifies the digital signature to be verified successfully.

[0053] The authentication platform processor uses the pre-installed root certificate public key to verify the digital signature of the endpoint entity certificate. This step confirms that the certificate was indeed issued by AMD or its authorized CA and is trustworthy, thus implementing certificate chain verification. If verification fails, the certificate is deemed invalid, the entire authentication process immediately fails, an error code is written, a circuit breaker is triggered, and the process terminates. If verification succeeds, the engine trusts the public key in the certificate.

[0054] Step 105: In response to receiving a response data packet, which includes the device private key in plaintext and a signature result generated based on a random number, the signature result is verified using the root certificate public key of the authentication platform based on the terminal entity certificate. In response to the signature result being verified successfully, it is determined that the target device has been verified successfully.

[0055] The signature result is verified using the public key of the authentication platform root certificate based on the terminal entity certificate. In response to the successful verification of the signature result, the verification of the target device is determined to be successful, including: verifying the signature result based on the public key of the authentication platform root certificate; in response to the successful verification of the signature result using the public key of the authentication platform root certificate, it is considered that the target device holds the correct private key that matches the public key of the authentication platform root certificate in the terminal entity certificate, and the target device is verified to be successful.

[0056] After verifying the validity of the terminal entity certificate, the authentication platform processor generates a random number and sends it to the target device. The target device then signs the random number using its plaintext device private key and encapsulates it into a response data packet. The response data packet includes the terminal entity certificate and the signature result obtained by the device using its plaintext device private key to digitally sign the random number.

[0057] The authentication platform processor's internal random number generator generates a random number as a challenge code. The processor sends this random number to the target device's firmware, requesting it to sign it. Compared to related technologies that only verify the authenticity of device information, allowing attackers to forge device information, this application requires the device to use its corresponding private key to generate a random number, fundamentally solving the problem of identity theft.

[0058] The target device firmware also reads the target device's unique identifier. A decryption key is derived using the target device's unique identifier via KDF. This decryption key is then used to decrypt the encrypted device private key, yielding the plaintext device private key (this process is completed within the target device controller, and the private key is not exposed). The received random number is digitally signed using this plaintext device private key, resulting in a signature. The target device combines the signature result with the terminal entity certificate to form a ROM-formatted response data packet. This data packet is the target format response data packet. It is used by AMD's ART module to verify that the target device possesses the corresponding certificate's private key. The target device then transmits the encapsulated response data packet back to the host CPU via the system bus (such as PCIe). This channel itself may not have encryption capabilities, but the security of the core (signature) in the data packet does not depend on channel secrecy but on cryptographic strength.

[0059] The target device sends the corresponding data packet to the authentication platform processor, which then calls the ART authentication engine within its own processor to receive the response data packet. The environment in which the ART engine operates includes a Certificate Revocation List (CRL), a list of allowed vendor IDs, and policy rules (such as different verification strengths corresponding to different security levels). Under the trusted root certificate chain, the firmware of the specific authentication platform processor pre-programs AMD's root CA public key, which is the starting point for all trust.

[0060] After receiving the response data packet, the ART engine parses it, first extracting the terminal entity certificate. Key fields that can be extracted from the terminal entity certificate include: subject information, such as manufacturer, device model, device public key, signature algorithm, issuer information (should be AMD or its CA), validity period, digital signature to be verified, and signature result.

[0061] The authentication platform processor extracts the public key from the verified terminal entity certificate. This public key is then used to verify the signature returned by the device. If verification succeeds, it indicates that the device possesses a private key that matches the public key in the certificate and is encrypted and protected by the correct target device's unique identifier. The system then continues its normal startup process without any further prompts.

[0062] If verification fails, it means that the device cannot provide a correct signature (it may be a fake disk or a mismatched private key), which triggers a hardware-level response, such as cutting off the device power via BMC or PMC and displaying an error message on the display interface.

[0063] Through the above process, AMD ART not only verifies a static certificate, but also completes a dynamic, hardware-bound cryptographic authentication, forming an extremely powerful anti-counterfeiting mechanism.

[0064] In this application, the authentication platform processor generates a random number. The device signs this unique random number in real time using a private key bound to a unique identifier of the target device. At this point, the FPGA cannot predict the specific value of the next random number, therefore the data packets pre-recorded by the FPGA are invalid and cannot generate a valid signature response for the new random number. Furthermore, the root of trust in this application is AMD hardware and a root certificate, and the verification process is conducted within an independent, protected, trusted execution environment isolated from the CPU by hardware mechanisms. By binding the device key to the unique ID of each device, this application constructs a complete trust chain. The root certificate public key built into the authentication platform processor is used as the root of trust. The digital signature of the terminal entity certificate is verified through the root certificate to confirm that the certificate was issued by a trusted authority and that its content has not been tampered with, thus trusting the public key in the certificate. The signature result corresponding to the random number is verified through the public key of the terminal entity certificate to confirm that the responder possesses the corresponding private key, thus trusting the device's identity. Only when the signature result verification is successful can it be proven that the device possesses a legitimate private key bound to the unique identifier of the target device. This trust chain ensures that the trustworthiness of each link originates from the previous link, ensuring end-to-end trust from hardware to the application layer, thus constructing a complete trust chain.

[0065] In steps S102-S105, successful verification at any step unlocks full access to the hard drive, allowing the loading of protected firmware modules and even triggering a "secure boot" chain. Failure to verify triggers a tiered response based on preset strategies—from logging security events, limiting performance (e.g., slowing down operation), and isolating sensitive data partitions, to the most stringent physical-level protection (e.g., triggering firmware self-locking, clearing encryption keys, or activating hardware self-destruct circuits)—ensuring that counterfeit or tampered hard drives cannot obtain valid data or cause further harm. The entire process is deeply coupled at the hardware level, ensuring that the entire chain from reading to result execution is completed in a trusted execution environment, maximizing protection against side-channel attacks or malicious software intervention, and building a complete trust chain from the physical chip to logical access control.

[0066] The device verification method also includes: in response to the target device passing verification, entering the target device startup process; in response to the target device failing verification, forcibly shutting down the target device startup power and displaying alarm information on the display interface.

[0067] Please see Figure 4In this application, the device verification process is deeply integrated into the system startup sequence design. The response strategy to the verification result value returned by ART follows the core principle of "silent passage, explicit anomaly detection." After the system completes the reading of key data from the hard disk ROM during the power-on initialization phase and sends it to ART for high-strength cryptographic verification, if the value returned by ART is decrypted by the security coprocessor and compared with the rule base, and is confirmed to fully comply with all preset security policies, the system is determined to be in a "correct" security state. At this time, the startup process will remain extremely simple: no prompts related to hard disk anti-counterfeiting will be inserted into the power-on self-test (POST) interface, and the screen will only display the hardware detection list (such as CPU model, memory capacity, device enumeration status) in a standard order, ensuring a seamless and smooth user experience. This "no prompt equals security" design reduces information noise and implicitly conveys a state of trust—silent startup itself is the strongest endorsement of the hardware's legitimacy. Conversely, if the value returned by ART is "False," the system will immediately trigger an explicit alarm mechanism. Specifically, the firmware security module interrupts the normal boot process during the POST phase, forcibly taking over the display output and rendering a high-contrast error message framework in a prominent position on the screen (usually at the top or in a separate alarm area). This framework not only includes eye-catching visual identifiers (such as red borders and flashing icons), but also precisely outputs a qualitative warning of "hard drive anti-counterfeiting verification failed" and key numerical details, such as "Error code: 0x555 - CA fail" (indicating certificate chain verification failure). Simultaneously, the system will execute a preset circuit breaker strategy based on the error level: restricting hard drive access mode and triggering hardware-level isolation to disconnect the hard drive's power supply. This design ensures that any anti-counterfeiting failure event cannot be concealed, forcibly visualizing security risks at the user's most vigilant boot moment, while providing precise numerical anchors for subsequent forensics, forming a closed-loop defense from detection and alarm to handling.

[0068] The core technology is based on AMD ART Trusted Authorization technology. The process begins at system startup, first checking if the "hard drive anti-counterfeiting function" is enabled. If not, it boots normally. If enabled, the system obtains the EFI ROM information from the OEM manufacturer to identify the SATA hard drive requiring anti-counterfeiting verification. EFI ROM information refers to the firmware code used during computer startup; it contains the programming required to boot the computer, is crucial for startup, and executes major input / output tasks and saves programs or software instructions. Subsequently, it is passed to the AMD ART Trusted Authorization module for processing and obtaining its return value. The key step is analyzing this return value: if ART returns "True," the system displays no message and directly enters the normal boot process; if ART returns "False," the system will power off the hard drive, forcibly terminating the boot process, and display a "Error certificate key error" warning on the POST interface. The process then ends. This mechanism ensures the legitimacy of the bootable hard drive through hardware-level trusted verification, allowing the system to boot normally only when verification is successful and there are no anomalies; otherwise, it immediately interrupts and reports an error, thus preventing security risks from illegal or uncertified storage devices.

[0069] In one feasible implementation, after verifying the digital signature of the terminal entity certificate using a pre-set authentication platform root certificate public key, before generating a random number, a Uniform Resource Locator (URL) of an Online Certificate Status Protocol (OSP) response program can be obtained from a pre-set storage according to a pre-set security policy; a query request conforming to the OSP can be constructed based on the serial number and issuer information of the terminal entity certificate; the query request can be sent to the OSP response program via a network interface; and the digital signature of the status query response can be verified. The public key used to verify the digital signature of the status query response comes from a pre-set trusted OSP certificate or from the OCSP signer certificate specified in the terminal entity certificate. The status query response is a Certificate Revocation List (CRL) file. Initiating an online status query request involves downloading the latest CRL file from a pre-set CRL distribution point; verifying the status query response involves verifying the digital signature of the CRL file; and responding to a status query response indicating that a certificate has been revoked involves finding the serial number of the terminal entity certificate in the CRL file. If the status query response indicates that the terminal entity certificate has been revoked, the hard disk verification process is terminated and authentication failure handling is triggered. If the status query response indicates that the terminal entity certificate is in good condition, the random number generation step continues. If the status query response indicates that the terminal entity certificate is in good condition and includes a next update timestamp, the status query response is associated with the terminal entity certificate's serial number and securely cached. Within the validity period indicated by the next update timestamp, for subsequent authentication processes of the same terminal entity certificate, if an online status query is required, the cached response result will be used directly.

[0070] Specifically, the authentication platform processor may pre-configure at least one OCSP responder URL or a Certificate Revocation List distribution point URL. These addresses can be programmed during production or subsequently trusted by the system administrator through a security configuration interface.

[0071] After the authentication platform processor successfully verifies the digital signature of the endpoint entity certificate (i.e., ensures the certificate was issued by a trusted root and has not been tampered with), it does not immediately determine the certificate's validity. The authentication platform processor decides whether to perform an online status query based on pre-defined security policies. Security policies may include indications of extended fields in the certificate, current system security level settings, or mandatory queries for all certificates. Specifically, the authentication platform processor extracts information such as the serial number and issuer information from the endpoint entity certificate. The authentication platform processor constructs an OCSP status query request according to the OCSP protocol standard. This request includes information such as the serial number of the certificate to be checked. The authentication platform processor sends the query request to the designated OCSP responder through a secure network module (ensuring the authenticity of the request destination, such as using DoH or verifying the OCSP responder certificate). When verifying the endpoint entity certificate, the authentication platform processor connects to the Online Certificate Status Protocol (OCSP) server via a secure network or downloads a Certificate Revocation List (CRL) to check whether the certificate has been revoked.

[0072] The authentication platform processor receives an OCSP response from the OCSP Response Program and verifies the digital signature of the OCSP response. The public key used for verification comes from a pre-installed, trusted OCSP Response Program certificate, or from the OCSP signer certificate specified in the certificate. If the OCSP response signature verification fails, the online query is considered a failure, and the authentication result is determined according to the security policy (usually failure). After successful OCSP response signature verification, the processor parses the response body to obtain the certificate status. If the certificate status is good and has not been revoked, the authentication process continues. If the certificate has been revoked by the issuing authority, the authentication process terminates immediately, triggering the authentication failure circuit breaker mechanism.

[0073] By rigorously verifying the signature of the OCSP response itself, the security and trustworthiness of the online query process are ensured, preventing man-in-the-middle attacks. Not only is the certificate signature verified, but the certificate status is also checked in real time to prevent potentially lucrative key leakage attacks. Even if an attacker obtains a legitimate private key and clones the hard drive, the vendor can revoke its certificate, causing all servers worldwide running the platform to reject the hard drive, achieving a rapid response.

[0074] Embodiments of this application also provide an electronic device, such as... Figure 5 As shown, it includes a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the above-described device verification method embodiments.

[0075] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described device verification method embodiments when it is run.

[0076] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), mobile device, magnetic disk, or optical disk.

[0077] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0078] The above provides a detailed description of a device verification method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A device verification method, characterized in that, Applied to an authentication platform processor, the device verification method includes: In response to system startup, obtain the file signature of the authentication structure from the target firmware reserved area of ​​the target device; In response to the file signature conforming to the protocol specifications of the authentication platform, the authentication structure is parsed to obtain the terminal entity certificate, the encrypted device private key, and the target verification code; Obtain the unique identifier of the target device, and verify the encrypted device private key based on the unique identifier of the target device; in response to the successful verification of the encrypted device private key, decrypt the encrypted device private key to obtain the plaintext device private key; The digital signature of the terminal entity certificate is verified using the pre-set root certificate public key of the authentication platform; in response to the successful verification of the digital signature of the terminal entity certificate, a random number is generated; In response to receiving a response data packet, the response data packet includes a plaintext device private key and a signature result generated based on the random number. The signature result is verified based on the public key of the authentication platform root certificate of the terminal entity certificate. In response to the signature result being verified, it is determined that the target device has been verified.

2. The device verification method according to claim 1, characterized in that, The process of obtaining the file signature of the authentication structure from the target firmware reserved area of ​​the target device in response to system startup includes: Obtain a device key package, which is authorized by the authentication platform processor. The device key package includes a terminal entity certificate signed by the root certificate of the authentication platform and an encrypted private key file corresponding to the terminal entity certificate. Obtain the unique identifier of the target device; The controller embeds the device key packet and the unique identifier of the target device into the target firmware reserved area to form an authentication structure.

3. The equipment verification method according to claim 2, characterized in that, The control embeds the device key packet and the unique identifier of the target device into the target firmware reserved area to form an authentication structure, including: Obtain the first encryption key, which is a shared key agreed upon with the authentication platform processor; The device key packet is decrypted based on the first encryption key to obtain the plaintext device key packet, which includes the plaintext terminal entity certificate and the plaintext device private key. The plaintext device private key is encrypted using the first derived key to obtain the encrypted device private key, thereby enabling the encrypted device private key to be bound to the target device firmware. The first derived key is generated based on the unique identifier of the target device, and the first derived key is used for key packaging encryption. The target verification code is calculated based on the encrypted device private key using the second derived key, wherein the second derived key is generated based on the unique identifier of the target device and is used to calculate the target verification code. The system controls the writing of the plaintext terminal entity certificate, the encrypted device private key, and the target verification code into the target firmware reserved area according to a preset field structure to form an authentication structure.

4. The device verification method according to claim 1, characterized in that, The response that the file signature conforms to the protocol specifications of the authentication platform includes: In response to the system enabling the device verification function and setting the authentication platform root certificate public key in the target firmware reserved area, the authentication platform processor sends an instruction to the connected device to obtain the file signature of the authentication structure from the target firmware reserved area. If the file signature conforms to the protocol specifications of the authentication platform, the file signature authentication is considered successful, and the authentication platform processor reads the authentication structure into secure memory based on the file signature.

5. The equipment verification method according to claim 1, characterized in that, The step of obtaining the unique identifier of the target device and verifying the encrypted device private key based on the unique identifier of the target device includes: Obtain the target derived key, which is generated based on the unique identifier of the target device and predefined context information; The authentication verification code is calculated based on the target derived key and the encrypted device private key. The authentication verification code is compared with the target verification code. If the authentication verification code matches the target verification code, the encrypted device private key is considered to have been successfully verified.

6. The device verification method according to claim 1, characterized in that, The verification of the digital signature of the terminal entity certificate using the pre-set root certificate public key of the authentication platform includes: In response to receiving a verification data packet, the verification data packet is parsed to obtain the terminal entity certificate and the signature result, wherein the terminal entity certificate includes the digital signature to be verified; Obtain the public key of the root certificate of the authentication platform built into the authentication platform; The digital signature to be verified is verified based on the public key of the root certificate of the authentication platform; If the authentication platform's root certificate public key verifies the digital signature to be verified, then the terminal entity certificate is considered valid.

7. The device verification method according to claim 1, characterized in that, The process of generating random numbers includes: A random number is sent to the device to obtain a response data packet formed by the device signing the random number with its plaintext device private key and encapsulating it. The response data packet includes the terminal entity certificate and the signature result obtained by the device digitally signing the random number using the plaintext device private key.

8. The equipment verification method according to claim 1, characterized in that, The authentication platform root certificate public key based on the terminal entity certificate verifies the signature result, and in response to the signature result verification being successful, determines that the target device verification is successful, including: The signature result is verified based on the public key of the root certificate of the authentication platform; If the signature result is verified by the public key of the authentication platform root certificate, it is considered that the target device holds the correct private key that matches the public key of the authentication platform root certificate in the terminal entity certificate, and the target device verification is successful.

9. The device verification method according to claim 1, characterized in that, The device verification method further includes: Upon successful verification of the target device, the target device startup process begins. In response to the failure of the target device verification, the target device's power-on is forcibly shut down, and an alarm message is displayed on the screen.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the device verification method as described in any one of claims 1 to 9.

Images