WO2021012978A1 - 检测硬件的方法、装置、设备及存储介质 - Google Patents

检测硬件的方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2021012978A1
WO2021012978A1 PCT/CN2020/101699 CN2020101699W WO2021012978A1 WO 2021012978 A1 WO2021012978 A1 WO 2021012978A1 CN 2020101699 W CN2020101699 W CN 2020101699W WO 2021012978 A1 WO2021012978 A1 WO 2021012978A1
Authority
WO
WIPO (PCT)
Prior art keywords
hardware
binding relationship
key
relationship information
ciphertext
Prior art date
Application number
PCT/CN2020/101699
Other languages
English (en)
French (fr)
Inventor
张梦楠
乔立忠
陈海武
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to BR112022001162A priority Critical patent/BR112022001162A2/pt
Priority to EP20843600.6A priority patent/EP3982610B1/en
Priority to JP2021578090A priority patent/JP7347895B2/ja
Publication of WO2021012978A1 publication Critical patent/WO2021012978A1/zh
Priority to US17/581,212 priority patent/US12047388B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/73—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by creating or determining hardware identification, e.g. serial numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3278—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response using physically unclonable functions [PUF]

Definitions

  • This application relates to the field of security technology, in particular to methods, devices, equipment and storage media for detecting hardware.
  • the embodiments of the present application provide a method, device, device, and storage medium for detecting hardware to solve problems in related technologies.
  • the technical solutions are as follows:
  • a method for detecting hardware includes: sending first verification data to a physical carrier, the physical carrier carrying a plurality of hardware; receiving the ciphertext returned by the physical carrier and binding Relationship information, the ciphertext is obtained after at least two pieces of hardware of the plurality of hardware respectively encrypt the first verification data with their respective keys, and the binding relationship information is used to indicate the at least A binding relationship between two hardware; verifying the ciphertext and the binding relationship information, and determining the security of the at least two hardware based on the verification result.
  • the binding relationship information includes a binding relationship between keys corresponding to the at least two hardware;
  • the verification of the text and the binding relationship information includes: obtaining the keys corresponding to the at least two pieces of hardware, and verifying the binding relationship included in the binding relationship information based on the keys corresponding to the at least two pieces of hardware Whether it is correct; using the keys corresponding to the at least two hardware to decrypt the at least two hardware-encrypted ciphertexts respectively, and verify whether the second verification data obtained by the decryption is consistent with the first verification data; Determining the security of the at least two pieces of hardware based on the verification result includes: when the verification result is that the binding relationship included in the binding relationship information is correct, and the second verification data obtained by decryption is consistent with the first verification data, determining The at least two pieces of hardware are in a safe state.
  • the receiving the ciphertext and binding relationship information returned by the physical carrier includes: Receiving the ciphertext and notarization certificate returned by the physical carrier, the notarization certificate including the binding relationship between the keys corresponding to the at least two hardware, and also including the digital signature of the binding relationship;
  • the verification of the ciphertext and the binding relationship information includes: verifying whether the binding relationship included in the binding relationship information is correct based on the digital signature in the notarization certificate;
  • the keys corresponding to the two hardware respectively decrypt the at least two hardware-encrypted ciphertexts, and verify whether the second verification data obtained by the decryption is consistent with the first verification data;
  • the determining that the at least The security of the two pieces of hardware includes: when the verification result is that the binding relationship included in the binding relationship information is correct, and the second verification data obtained by decryption is consistent with the first verification data, determining that the at least two pieces of hardware are Safe state
  • the notarization certificate is used to verify the binding relationship between the hardware, which can be compatible with the standard TCG authentication protocol, and the binding relationship of the hardware is extended in the protocol, so that it has strong practicability.
  • the keys corresponding to the at least two hardware are determined by the at least The two hardwares are generated based on their respective hardware identifications.
  • the hardware identification is an inherent attribute of the hardware, it is unique, cannot be copied, and is protected by the hardware. Therefore, the hardware key is generated based on the hardware identification of the hardware. On the basis of improving the security of the key, the hardware Security is further improved.
  • the hardware identification includes a hardware unique key HUK, a physical unclonable function PUF, and a confidentiality-protected primary The identification information or endorsement key EK in the programmable OTP.
  • the key includes a symmetric key or an asymmetric secret key. key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key;
  • the ciphertext is obtained after the at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, and the binding relationship information is based on the relationship between the public keys corresponding to the at least two pieces of hardware.
  • the binding relationship is obtained.
  • a method for detecting hardware includes: receiving first verification data sent by a verification unit; obtaining ciphertext and binding relationship information, the ciphertext being multiple pieces of hardware carried on a physical carrier
  • the at least two pieces of hardware in the at least two pieces of hardware are obtained after encrypting the first verification data with their respective keys, and the binding relationship information is used to indicate the binding relationship between the at least two pieces of hardware;
  • the ciphertext and the binding relationship information are sent to the verification unit, and the verification unit verifies the ciphertext and the binding relationship information, and the security of the at least two pieces of hardware is determined based on the verification result.
  • the method before obtaining the binding relationship information, further includes: obtaining keys of the at least two hardware, based on the keys of the at least two hardware Obtain the binding relationship information and store the binding relationship information.
  • the binding is obtained based on the binding relationship between the keys of the at least two hardware Relationship information, storing the binding relationship information, including: registering the keys of the at least two hardware to obtain a notarization certificate, storing the notarization certificate, the notarization certificate includes the secrets corresponding to the at least two hardware
  • the binding relationship between the keys further includes the digital signature of the binding relationship; the obtaining the binding relationship information includes: obtaining the notarization certificate.
  • the keys corresponding to the at least two hardware are determined by the at least The two hardwares are generated based on their respective hardware identifications.
  • the hardware identification includes HUK, PUF, identification information in the confidentiality-protected OTP, or EK.
  • the key includes a symmetric key or an asymmetric secret key. key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key;
  • the ciphertext is obtained after the at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, and the binding relationship information is based on the relationship between the public keys corresponding to the at least two pieces of hardware. The binding relationship is obtained.
  • a device for detecting hardware includes: a sending module for sending first verification data to a physical carrier, the physical carrier carrying multiple pieces of hardware; a receiving module for receiving The ciphertext and binding relationship information returned by the physical carrier, the ciphertext is obtained after at least two pieces of hardware in the plurality of hardware respectively encrypt the first verification data with their own keys, The binding relationship information is used to indicate the binding relationship between the at least two pieces of hardware; the verification module is used to verify the ciphertext and the binding relationship information, and is used to determine the at least two pieces of information based on the verification result. The security of each hardware.
  • the binding relationship information includes a binding relationship between keys corresponding to the at least two hardware; the verification module uses To obtain the keys corresponding to the at least two pieces of hardware, verify whether the binding relationship included in the binding relationship information is correct based on the keys corresponding to the at least two pieces of hardware; To decrypt the at least two hardware-encrypted ciphertexts respectively, and verify whether the decrypted second verification data is consistent with the first verification data; when the verification result is the binding included in the binding relationship information When the relationship is correct and the decrypted second verification data is consistent with the first verification data, it is determined that the at least two pieces of hardware are in a safe state.
  • the receiving module is configured to receive the ciphertext and notarization certificate returned by the physical carrier ,
  • the notarization certificate includes the binding relationship between the keys corresponding to the at least two hardware, and also includes the digital signature of the binding relationship;
  • the verification module is configured to be based on the notarization certificate
  • the digital signature verifies whether the binding relationship included in the binding relationship information is correct; using the key corresponding to the at least two hardware in the notarization certificate to decrypt the at least two hardware-encrypted ciphertexts, and verify Whether the decrypted second verification data is consistent with the first verification data; when the verification result is that the binding relationship included in the binding relationship information is correct, and the decrypted second verification data is consistent with the first verification data, It is determined that the at least two pieces of hardware are in a safe state.
  • the keys corresponding to the at least two hardware are determined by the at least The two hardwares are generated based on their respective hardware identifications.
  • the hardware identifier includes a hardware unique key HUK, a physical unclonable function PUF, and a confidentiality-protected primary The identification information or endorsement key EK in the programmable OTP.
  • the key includes a symmetric key or an asymmetric secret key. key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key;
  • the ciphertext is obtained after the at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, and the binding relationship information is based on the relationship between the public keys corresponding to the at least two pieces of hardware The binding relationship is obtained.
  • a device for detecting hardware includes: a receiving module for receiving first verification data sent by a verification unit; a first acquiring module for acquiring ciphertext and binding relationship information, so The ciphertext is obtained after at least two of the multiple hardware carried on the physical carrier respectively use their own keys to encrypt the first verification data, and the binding relationship information is used to indicate the at least two A binding relationship between two pieces of hardware; a sending module for sending the ciphertext and binding relationship information to the verification unit, and the verification unit verifies the ciphertext and the binding relationship information , Determining the security of the at least two pieces of hardware based on the verification result.
  • the device further includes: a second obtaining module, configured to obtain keys of the at least two hardware, based on the at least two hardware The binding relationship between the keys of the key to obtain the binding relationship information; the storage module is used to store the binding relationship information.
  • the second acquisition module is configured to register the keys of the at least two hardware to obtain a notarization certificate ,
  • the notarization certificate includes the binding relationship between the keys corresponding to the at least two hardware, and also includes the digital signature of the binding relationship;
  • the storage module is used to store the notarization certificate;
  • the first obtaining module is used to obtain the notarization certificate.
  • the keys corresponding to the at least two hardware are determined by the at least The two hardwares are generated based on their respective hardware identifications.
  • the hardware identifier includes a hardware unique key HUK, a physical unclonable function PUF, and a confidentiality-protected primary The identification information or endorsement key EK in the programmable OTP.
  • the key includes a symmetric key or an asymmetric secret key. key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key;
  • the ciphertext is obtained after the at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, and the binding relationship information is based on the relationship between the public keys corresponding to the at least two pieces of hardware. The binding relationship is obtained.
  • a device for detecting hardware includes a memory and a processor; the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the present application
  • the method in any possible implementation of the first aspect or the second aspect.
  • a communication device which includes a transceiver, a memory, and a processor.
  • the transceiver, the memory, and the processor communicate with each other through an internal connection path
  • the memory is used to store instructions
  • the processor is used to execute the instructions stored in the memory to control the transceiver to receive signals and control the transceiver to send signals
  • the processor executes the instructions stored in the memory, the processor is caused to execute the method in any possible implementation manner of the first aspect or the second aspect.
  • processors there are one or more processors and one or more memories.
  • the memory may be integrated with the processor, or the memory and the processor may be provided separately.
  • the memory can be a non-transitory (non-transitory) memory, such as a read only memory (ROM), which can be integrated with the processor on the same chip, or can be set in different On the chip, the embodiment of the present application does not limit the type of memory and the setting mode of the memory and the processor.
  • ROM read only memory
  • a computer program includes: computer program code, when the computer program code is run by a computer, the computer executes the first aspect or the second aspect. Any one of the possible implementations of the aspect.
  • a readable storage medium stores a program or instruction.
  • the program or instruction runs on a computer, any possible implementation manner of the first aspect or the second aspect is The method in is executed.
  • a chip including a processor, configured to call and execute instructions stored in the memory from the memory, so that the communication device installed with the chip executes the above-mentioned first aspect or second aspect The method in any possible implementation.
  • another chip including: an input interface, an output interface, a processor, and a memory.
  • the input interface, output interface, the processor, and the memory are connected by an internal connection path, and the processing
  • the processor is configured to execute the code in the memory, and when the code is executed, the processor is configured to execute the method in any one of the possible implementation manners of the first aspect or the second aspect.
  • FIG. 1 is a schematic diagram of an implementation environment of detection hardware provided by an embodiment of the application
  • FIG. 2 is a flowchart of a method for detecting hardware provided by an embodiment of the application
  • FIG. 3 is a schematic diagram of a process of establishing a binding relationship provided by an embodiment of the application
  • FIG. 4 is a schematic diagram of a process of detecting hardware provided by an embodiment of the application.
  • FIG. 5 is a schematic diagram of an implementation environment of detection hardware provided by an embodiment of the application.
  • FIG. 6 is a flowchart of a method for detecting hardware provided by an embodiment of the application.
  • FIG. 7 is a schematic diagram of the certificate structure provided by an embodiment of the application.
  • FIG. 8 is a schematic diagram of an implementation environment of detection hardware provided by an embodiment of the application.
  • FIG. 9 is a flowchart of a method for detecting hardware provided by an embodiment of the application.
  • FIG. 10 is a schematic diagram of a process of detecting hardware in a related technology provided by an embodiment of the application.
  • FIG. 11 is a schematic structural diagram of an apparatus for detecting hardware provided by an embodiment of the application.
  • FIG. 12 is a schematic structural diagram of an apparatus for detecting hardware provided by an embodiment of the application.
  • FIG. 13 is a schematic structural diagram of an apparatus for detecting hardware provided by an embodiment of the application.
  • FIG. 14 is a schematic structural diagram of a hardware detection device provided by an embodiment of the application.
  • FIG. 15 is a schematic structural diagram of a device for detecting hardware provided by an embodiment of the application.
  • the embodiments of the present application provide a method for detecting hardware.
  • the method proposes a hardware binding security scheme against hardware counterfeiting and replacement attacks, and is based on cryptographic principles to ensure that the physical carrier is carried
  • the security of the hardware includes, but is not limited to, a single board.
  • the single board includes printed circuit boards (PCB), components and connectors.
  • the single board can complete a certain function of the circuit unit, and the single board can be inserted into the backplane.
  • On the connector There are multiple pieces of hardware carried on a single board.
  • the hardware includes but not limited to a processor, a microcontroller unit (MCU), a trusted platform module (TPM), and a field programmable gate array.
  • the network equipment is a routing device, such as a router or a high-level switch, and a high-level switch is a three- to seven-layer switch, such as a three-tier switch, a four-tier switch, a five-tier switch, a six-tier switch, or a seven-tier switch.
  • Switching equipment includes Ethernet switches or Layer 3 to Layer 7 switches.
  • the physical carrier may also be a PCB with other functions, such as a handheld device motherboard or a computer motherboard or a server motherboard or a PCB contained in other electronic devices.
  • the implementation environment includes a verification unit, a single board, and a certificate authority (CA).
  • the verification unit may be on the same side as the single board, that is, relative to the single board, the verification unit is a local device, and the verification unit implements detection of the hardware on the single board locally.
  • the verification unit may not be on the same side as the single board, but is connected to the single board remotely to realize the detection of the hardware on the single board in a remote manner. This embodiment of the application does not check whether the verification unit is deployed locally. limited.
  • the two pieces of hardware carried on a single board are chip 1 and chip 2.
  • the chip 1 and chip 2 can be chips that process core business functions. Their replacement and counterfeiting will directly affect business security. Threatened.
  • the embodiment of the application adopts methods such as chip generation chip identity key, establishment of the binding relationship between chips based on the chip identity key, and verification of the integrity of the chip based on cryptography, etc., to secure the chip on the board. Detection.
  • the identity key is a key used to represent the identity of different chips, and can also be derived from the root key.
  • the verification unit sends the first verification data to the single board, and chip 1 and chip 2 on the single board respectively generate keys based on their respective hardware identifiers.
  • the key generated by chip 1 is ID1 key (key)
  • the key generated by chip 2 is ID2 key.
  • Chip 1 encrypts the first verification data based on the key generated by chip 1 to obtain ciphertext, such as ciphertext 1.
  • Chip 2 encrypts the first verification data based on the key generated by chip 2 to obtain ciphertext, such as ciphertext 2.
  • the binding relationship between chip 1 and chip 2 is established based on the key generated by chip 1 and chip 2 to obtain binding relationship information.
  • the single board sends ciphertext 1 and ciphertext 2 and the binding relationship information to the verification unit.
  • chip 1 or chip 2 on the single board may send ciphertext 1 and ciphertext 2 and the binding relationship information to
  • the verification unit may also be that after chip 1 and chip 2 encrypt the first verification data to obtain the cipher text, chip 1 and chip 2 respectively send the cipher text 1 and cipher text 2 obtained respectively to the single board except for chips 1 and 2
  • the component sends ciphertext 1 and ciphertext 2 and the binding relationship information to the verification unit, or chip 1 sends ciphertext 1 to the verification unit, and chip 2 sends ciphertext 2 to the verification unit , Chip 1 and/or Chip 2 send the binding relationship to the verification unit.
  • the embodiment of this application does not limit the way that the single board sends the ciphertext 1 and ciphertext 2 and the binding relationship information to the verification unit.
  • the verification unit After the verification unit receives the ciphertext 1 and ciphertext 2 and the binding relationship information, the verification unit The unit verifies the correctness of the binding relationship and the correctness of the result of the cryptographic operation, thereby determining the security of the chip 1 and the chip 2.
  • the key generation process of chip 1 and chip 2 may be generated before receiving the first verification data sent by the verification unit, or may be generated after receiving the first verification data sent by the verification unit, which is not the case in this embodiment of the application. It is limited to ensure that it can be generated before the first verification data is encrypted.
  • chip 1 and chip 2 encrypt the first data, and establish the binding relationship between chip 1 and chip 2 based on the key generated by chip 1 and chip 2, and obtain the binding relationship information.
  • the embodiments of the application are also not limited.
  • the binding relationship may be implemented in the form of a certificate.
  • the CA is a certification authority.
  • the single board applies for key registration from the CA, and the CA determines the binding relationship to generate a notarized certificate.
  • the notarization certificate includes the binding relationship between the keys of chip 1 and chip 2, such as the binding relationship between ID1 key and ID2 key.
  • the notarization certificate also includes the digital signature obtained after the CA signs the binding relationship. Among them, the digital signature in the notarization certificate is obtained by the CA using the CA's private key to sign the binding relationship.
  • the CA returns the notarization certificate to the board, and the board stores it.
  • the single board can be stored on chip 1, or on chip 2, or in other storage areas of the single board except chip 1 and chip 2. After that, after the single board receives the first verification data sent by the verification unit, the single board then obtains the stored notarization certificate to send the notarization certificate and the cipher text to the verification unit.
  • the method for detecting hardware includes the following steps:
  • Step 201 The verification unit sends the first verification data to the physical carrier, and the physical carrier carries multiple pieces of hardware.
  • the first verification data sent by the verification unit to the physical carrier is used for subsequent verification, and the embodiment of the present application does not limit the content of the first verification data.
  • the verification unit may initiate a challenge to the physical carrier based on the challenge-response mechanism, such as sending a random number (Nonce) to the physical carrier, and the random number is the first verification data.
  • the random number is the first verification data.
  • other data determined by the communication protocol can also be sent, and one or more of the random number and other data determined by the communication protocol can be used as the first verification data.
  • other data determined by the communication protocol includes data determined by the quote (Quote) protocol of the Trusted Computing Group (TCG), or data determined by the simple network management protocol (SNMP), Or data determined by the network configuration protocol (NETCONF).
  • the first verification data can be directly sent to one of the hardware on the physical carrier, for example, to the hardware that needs to be detected. It can also be received by the data interface on the physical carrier, and then transmitted to the hardware of the physical carrier (such as hardware to be detected).
  • Step 202 The physical carrier receives the first verification data sent by the verification unit.
  • the physical carrier receives the first verification data sent by the verification unit, which may be received by one of multiple hardware carried on the physical carrier, or may be received through a data interface on the physical carrier.
  • the first verification data arrives on the physical carrier, in order to enable each hardware that needs to perform hardware testing to encrypt the first verification data for subsequent testing procedures, the first verification data needs to be transmitted to each hardware that needs to be tested on.
  • Step 203 The physical carrier obtains the ciphertext and binding relationship information.
  • the method of obtaining the ciphertext may be obtained by encrypting the first verification data by the detected hardware using the key of the detected hardware.
  • the detected hardware may be at least two of the multiple hardware carried on the physical carrier, namely, the encrypted
  • the text is obtained after at least two of the multiple hardware carried on the physical carrier respectively use their own keys to encrypt the first verification data. If it is necessary to detect all the hardware carried on the physical carrier, each hardware carried on the physical carrier can use its own key to encrypt the first verification data to obtain the ciphertext.
  • the binding relationship information is used to indicate the binding relationship between at least two pieces of hardware, and the physical carrier may obtain the binding relationship information by establishing a binding relationship between the at least two pieces of hardware to obtain the binding relationship information.
  • the physical carrier binds the keys of the at least two hardware, and uses the binding relationship between the keys as the binding relationship between the hardware. If it is necessary to detect all the hardware carried on the physical carrier, the binding relationship between each hardware can be established. That is to say, whether it is to obtain the ciphertext or the binding relationship information, at least two of the multiple hardware carried on the physical carrier involved can be all the hardware carried on the physical carrier, or it can be carried on the physical carrier. Part of the hardware.
  • all hardware to be detected can be bound by using a binding relationship, for example, a binding relationship includes the keys of all hardware to be detected.
  • a binding relationship includes the keys of all hardware to be detected.
  • it can also be bound through multiple binding relationships, for example, a binding relationship is established between every two pieces of hardware, or a binding relationship is established between every three pieces of hardware. Definite relationship.
  • the embodiment of the present application does not limit the number of hardware that establishes a binding relationship, nor does it limit the number of established binding relationships, and it is sufficient to ensure that each hardware that needs to be detected can be verified through the binding relationship. And in the case of multiple binding relationships, each binding relationship can be verified by the following verification method.
  • the verification unit can obtain the ciphertext of the hardware 1, and the ciphertext generated by one or more hardwares that have a binding relationship with the hardware 1, and the binding relationship to detect whether the hardware 1 is Correct and credible.
  • the manner in which one or more pieces of hardware having a binding relationship with the hardware 1 generate ciphertext is similar to the manner described in the embodiment, and will not be repeated.
  • the embodiment of the present application does not limit it.
  • a root key is injected into the hardware during the manufacturing process, and the identity key can be derived based on the root key, and the first verification data can be encrypted by the identity key.
  • the hardware ID is the hardware The inherent properties of, are unique, cannot be copied, and are protected by hardware.
  • hardware ID is currently limited to the protection of the supply chain and has not been widely used in security technical solutions.
  • the key corresponding to the hardware is generated by at least two hardware based on their respective hardware identifications.
  • the identity key is based on the root key, and the security of the root key depends heavily on the security of the hardware production environment , Security of key injection method. Therefore, the method of using hardware ID to generate the key has stronger security than the general key generation method.
  • the hardware ID includes, but is not limited to, a hardware unique key (HUK), a physical unclonable function (PUF), and a confidentiality-protected one-time progra mable (OTP) ) In the identification information or endorsement key (EK).
  • the identification information in HUK, PUF, OTP, or EK as hardware identification has the characteristics of unique, random, non-tamperable, secure access, etc. Therefore, generating keys based on these hardware identifications can provide security for the security of the keys .
  • Which hardware identification is used to generate the key can be determined based on hardware.
  • the generated key can be a symmetric key or an asymmetric key. If it is a symmetric key, the first verification data is encrypted and the symmetric key is used when establishing the binding relationship.
  • the key when the key is an asymmetric key, the key includes a public key and a private key; the ciphertext is obtained after at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, The binding relationship information is obtained based on the binding relationship between the public keys corresponding to at least two pieces of hardware.
  • the binding relationship information may be that after receiving the first verification data, the binding relationship between the hardware is established to obtain the binding relationship information. It may also be that before the first verification data is received, the binding relationship is established and the binding relationship information is stored. Before acquiring the binding relationship information, the method further includes: acquiring the keys of at least two hardware, acquiring the binding relationship information based on the binding relationship between the keys of the at least two hardware, and storing the binding relationship information. After receiving the first verification data, the stored binding relationship information is acquired.
  • the physical carrier obtains the binding relationship information based on the binding relationship between the keys of at least two hardware, and stores the binding relationship information, including: the physical carrier registers the at least two hardware keys with the CA, and the CA determines the need After the binding relationship is established, the binding relationship is established, the binding relationship is signed, and the notarization certificate is obtained.
  • the hardware on the physical carrier may also send their respective keys to the CA for registration. For example, each detected hardware sends its own key and the identification of the physical carrier to the CA. The CA binds the key of the hardware on the same physical carrier according to the identification of the physical carrier sent by each hardware.
  • the digital signature in the notarization certificate is obtained by the CA using the CA's private key to sign the binding relationship.
  • the CA After the CA obtains the notarization certificate, it sends the notarization certificate to the physical carrier, and the physical carrier stores the notarization certificate.
  • the notarization certificate includes the binding relationship between the keys corresponding to at least two hardware, and also includes signing the binding relationship The digital signature obtained later.
  • the physical carrier obtains the binding relationship information, including: obtaining a notarization certificate.
  • the binding relationship between the hardware is established through the key, so the binding relationship is protected by cryptographic methods.
  • the binding relationship can be expressed in the form of a certificate. Therefore, it has the characteristics of ease of use.
  • the physical carrier or the hardware on the physical carrier can register keys with the CA, that is, register the key ID1Key of chip 1 and the key ID2Key of chip 2.
  • the CA determines the binding relationship between the key of chip 1 and the key of chip 2, it establishes the binding relationship between the key ID1Key of chip 1 and the key ID2Key of chip 2, and then uses the private key of CA to establish the binding Sign the relationship and get a notarized certificate.
  • the notarization certificate includes the key of the hardware that establishes the binding relationship, and the notarization certificate also includes the digital signature obtained by signing the binding relationship.
  • the binding relationship between the hardware included in the notarization certificate is the binding relationship between the symmetric keys of each hardware.
  • the binding relationship between the hardware contained in the notarization certificate can be the public key in the asymmetric key of the hardware, and the private key of the hardware is stored in the secure environment of the hardware .
  • the security environment includes, but is not limited to, a trusted execution environment (TEE), that is, a safe operating environment for code, or a safe production environment.
  • TEE trusted execution environment
  • Step 204 The physical carrier sends the ciphertext and binding relationship information to the verification unit.
  • the physical carrier After obtaining the ciphertext and binding relationship information, the physical carrier sends the ciphertext and binding relationship information to the verification unit.
  • the physical carrier sends the ciphertext and binding relationship information to the verification unit, it can be sent by any of the detected hardware on the physical carrier. In this way, each detected hardware on the physical carrier gets the ciphertext After that, the ciphertext is sent to the any hardware, and the any hardware sends the ciphertext and the binding relationship information to the verification unit.
  • the ciphertext and binding relationship information can also be sent by other components on the physical carrier except the detected hardware.
  • each detected hardware on the physical carrier obtains the ciphertext
  • the ciphertext is sent to the other component, and the other component sends the ciphertext and the binding relationship information to the verification unit.
  • the number of ciphertexts is consistent with the number of detected hardware , Then each ciphertext can be connected and added to the data format to send.
  • Table 1 the format of the cipher text is shown in Table 1 below.
  • Ciphertext 1 Ciphertext 2
  • the physical carrier may also send other data to the verification unit, and may also return the first verification data sent by the verification unit.
  • the first verification data as a random number Nonce as an example, the format of the cipher text is shown in Table 2 below.
  • DATA may be other data, and the embodiment of the present application does not limit the content of other data.
  • Ciphertext 1 Ciphertext 2
  • Step 205 The verification unit receives the ciphertext and binding relationship information returned by the physical carrier.
  • the verification unit receives the ciphertext and binding relationship information returned by the physical carrier. If the binding relationship information is sent in the form of a notarization certificate, the verification unit receives the ciphertext and binding relationship information returned by the physical carrier, including: receiving the physical carrier
  • the returned ciphertext and notarization certificate, the notarization certificate includes the binding relationship between the keys corresponding to at least two hardware, and also includes the digital signature of the binding relationship.
  • Step 206 The verification unit verifies the ciphertext and the binding relationship information, and determines the security of at least two pieces of hardware based on the verification result.
  • the binding relationship information includes the binding relationship between the keys corresponding to at least two pieces of hardware; the verification unit verifies the ciphertext and the binding relationship information, including: obtaining the keys corresponding to the at least two pieces of hardware , Verifying whether the binding relationship included in the binding relationship information is correct based on the keys corresponding to the at least two pieces of hardware; using the keys corresponding to the at least two pieces of hardware to decrypt the at least two hardware-encrypted ciphertexts respectively, and verify the decryption to obtain Whether the second verification data of is consistent with the first verification data.
  • the manner in which the verification unit obtains the keys corresponding to the at least two hardware may be that after the physical carrier establishes the binding relationship information, the key of each hardware is sent to the verification unit for storage by the verification unit.
  • the key of each hardware is sent to the verification unit, which can be sent by the components on the physical carrier uniformly, or it can be sent independently by each hardware.
  • This application is not correct for sending the key of each hardware to the verification unit. Way to limit. Taking the physical carrier uniformly sending the key of each hardware to the verification unit as an example, since the verification unit may need to detect the hardware on multiple physical carriers, the verification unit can receive the keys sent by multiple physical carriers.
  • the verification unit When the verification unit stores the keys, it can store each key corresponding to the physical carrier identifier, so as to distinguish the keys of the hardware on different physical carriers through the physical carrier identifier. When subsequently detecting the hardware on the physical carrier, the verification unit then obtains the keys of the at least two hardware carried by the physical carrier from the stored keys.
  • the verification unit stores the keys, it can store each key corresponding to the physical carrier identifier, so as to distinguish the keys of the hardware on different physical carriers through the physical carrier identifier.
  • the verification unit When subsequently detecting the hardware on the physical carrier, the verification unit then obtains the keys of the at least two hardware carried by the physical carrier from the stored keys.
  • other corresponding storage methods can also be used, which is not limited in the embodiment of the present application.
  • the verification unit verifies whether the binding relationship included in the binding relationship information is correct based on the keys corresponding to the at least two hardware. For example, verify whether the two keys in the binding relationship are the same as the previously stored key in the verification unit. If the key in the binding relationship is the same as the previously stored key, the binding relationship is correct. If the key of is different from the previously stored key, the binding relationship is incorrect.
  • the verification unit uses the feedback from the certification authority The key is to verify the digital signature in the notarization certificate based on the key fed back by the certification authority.
  • the binding relationship is correct; if the verification fails, the binding relationship is incorrect.
  • the digital signature in the notarization certificate is obtained by the certification authority using the private key of the certification authority to sign the binding relationship, and the verification unit can verify the digital signature in the notarization certificate based on the public key of the certification authority.
  • the keys corresponding to the at least two hardware are then used to decrypt the ciphertexts encrypted by the at least two hardwares respectively to verify whether the second verification data obtained by the decryption is consistent with the first verification data.
  • the security of at least two pieces of hardware is determined based on the verification result, including: when the verification result is that the binding relationship included in the binding relationship information is correct, and the second verification data obtained by decryption is consistent with the first verification data, determining at least two The hardware is in a safe state.
  • the verification result is that the binding relationship included in the binding relationship information is incorrect, or the second verification data obtained by decryption is inconsistent with the first verification data, it can be determined that the hardware on the physical carrier is in a non-secure state. There are potential safety hazards, and corresponding exception handling can be taken.
  • the above is to first obtain the keys corresponding to at least two hardware, and verify whether the binding relationship included in the binding relationship information is correct based on the keys corresponding to the at least two hardware;
  • the corresponding key decrypts at least two hardware-encrypted ciphertexts respectively, and verifies whether the second verification data obtained by the decryption is consistent with the first verification data.
  • it is also possible to obtain the keys corresponding to at least two pieces of hardware use the keys corresponding to the at least two pieces of hardware to decrypt the at least two pieces of hardware-encrypted ciphertexts respectively, and verify the decrypted second Whether the verification data is consistent with the first verification data.
  • the embodiment of the present application does not limit the sequence of the verification unit to verify the ciphertext and verify the binding relationship information.
  • the verification unit may compare each field in the first verification data with each field in the second verification data one by one, and only Only when all the fields of the second verification data and the first verification data are completely consistent can it be confirmed that the second verification data is consistent with the first verification data. Since this method compares all the fields in the first verification data with the second verification data, the verification result is more accurate and reliable.
  • the target field in the second verification data can be compared with the target field in the first verification data. The target field can be selected randomly or the key field can be used as the target field.
  • the target field in the second verification data matches the target field in the first verification data, it can be confirmed that the second verification data is consistent with the first verification data.
  • This method of comparing the target field does not need to compare all the fields in the second verification data and the first verification data one by one, thereby improving the verification speed.
  • the embodiment of the present application does not limit it.
  • the first verification data may be sent by a physical carrier. That is, after the verification unit sends the first verification data to the physical carrier, when the physical carrier returns the ciphertext and binding relationship information to the verification unit, the first verification data is also returned to the verification unit. After decrypting the ciphertext, the verification unit compares the decrypted second verification data with the first verification data.
  • the physical carrier may not return the first verification data. In this case, the verification unit may record the first verification data sent to the physical carrier before, and then receive the physical carrier.
  • the decrypted second verification data is compared with the recorded first verification data.
  • the embodiment of the present application is not limited, and the content of the first verification data sent to the physical carrier can be determined subsequently for the physical carrier.
  • FIG 3 Taking the physical carrier as a single board and the hardware on the physical carrier as a chip, the process of obtaining binding relationship information is shown in Figure 3 as an example.
  • the chip on the board After the chip on the board generates an identity key based on the chip ID, it submits the binding relationship information to issue a certificate application request.
  • the CA receives the application request sent by the board, and after the CA verifies the validity of the request, it issues the binding relationship information, that is, the notarization certificate. Send the notarization certificate, that is, the binding relationship information to the board.
  • the binding relationship information is stored locally. Later, when it is necessary to perform hardware detection on the chip on the single board, as shown in Figure 4, Figure 4 shows the process of detecting the hardware.
  • the verification unit initiates a challenge to the single board, the chip on the single board generates an identity key, and uses the identity key to encrypt the first verification data sent by the verification unit to obtain a ciphertext.
  • the single board obtains the binding relationship information obtained based on the binding relationship between the chips, such as the notarization certificate obtained in FIG. 3.
  • the single board sends the ciphertext and the binding relationship information to the verification unit, and the verification unit verifies the correctness of the binding relationship information, and uses the corresponding identity key to verify the correctness of the encrypted data, that is, the ciphertext.
  • the hardware carried on the physical carrier is bound, if it is counterfeited or replaced, the binding relationship between the hardware changes, and subsequent verification cannot be passed.
  • the security of the hardware on the board can be determined through the binding relationship and the ciphertext verification method.
  • the authenticity of the hardware on the board is verified through ciphertext, and the integrity of the hardware on the board is verified through the binding relationship.
  • the foregoing method for detecting hardware is described with reference to hardware detection on a single board as an example.
  • the method provided in this embodiment can also perform hardware detection for multiple single boards on the entire device.
  • the hardware detection method on each board can be implemented by the above method. For the entire device, if a board fails the hardware test, for example, if an unauthenticated board is inserted, the device will alarm or deny service.
  • the single board replacement between devices can also achieve alarms, which can further protect the hardware integrity of the entire device.
  • the method provided in the embodiment of the present application may also combine hardware detection results with other technologies.
  • the hardware detection result obtained by the method provided in the embodiment of the present application is combined with the joint test action group (JTAG) authentication technology.
  • JTAG authentication function ensures that the emulator or control unit that fails the authentication cannot obtain the JTAG debugging control right of the chip.
  • JTAG authority can be granted only when the hardware passes the inspection, that is, the JTAG authentication function can be used through JTAG authority.
  • the method provided by the embodiments of the present application verifies the security of the hardware based on the binding relationship between the hardware carried on the physical carrier and the ciphertext encrypted by the hardware with its own key, which can prevent the hardware from being replaced. And attacks such as being counterfeited.
  • the hardware's key is used to verify the authenticity of the hardware through cryptographic methods (such as digital signatures, asymmetric encryption and decryption).
  • the verification process can be based on a challenge-response mechanism.
  • Each piece of hardware uses a private key to respond to the challenge; the verification unit verifies the correctness of the response through the public key of each piece of hardware and determines whether the hardware has been tampered with.
  • the verification process may be compatible with the Trusted Computing Group (TCG) or Internet Engineering Task Group (Internet Engineering Task Framework, IETF)-RATS verification specifications.
  • the method for detecting hardware provided in the embodiments of the present application can be applied to a variety of scenarios, and is suitable for detecting multiple types of hardware. Next, based on the above-mentioned hardware detection method, examples are given for different application scenarios.
  • Scenario 1 Protect the hardware root of trust scenario
  • the hardware root of trust is the basis for the secure boot and trusted boot of a single board, it is particularly important to protect the integrity of the hardware root of trust.
  • the hardware root of trust of a single board usually consists of a processor and a TPM security chip. Among them, the processor serves as the trusted measurement root, and the TPM chip serves as the trusted report root and the trusted storage root.
  • the hardware detection is performed on the processor and TPM chip on a single board.
  • the processor as a system chip (system on a chip, SoC) as an example
  • the implementation environment of the hardware detection method is shown in Figure 5.
  • the method for detecting hardware provided by the embodiments of the present application may be as shown in FIG. 6, using a physical carrier as a single board and a verification unit as a remote authentication (remote attestation, RA) server as an example.
  • the hardware method includes the following steps.
  • Step 601 The RA server sends a random number to the single board, and the single board carries the SoC and TPM.
  • the random number sent by the RA server to the single board is used for subsequent verification, and the embodiment of the present application does not limit the content of the random number.
  • the RA server may initiate a challenge to the single board based on the challenge-response mechanism to send a random number (Nonce) to the single board.
  • a random number (Nonce)
  • other data determined by the communication protocol can also be sent, and random numbers and other data determined by the communication protocol can all be used as random numbers.
  • the RA server in addition to sending a random number to the single board, may also send the value of a port command register (port command register, PCR).
  • the random number can be sent to the SoC on the single board, and then sent to the TPM inside the single board. It can also be received by the data interface on the board, and then transmitted to the SoC and TPM.
  • Step 602 The board receives the random number sent by the RA server.
  • the single board After the single board receives the random number sent by the RA server, in order to enable the SoC and TPM that require hardware detection to be encrypted based on the random number for subsequent detection procedures, the random number needs to be transmitted to the SoC and TPM.
  • Step 603 The board obtains the ciphertext and binding relationship information.
  • the ciphertext is obtained after the SoC and TPM carried on the board use their respective keys to encrypt the random numbers. If the RA server sends the value of the PCR register in addition to the random number, the ciphertext is obtained after the SoC and TPM carried on the board use their own keys to encrypt the value of the random number and the PCR register.
  • the key corresponding to the hardware is generated by the hardware based on the respective hardware identification.
  • TEE such as the trusted zone of advanced instruction set computing machines (ARM) processors, the software protection extension of Intel processors (software guard extensions, SGX).
  • TEE has high security features and can guarantee the confidentiality and integrity of asymmetric keys, especially private keys. Therefore, as shown in Figure 5, SoC can be based on the TEE trusted execution environment, such as reading HUK information in the trusted zone and generating an identity key pair, that is, SoC uses HUK to generate asymmetric keys, including public and private keys. Store the private key securely in the TEE.
  • the key generated by the SoC in Figure 5 is ID key.
  • the attestation identity key (AIK) is generated by the EK as the identity key of the TPM chip.
  • the security attributes of the TPM chip itself can provide a higher security protection environment for the storage and access of keys.
  • the binding relationship information is used to indicate the binding relationship between the SoC and the TPM.
  • binding relationship information may be obtained based on the binding relationship between the keys of the SoC and the TPM, and the binding relationship information may be stored.
  • the board applies for an AIK certificate from the CA.
  • the single board registers the public key of the SoC and TPM, and the CA issues an AIK certificate to the single board.
  • the board stores the AIK certificate in the TPM.
  • the AIK certificate includes the binding relationship between the SoC public key and the TPM AIK public key, and also includes a digital signature, which is the binding relationship between the CA and the CA's private key Get it by signing.
  • the AIK certificate structure is shown in Figure 7.
  • the AIK certificate includes a basic domain and an extended domain.
  • the basic domain includes version (version), serial number (serial no.), issuer signature algorithm (issuer signature algorithm), public key information (subject public key information), issuer signature (issuer's signature), among which, the public key
  • the AIK public key is stored in the information, and the issuer's signature is the digital signature obtained by the CA signing the binding relationship.
  • the extended domain includes the user's alternative name (subject alternative name) and key usage (Key Usage), where the subject alternative name stores the public key information of the HUK derived key.
  • the AIK certificate can be in the X509.v3 format or in a custom format.
  • the embodiment of the present application does not limit this, and the standard X509.v3 version is taken as an example in FIG. 7. Since the AIK certificate is endorsed by the CA, the method provided in this embodiment of the application borrows the binding relationship between the AIK certificate expression processor and the TPM chip in the TCG.
  • the single board obtains the binding relationship information, including: obtaining a notarization certificate.
  • a single board can register a key with the CA to obtain a notarization certificate.
  • the notarization certificate includes the key of the hardware that establishes the binding relationship and the digital signature of the binding relationship.
  • the binding relationship contained in the AIK certificate may be the binding relationship between the ID key and the AIK. That is, the binding relationship of the hardware trusted root is established by the AIK certificate.
  • the digital signature of the binding relationship may be obtained by the CA using the CA's private key to sign the binding relationship.
  • Step 604 The single board sends the ciphertext and binding relationship information to the RA server.
  • the single board After obtaining the ciphertext and binding relationship information, the single board sends the ciphertext and binding relationship information to the RA server.
  • the number of ciphertexts is two.
  • SoC signature and TPM can be connected and added to the data format to be sent in sequence.
  • the data format is shown in Table 3 below.
  • the single board can also send other data to the RA server, or it can also return the random number sent by the RA server.
  • the RA server sends the value of the PCR register in addition to the random number to the board
  • the board can not only send the SoC signature and AIK signature to the RA server, but also the random number and the value of the PCR register. Send to the RA server.
  • the data format is shown in Table 4 below.
  • Step 605 The RA server receives the ciphertext and binding relationship information returned by the board.
  • the RA server receives the ciphertext and binding relationship information returned by the board. As shown in Figure 5, the binding relationship information is sent in the form of a notarized certificate, and the RA server receives the ciphertext and AIK certificate returned by the board. Including the binding relationship between the keys corresponding to the SoC and the TPM.
  • step 606 the RA server verifies the ciphertext and the binding relationship information, and determines the security of the SOC and TPM based on the verification result.
  • the binding relationship information includes the binding relationship between the keys corresponding to at least two pieces of hardware; the RA server verifies the ciphertext and the binding relationship information, including: obtaining the public keys corresponding to the SoC and the TPM, Verify whether the binding relationship included in the binding relationship information is correct based on the public key corresponding to the SoC and TPM; use the public key corresponding to the SoC and TPM to decrypt the encrypted ciphertext of the SoC and TPM respectively, and verify that the decrypted data and random Whether the numbers are consistent.
  • the RA server obtains the public key corresponding to the SoC and the TPM by sending the public key of the SoC and TPM to the RA server after the binding relationship information is established by the single board, and the RA server stores it. Since the RA server may need to detect the hardware on multiple boards, the RA server can receive keys sent by multiple boards. When the RA server stores the keys, it can store each key corresponding to the board ID to distinguish the keys of the hardware on different boards through the board ID. When subsequently detecting the hardware on the single board, the RA server obtains the keys of the at least two hardware carried by the single board from the stored keys.
  • the RA server After obtaining the previously stored public keys of the SoC and TPM, the RA server verifies whether the binding relationship included in the binding relationship information is correct based on the public key corresponding to the SoC and TPM.
  • the notarization certificate includes the binding relationship and the digital signature obtained after signing the binding relationship.
  • the digital signature is the private key pair of the certificate authority using the certificate authority.
  • the binding relationship is obtained by signing, and the RA server verifies whether the binding relationship included in the binding relationship information is correct based on the digital signature in the notarization certificate.
  • the RA server uses the public key of the certification authority to verify the digital signature in the notarization certificate.
  • the binding relationship is correct, and if the verification fails, the binding relationship is incorrect.
  • the keys corresponding to the SoC and TPM are used to decrypt the ciphertexts encrypted by the SoC and TPM respectively to verify whether the decrypted data is consistent with the random number.
  • the safety of SoC and TPM is determined based on the verification result. For example, when the verification result is that the binding relationship included in the binding relationship information is correct, and the decrypted data is consistent with the random number, it is determined that the SoC and TPM are in a safe state, indicating that the SoC and TPM are real, and there is no counterfeiting or replacement. Wait for the attack.
  • the method provided in the embodiments of the present application is based on the binding relationship between the SoC and TPM carried on the board, and the ciphertext encrypted by the SoC and TPM using their respective keys to verify the security of the SoC and TPM It can prevent SoC and TPM from being replaced and counterfeited.
  • the RA server is used as the verification unit, and the encryption and decryption operation of Nonce (random number) may adopt the trusted verification process in TCG.
  • Nonce random number
  • Scenario 2 The scenario of protecting the data processing unit
  • processors and FPGA are the more important data processing units in the single board, under normal circumstances, the processor tends to implement control, storage and data processing functions; for scenarios with higher requirements for data stream processing performance, FPGAs are used to implement hardware Acceleration function.
  • FPGAs are usually responsible for hardware acceleration of cryptographic operations; processors are mainly used for management and inter-board data communication functions. If the processor and FPGA contain hardware Trojan (Trojan), spyware (Spyware), it will directly lead to system security risks. Therefore, it is particularly important to ensure the integrity and authenticity of the FPGA and processor hardware in the single board.
  • the implementation environment of the hardware detection method is shown in Figure 8. With reference to the implementation environment shown in FIG. 8, the method for detecting hardware provided by the embodiment of the present application may be as shown in FIG. 9, including the following steps.
  • Step 901 The verification unit sends a random number to the single board, and the single board carries the SoC and FPGA.
  • the random number sent by the verification unit to the single board is used for subsequent verification, and the embodiment of the present application does not limit the content of the random number.
  • the verification unit may initiate a challenge to the single board based on the challenge-response mechanism to send a random number (Nonce) to the single board.
  • a random number (Nonce)
  • other data determined by the communication protocol can also be sent, and random numbers and other data determined by the communication protocol can all be used as random numbers.
  • the random number can be sent to the SoC on the single board, and then sent to the FPGA inside the single board. It can also be received by the data interface on the board, and then transmitted to the SoC and FPGA.
  • Step 902 The single board receives the random number sent by the verification unit.
  • the single board After the single board receives the random number sent by the verification unit, in order to enable the SoC and FPGA that require hardware detection to be encrypted based on the random number for subsequent detection procedures, the random number needs to be transmitted to the SoC and FPGA.
  • Step 903 the single board obtains the ciphertext and binding relationship information.
  • the ciphertext is obtained after the SoC and FPGA carried on the board use their respective keys to encrypt the random numbers.
  • the key corresponding to the hardware is generated by the hardware based on the respective hardware identification.
  • TEE has high security features and can guarantee the confidentiality and integrity of asymmetric keys, especially private keys. Therefore, as shown in Figure 5, SoC can read HUK information and generate an identity key pair based on the TEE trusted execution environment, that is, SoC uses HUK to generate asymmetric keys, including public and private keys, and store the private keys securely In TEE.
  • the key generated by the SoC in Figure 8 is ID1 key.
  • an asymmetric key is generated according to the PUF as the identity key of the FPGA chip.
  • the key generated by the FPGA is ID2Key.
  • the FPGA chip provides a higher security protection environment for key storage and access.
  • the binding relationship information is used to indicate the binding relationship between the SoC and FPGA.
  • the binding relationship information may be obtained based on the binding relationship between the keys of the SoC and the FPGA, and the binding relationship information may be stored. For example, register the public key of SoC and FPGA, get a notarization certificate, store the notarization certificate, the notarization certificate includes the binding relationship between the public key corresponding to the SoC and FPGA, and also includes the digital signature of the binding relationship; in this case
  • To obtain binding relationship information including: obtaining a notarization certificate.
  • the single board can register the key with the CA, and the CA sends the notarized certificate to the single board.
  • the notarized certificate contains the key of the hardware that establishes the binding relationship and the digital signature of the binding relationship.
  • the digital signature may be obtained by the CA using the CA's private key to sign the binding relationship.
  • the binding relationship contained in the notarization certificate may be the binding relationship between ID1 key and ID2 key.
  • Step 904 The single board sends the ciphertext and the binding relationship information to the verification unit.
  • the single board After obtaining the ciphertext and binding relationship information, the single board sends the ciphertext and binding relationship information to the verification unit.
  • the SoC and FPGA respectively encrypt the random numbers to obtain the ciphertext, and the number of ciphertexts is two, each ciphertext can be connected and added to the data format to be sent in turn.
  • the single board may also send other data to the verification unit, and may also return the random number sent by the verification unit. In the implementation environment shown in Figure 8, the single board sends the ciphertext and the certificate to the verification unit.
  • Step 905 The verification unit receives the ciphertext and binding relationship information returned by the board.
  • the verification unit receives the ciphertext and binding relationship information returned by the board. As shown in Figure 8, the binding relationship information is sent in the form of a notarized certificate, and the verification unit receives the ciphertext and AIK certificate returned by the board. Including the binding relationship between the keys corresponding to the SoC and FPGA, and the digital signature of the binding relationship.
  • Step 906 the verification unit verifies the ciphertext and the binding relationship information, and determines the security of the SOC and FPGA based on the verification result.
  • the binding relationship information includes the binding relationship between the keys corresponding to at least two hardware; the verification unit verifies the ciphertext and the binding relationship information, including: obtaining the public key corresponding to the SoC and the FPGA, Based on the public key corresponding to the SoC and FPGA, verify whether the binding relationship information includes the correct binding relationship; use the public key corresponding to the SoC and FPGA to decrypt the encrypted ciphertext of the SoC and FPGA respectively, and verify that the decrypted data is random Whether the numbers are consistent.
  • the method for the verification unit to obtain the public key corresponding to the SoC and FPGA may be that after the single board establishes the binding relationship information, the public key of the SoC and FPGA is sent to the verification unit for storage by the verification unit. Since the verification unit may need to detect the hardware on multiple boards, the verification unit may receive the keys sent by the multiple boards. When the verification unit stores the keys, it can store each key corresponding to the single board identification, so as to distinguish the keys of hardware on different single boards through the single board identification. When subsequently detecting the hardware on the single board, the verification unit obtains the keys of the at least two hardware carried by the single board from the stored keys.
  • the verification unit verifies whether the binding relationship included in the binding relationship information is correct based on the public key corresponding to the SoC and FPGA. If the binding relationship is correct, use the keys corresponding to the SoC and FPGA to decrypt the encrypted ciphertexts of the SoC and FPGA respectively, and verify whether the decrypted data is consistent with the random number. The safety of SoC and FPGA is determined based on the verification result.
  • the notarization certificate includes the binding relationship and the digital signature obtained after signing the binding relationship. The digital signature is the private key pair of the certificate authority using the certificate authority.
  • the binding relationship is obtained by signing, and the verification unit verifies whether the binding relationship included in the binding relationship information is correct based on the digital signature in the notarization certificate.
  • the verification unit uses the public key of the certification authority to verify the digital signature in the notarization certificate. If the verification succeeds, the binding relationship is correct, and if the verification fails, the binding relationship is incorrect.
  • the verification result is that the binding relationship included in the binding relationship information is correct, and the decrypted data is consistent with the random number
  • the verification result is that the binding relationship included in the binding relationship information is incorrect, or the decrypted data is consistent with the random number
  • corresponding exception handling can be taken.
  • the verification unit issues an alarm, or the verification unit sends a prompt message to the display device to remind the hardware on the single board that there is a potential safety hazard.
  • other methods may also be adopted, which are not limited in the embodiment of the present application.
  • the method provided by the embodiments of the present application is based on the binding relationship between the SoC and FPGA carried on a single board, and the ciphertext encrypted by the SoC and FPGA using their respective keys to verify the security of the SoC and FPGA It can prevent SoC and FPGA from being replaced and counterfeited.
  • a method of detecting hardware based on hardware identification For example, as shown in Figure 10, after the device is powered on, it first executes a secure startup business process to ensure the integrity of the startup software; then, a trusted software operating system (OS) verifies the authenticity of the hardware TPM. The OS verifies the unique identification ID of the TPM security chip and confirms the certificate legally held by the TPM security chip. In this way, the authenticity of the TPM security module is confirmed. That is to say, in the related technology, the integrity of the software is guaranteed by the safe boot, and the authenticity of the hardware is guaranteed by the trusted software.
  • OS trusted software operating system
  • the solution provided by related technologies only guarantees the authenticity of the TPM and does not have the binding relationship between the hardware. There is no attack scenario in which other hardware is replaced in a single board. Defensive capabilities, and the same does not have defensive capabilities against other attack scenarios where hardware is counterfeited.
  • the method provided by the embodiment of the application obtains the ciphertext by encrypting the key, and realizes the protection of the integrity of the hardware in the single board based on the verification of the ciphertext, effectively preventing the hardware in the single board from being counterfeited or replaced;
  • the binding between the hardware further prevents the hardware from being counterfeited and replaced.
  • the binding relationship can be in the form of a certificate, which can be compatible with the standard TCG certification protocol, and can extend the hardware binding relationship in the protocol while complying with the TCG standard certification requirements. Strong practicality.
  • the key can be generated by using a hardware ID, which fully utilizes the hardware's hardware ID, secure storage and other security features, thereby improving security. Therefore, the method provided in the embodiment of the present application has the ability to reliably guarantee the hardware authenticity of the single board as a product during shipment and live network operation.
  • an embodiment of the present application provides a device for detecting hardware, which can perform the verification process performed by the verification unit described above, and the device includes:
  • the sending module 1101 is configured to send the first verification data to the physical carrier, and the physical carrier carries multiple pieces of hardware;
  • the receiving module 1102 is used to receive the ciphertext and binding relationship information returned by the physical carrier.
  • the ciphertext is obtained after at least two pieces of hardware in the plurality of hardware respectively use their own keys to encrypt the first verification data, and the binding
  • the relationship information is used to indicate the binding relationship between at least two pieces of hardware;
  • the verification module 1103 is used to verify the ciphertext and the binding relationship information, and is used to determine the security of at least two pieces of hardware based on the verification result.
  • the binding relationship information includes a binding relationship between keys corresponding to at least two pieces of hardware
  • the verification module 1103 is configured to obtain keys corresponding to at least two hardware, and verify whether the binding relationship included in the binding relationship information is correct based on the keys corresponding to the at least two hardware; using keys corresponding to the at least two hardware Decrypt at least two hardware-encrypted ciphertexts respectively, and verify whether the second verification data obtained by decryption is consistent with the first verification data;
  • the verification result is that the binding relationship included in the binding relationship information is correct, and the second verification data obtained by decryption is consistent with the first verification data, it is determined that at least two pieces of hardware are in a safe state.
  • the receiving module 1102 is configured to receive the ciphertext and the notarization certificate returned by the physical carrier.
  • the notarization certificate includes the binding relationship between the keys corresponding to at least two hardware, and also includes the binding relationship Digital signature;
  • the verification module 1103 is configured to verify whether the binding relationship included in the binding relationship information is correct based on the digital signature in the notarization certificate; use the keys corresponding to the at least two hardware in the notarization certificate to perform the encryption on the at least two hardware encrypted cipher texts respectively Decryption, to verify whether the second verification data obtained by decryption is consistent with the first verification data;
  • the verification result is that the binding relationship included in the binding relationship information is correct, and the second verification data obtained by decryption is consistent with the first verification data, it is determined that at least two pieces of hardware are in a safe state.
  • the keys corresponding to the at least two pieces of hardware are respectively generated by the at least two pieces of hardware based on their hardware identifiers.
  • the hardware identification includes identification information in HUK, PUF, OTP whose confidentiality is protected, or EK.
  • the key includes a symmetric key or an asymmetric key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key;
  • the ciphertext is obtained after at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, and the binding relationship information is obtained based on the binding relationship between the public keys corresponding to the at least two pieces of hardware.
  • an embodiment of the present application provides a device for detecting hardware, which can perform the functions of the above-mentioned physical carrier, and the device includes:
  • the receiving module 1201 is configured to receive the first verification data sent by the verification unit;
  • the first obtaining module 1202 is used to obtain the ciphertext and binding relationship information.
  • the ciphertext is obtained after at least two of the multiple hardware carried on the physical carrier respectively use their respective keys to encrypt the first verification data ,
  • the binding relationship information is used to indicate the binding relationship between at least two pieces of hardware;
  • the sending module 1203 is configured to send the ciphertext and the binding relationship information to the verification unit, and the verification unit verifies the ciphertext and the binding relationship information, and determines the security of at least two pieces of hardware based on the verification result.
  • the device further includes:
  • the second obtaining module 1204 is configured to obtain keys of at least two hardware, and obtain binding relationship information based on the binding relationship between the keys of the at least two hardware;
  • the storage module 1205 is used to store binding relationship information.
  • the second obtaining module 1204 is configured to register keys of at least two hardware to obtain a notarization certificate, the notarization certificate includes the binding relationship between the keys corresponding to the at least two hardware, and Including the digital signature of the binding relationship;
  • the storage module 1205 is used to store the notarization certificate
  • the first obtaining module 1202 is used to obtain a notarization certificate.
  • the keys corresponding to the at least two pieces of hardware are respectively generated by the at least two pieces of hardware based on their hardware identifiers.
  • the hardware identification includes identification information in HUK, PUF, OTP whose confidentiality is protected, or EK.
  • the key includes a symmetric key or an asymmetric key.
  • the key when the key is an asymmetric key, the key includes a public key and a private key; the ciphertext is obtained after at least two pieces of hardware respectively use their own private keys to encrypt the first verification data, The binding relationship information is obtained based on the binding relationship between the public keys corresponding to at least two pieces of hardware.
  • an embodiment of the present application also provides a device for detecting hardware.
  • the device includes a storage 1401 and a processor 1402; the memory 1401 stores at least one instruction, and at least one instruction is loaded and loaded by the processor 1402. Execute to implement any of the foregoing hardware detection methods provided in the embodiments of the present application.
  • the embodiment of the present application also provides a hardware detection device 1501, the memory 1502, and the processor 1503 communicate with each other through an internal connection path, the memory 1502 is used to store instructions, and the processor 1503 is used to execute instructions stored in the memory.
  • the processor 1503 is made to execute any of the above methods for detecting hardware.
  • An embodiment of the present application also provides a hardware detection system, which includes the hardware detection device shown in FIG. 11 and the hardware detection device shown in FIG. 12 or FIG. 13.
  • An embodiment of the present application also provides a computer-readable storage medium, in which at least one instruction is stored, and the instruction is loaded and executed by a processor to implement any of the foregoing hardware detection methods provided in the embodiment of the present application.
  • the embodiment of the present application also provides a chip including a processor, and the processor is configured to call and execute instructions stored in the memory from the memory, so that the communication device with the chip installed executes any one of the aforementioned hardware detection methods.
  • the embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor, and a memory.
  • the input interface, output interface, the processor and the memory are connected by an internal connection path, and the processor is used to execute the code in the memory.
  • the processor is used to execute any of the above methods for detecting hardware.
  • processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processing (digital signal processing, DSP), and application specific integrated circuits. ASIC), field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or any conventional processor. It is worth noting that the processor may be a processor that supports an advanced reduced instruction set machine (advanced RISC machines, ARM) architecture.
  • the memory may be integrated with the processor, or the memory and the processor may be provided separately.
  • the above-mentioned memory may include a read-only memory and a random access memory, and provides instructions and data to the processor.
  • the memory may also include non-volatile random access memory.
  • the memory can also store device type information.
  • the memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), and electronic Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • the volatile memory may be random access memory (RAM), which is used as an external cache. By way of exemplary but not limiting illustration, many forms of RAM are available.
  • static random access memory static random access memory
  • dynamic random access memory dynamic random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • double data rate synchronous dynamic random access Memory double data date SDRAM, DDR SDRAM
  • enhanced synchronous dynamic random access memory enhanced SDRAM, ESDRAM
  • serial link DRAM SLDRAM
  • direct memory bus random access memory direct rambus RAM
  • This application provides a computer program.
  • the computer program When the computer program is executed by a computer, it can cause a processor or computer to execute the corresponding steps and/or processes in the foregoing method embodiments.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center integrated with one or more available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Power Engineering (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了检测硬件的方法、装置、设备及存储介质。方法包括：向物理载体发送第一验证数据，物理载体上承载有多个硬件；接收物理载体返回的密文和绑定关系信息，密文是多个硬件中的至少两个硬件分别采用各自的密钥对第一验证数据进行加密之后得到的，绑定关系信息用于指示至少两个硬件之间的绑定关系；对密文及绑定关系信息进行验证，基于验证结果确定至少两个硬件的安全性。基于物理载体上承载的硬件之间的绑定关系以及硬件采用各自的密钥加密的密文来验证硬件的安全性，能够防止硬件发生被替换以及被仿冒等攻击行为。

Description

检测硬件的方法、装置、设备及存储介质
本申请要求于2019年07月24日提交中国专利局、申请号为201910673176.6、申请名称为“检测硬件的方法、装置、设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及安全技术领域，特别涉及检测硬件的方法、装置、设备及存储介质。
背景技术
硬件的安全性是密码算法、安全协议等软件安全技术的基础。近年来，针对硬件的攻击行为越来越常见。因此，如何进行硬件检测，以在硬件层面保证设备的安全性，已经成为安全领域的重要课题。
发明内容
本申请实施例提供了一种检测硬件的方法、装置、设备及存储介质，以解决相关技术中的问题，技术方案如下：
第一方面，提供了一种检测硬件的方法，所述方法包括：向物理载体发送第一验证数据，所述物理载体上承载有多个硬件；接收所述物理载体返回的密文和绑定关系信息，所述密文是所述多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；对所述密文及所述绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
通过基于物理载体上承载的硬件之间的绑定关系以及硬件采用各自的密钥加密的密文来验证硬件的安全性，能够防止硬件发生被替换以及被仿冒等攻击行为。
结合第一方面，在第一方面的第一种可能的实施方式中，所述绑定关系信息包括所述至少两个硬件所对应的密钥之间的绑定关系；所述对所述密文及所述绑定关系信息进行验证，包括：获取所述至少两个硬件所对应的密钥，基于所述至少两个硬件所对应的密钥验证所述绑定关系信息包括的绑定关系是否正确；采用所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；所述基于验证结果确定所述至少两个硬件的安全性，包括：当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
结合第一方面或第一方面的第一种可能的实施方式，在第一方面的第二种可能的实施方式中，所述接收所述物理载体返回的密文和绑定关系信息，包括：接收所述物理载体返回的密文和公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；所述对所述密文及所述绑定关系信息进行验证，包括：基于所述公证证书中的数字签名验证所述绑定关系信息包括的绑定关系是否正确；采用所述公证证书中所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别 进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；所述基于验证结果确定所述至少两个硬件的安全性，包括：当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
通过公证证书来验证硬件之间的绑定关系，能够兼容标准的TCG认证协议，且在协议中扩展硬件的绑定关系，从而具备较强的实用性。
结合第一方面、第一方面的第一种或第二种可能的实施方式，在第一方面的第三种可能的实施方式中，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
由于硬件标识是硬件的固有属性，具有唯一性、不可复制，且由硬件提供保护，因而基于硬件各自的硬件标识生成硬件的密钥，在提高了密钥的安全性的基础上，使得硬件的安全性进一步提高。
结合第一方面的第三种可能的实施方式，在第一方面的第四种可能的实施方式中，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
结合第一方面、第一方面的第一种至第四种中任一可能的实施方式，在第一方面的第五种可能的实施方式中，所述密钥包括对称密钥或非对称密钥。
结合第一方面的第五种可能的实施方式，在第一方面的第六种可能的实施方式中，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。通过采用非对称密钥，进一步提高硬件的安全性。
第二方面，提供了一种检测硬件的方法，所述方法包括：接收验证单元发送的第一验证数据；获取密文和绑定关系信息，所述密文是物理载体上承载的多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；将所述密文和绑定关系信息发送至所述验证单元，由所述验证单元对所述密文及所述绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
结合第二方面，在第二方面的第一种可能的实施方式中，获取绑定关系信息之前，还包括：获取所述至少两个硬件的密钥，基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息，存储所述绑定关系信息。
结合第二方面的第一种可能的实施方式，在第一方面的第二种可能的实施方式中，所述基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息，存储所述绑定关系信息，包括：注册所述至少两个硬件的密钥，得到公证证书，存储所述公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；所述获取绑定关系信息，包括：获取所述公证证书。
结合第二方面、第二方面的第一种或第二种可能的实施方式，在第二方面的第三种可能的实施方式中，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬 件标识生成。
结合第二方面的第三种可能的实施方式，在第二方面的第四种可能的实施方式中，所述硬件标识包括HUK、PUF、机密性受保护的OTP中的标识信息或EK。
结合第二方面、第二方面的第一种至第四种中任一可能的实施方式，在第二方面的第五种可能的实施方式中，所述密钥包括对称密钥或非对称密钥。
结合第二方面的第五种可能的实施方式，在第二方面的第六种可能的实施方式中，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
第三方面，提供了一种检测硬件的装置，所述装置包括：发送模块，用于向物理载体发送第一验证数据，所述物理载体上承载有多个硬件；接收模块，用于接收所述物理载体返回的密文和绑定关系信息，所述密文是所述多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；验证模块，用于对所述密文及所述绑定关系信息进行验证，用于基于验证结果确定所述至少两个硬件的安全性。
结合第三方面，在第三方面的第一种可能的实施方式中，所述绑定关系信息包括所述至少两个硬件所对应的密钥之间的绑定关系；所述验证模块，用于获取所述至少两个硬件所对应的密钥，基于所述至少两个硬件所对应的密钥验证所述绑定关系信息包括的绑定关系是否正确；采用所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
结合第三方面或第一方面的第一种可能的实施方式，在第三方面的第二种可能的实施方式中，所述接收模块，用于接收所述物理载体返回的密文和公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；所述验证模块，用于基于所述公证证书中的数字签名验证所述绑定关系信息包括的绑定关系是否正确；采用所述公证证书中所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
结合第三方面、第三方面的第一种或第二种可能的实施方式，在第三方面的第三种可能的实施方式中，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
结合第三方面的第三种可能的实施方式，在第三方面的第四种可能的实施方式中，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
结合第三方面、第三方面的第一种至第四种中任一可能的实施方式，在第三方面的第五种可能的实施方式中，所述密钥包括对称密钥或非对称密钥。
结合第三方面的第五种可能的实施方式，在第三方面的第六种可能的实施方式中，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；
所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
第四方面，提供了一种检测硬件的装置，所述装置包括：接收模块，用于接收验证单元发送的第一验证数据；第一获取模块，用于获取密文和绑定关系信息，所述密文是物理载体上承载的多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；发送模块，用于将所述密文和绑定关系信息发送至所述验证单元，由所述验证单元对所述密文及所述绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
结合第四方面，在第四方面的第一种可能的实施方式中，所述装置还包括：第二获取模块，用于获取所述至少两个硬件的密钥，基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息；存储模块，用于存储所述绑定关系信息。
结合第四方面的第一种可能的实施方式，在第四方面的第二种可能的实施方式中，所述第二获取模块，用于注册所述至少两个硬件的密钥，得到公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；所述存储模块，用于存储所述公证证书；所述第一获取模块，用于获取所述公证证书。
结合第四方面、第四方面的第一种或第二种可能的实施方式，在第四方面的第三种可能的实施方式中，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
结合第四方面的第三种可能的实施方式，在第四方面的第四种可能的实施方式中，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
结合第四方面、第四方面的第一种至第四种中任一可能的实施方式，在第四方面的第五种可能的实施方式中，所述密钥包括对称密钥或非对称密钥。
结合第四方面的第五种可能的实施方式，在第四方面的第六种可能的实施方式中，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
第五方面，提供了一种检测硬件的设备，所述设备包括存储器及处理器；所述存储器中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行，以实现本申请第一方面或第二方面的任一种可能的实施方式中的方法。
第六方面，提供了一种通信装置，该装置包括：收发器、存储器和处理器。其中，该收发器、该存储器和该处理器通过内部连接通路互相通信，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，以控制收发器接收信号，并控制收发器发送信号，并且当该处理器执行该存储器存储的指令时，使得该处理器执行第一方面或第二方面的任一种可能的实施方式中的方法。
可选地，所述处理器为一个或多个，所述存储器为一个或多个。
可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。
在具体实现过程中，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
第七方面，提供了一种计算机程序(产品)，所述计算机程序(产品)包括：计算机程序代码，当所述计算机程序代码被计算机运行时，使得所述计算机执行上述第一方面或第二方面的任一种可能的实施方式中的方法。
第八方面，提供了一种可读存储介质，可读存储介质存储程序或指令，当所述程序或指令在计算机上运行时，上述第一方面或第二方面的任一种可能的实施方式中的方法被执行。
第九方面，提供了一种芯片，包括处理器，处理器用于从存储器中调用并运行所述存储器中存储的指令，使得安装有所述芯片的通信设备执行上述第一方面或第二方面的任一种可能的实施方式中的方法。
第十方面，提供另一种芯片，包括：输入接口、输出接口、处理器和存储器，所述输入接口、输出接口、所述处理器以及所述存储器之间通过内部连接通路相连，所述处理器用于执行所述存储器中的代码，当所述代码被执行时，所述处理器用于执行上述第一方面或第二方面的任一种可能的实施方式中的方法。
附图说明
图1为本申请实施例提供的检测硬件的实施环境示意图；
图2为本申请实施例提供的检测硬件的方法流程图；
图3为本申请实施例提供的建立绑定关系的过程示意图；
图4为本申请实施例提供的检测硬件的过程示意图；
图5为本申请实施例提供的检测硬件的实施环境示意图；
图6为本申请实施例提供的检测硬件的方法流程图；
图7为本申请实施例提供的证书结构示意图；
图8为本申请实施例提供的检测硬件的实施环境示意图；
图9为本申请实施例提供的检测硬件的方法流程图；
图10为本申请实施例提供的相关技术中检测硬件的过程示意图；
图11为本申请实施例提供的检测硬件的装置的结构示意图；
图12为本申请实施例提供的检测硬件的装置的结构示意图；
图13为本申请实施例提供的检测硬件的装置的结构示意图；
图14为本申请实施例提供的检测硬件的设备的结构示意图；
图15为本申请实施例提供的检测硬件的设备的结构示意图。
具体实施方式
本申请的实施方式部分使用的术语仅用于对本申请的实施例进行解释，而非旨在限定 本申请。
硬件的安全性是密码算法、安全协议等软件安全技术的基础，近年来，针对硬件的攻击行为越来越常见。例如，硬件仿冒、替换等攻击行为。
对此，本申请实施例提供了一种检测硬件的方法，该方法针对硬件仿冒、替换等攻击行为，提出了硬件绑定的安全方案，且基于密码学原理，来保证物理载体上所承载的硬件的安全性。其中，物理载体包括但不限于单板，单板包括印制电路板(printed circuit board，PCB)、元器件和连接器等部件，单板能够完成一定功能的电路单元，单板可以插入背板上的连接器中。单板上承载有多个硬件，该硬件包括但不限于处理器、微控制单元(Microcontroller Unit，MCU)、可信平台模块(trusted platform module，TPM)、现场可编程门阵列(field programmable gate array，FPGA)、复杂可编程逻辑器件(complex programmable logic device，CPLD)等。单板和背板可用作网络设备的组件。网络设备为路由设备，比如路由器或高层交换机，高层交换机三至七层交换机，比如三层交换机、四层交换机、五层交换机、六层交换机层交换机或七层交换机。交换设备包括以太网交换机或三至七层交换机。物理载体也可以是具有其他功能的PCB，比如手持设备主板或电脑主板或服务器主板或其他电子设备包含的PCB。
以物理载体包括单板，单板上承载两个硬件为例，对本申请实施例提供的方法所应用的实施环境进行说明。如图1所示，该实施环境中包括验证单元、单板及证书颁发机构(certificate authority，CA)。其中，验证单元可以与单板在同一侧，即相对于单板而言，验证单元为本地设备，验证单元在本地实现对单板上的硬件进行检测。除此之外，验证单元也可以与单板不在同一侧，而是与单板进行远程连接，以远程方式实现对单板上的硬件进行检测，本申请实施例不对验证单元是否部署在本地进行限定。如图1所示，单板上承载的两个硬件分别为芯片1和芯片2，该芯片1和芯片2可以是处理核心业务功能的芯片，其被替换、仿冒会导致对业务安全性的直接威胁。对此，本申请实施例采用芯片生成芯片身份密钥、基于芯片身份密钥建立芯片间的绑定关系以及基于密码学对芯片的完整性进行验证等方式，对单板上的芯片进行安全性检测。身份密钥是用于代表不同芯片身份的密钥，也可以由根密钥派生。
如图1所示，由验证单元向单板发送第一验证数据，单板上的芯片1和芯片2分别基于各自的硬件标识生成密钥。以芯片1的硬件标识为芯片ID1，芯片2的硬件标识为芯片ID2为例，芯片1生成的密钥为ID1 key(密钥)，芯片2生成的密钥为ID2 key。芯片1基于芯片1生成的密钥对第一验证数据进行加密，得到密文，如密文1。芯片2基于芯片2生成的密钥对第一验证数据进行加密，得到密文，如密文2。此外，基于芯片1和芯片2生成的密钥建立芯片1和芯片2的绑定关系，得到绑定关系信息。单板将密文1和密文2以及绑定关系信息发送至验证单元，示例性地，可以由单板上的芯片1或芯片2将密文1和密文2以及绑定关系信息发送至验证单元，也可以是在芯片1和芯片2对第一验证数据进行加密得到密文之后，芯片1和芯片2分别将各自得到的密文1和密文2发送给单板上除芯片1和芯片2之外的组件，由该组件将密文1和密文2以及绑定关系信息发送至验证单元，或芯片1将密文1发给验证单元，芯片2将密文2发给验证单元，芯片1和/或芯片2将绑定关系发给验证单元。本申请实施例不对单板将密文1和密文2以及绑定关系信息发送至验证单元的方式进行限定，验证单元接收到该密文1和密文2以及绑定关系信息后，由验证单元验证绑定关系的正确性以及密码 运算结果的正确性，从而确定芯片1和芯片2的安全性。
其中，芯片1和芯片2生成密钥的过程可以在接收到验证单元发送的第一验证数据之前生成，也可以在接收到验证单元发送的第一验证数据之后生成，本申请实施例对此不加以限定，保证能够在对第一验证数据进行加密之前生成即可。此外，芯片1和芯片2对第一数据进行加密，以及基于芯片1和芯片2生成的密钥建立芯片1和芯片2的绑定关系，得到绑定关系信息这几个过程的先后执行顺序，本申请实施例同样不加以限定。
作为一种示例性实施方式，绑定关系可以采用证书的形式实现。如图1所示的实施环境中，以单板在CA上进行密钥注册为例，CA是证书颁发机构，单板通过向CA申请密钥注册，由CA确定绑定关系，生成公证证书。公证证书中包括芯片1和芯片2的密钥之间的绑定关系，如ID1 key与ID2 key的绑定关系。除此之外，公证证书中还包括CA对绑定关系进行签名之后得到的数字签名。其中，公证证书中的数字签名是CA采用CA的私钥对绑定关系进行签名得到。CA将公证证书返回给单板，由单板进行存储。例如，可以存储在芯片1上，或者芯片2上，或者存储在单板中除芯片1和芯片2的其他存储区域。之后，当单板接收到验证单元发送的第一验证数据后，单板再获取存储的公证证书，以将公证证书和密文发送至验证单元。
接下来，基于上述图1所示的实施环境，对本申请实施例提供的检测硬件的方法进行说明。如图2所示，该方法包括如下几个步骤：
步骤201，验证单元向物理载体发送第一验证数据，物理载体上承载有多个硬件。
验证单元向物理载体发送的第一验证数据用于后续的验证，本申请实施例不对第一验证数据的内容加以限定。例如，验证单元可以基于挑战-响应机制向物理载体发起挑战，如向物理载体发送随机数(Nonce)，随机数即为第一验证数据。此外，除了发送随机数，还可以发送其他由通信协议确定的数据，则随机数及其他由通信协议确定的数据中的一种或多种均可以作为第一验证数据。例如，其他由通信协议确定的数据包括由可信赖计算组织(trusted computing group，TCG)的引证(Quote)协议确定的数据，或者由简单网络管理协议(simple network management protocol，SNMP)确定的数据，或者由网络配置协议(network configuration protocol，NETCONF)确定的数据等。
由于物理载体上承载有多个硬件，因而该第一验证数据可以直接发送给物理载体上的其中一个硬件，比如发给需要检测的硬件。也可以由物理载体上的数据接口来接收，之后传输至物理载体的硬件(比如需检测的硬件)中。
步骤202，物理载体接收验证单元发送的第一验证数据。
物理载体接收验证单元发送的第一验证数据，可以是物理载体上承载的多个硬件中的一个硬件接收，也可以是通过物理载体上的数据接口来接收。当第一验证数据到达物理载体后，为了使需要进行硬件检测的每个硬件均能够对第一验证数据进行加密，以进行后续的检测流程，该第一验证数据需要传输至各个需要检测的硬件上。
步骤203，物理载体获取密文和绑定关系信息。
获取密文的方式可以是由被检测硬件采用被检测硬件的密钥对第一验证数据进行加密得到，该被检测硬件可以是物理载体上承载的多个硬件中的至少两个硬件，即密文是物理载体上承载的多个硬件中的至少两个硬件分别采用各自的密钥对第一验证数据进行加密之后得到的。如果需要对物理载体上承载的所有硬件进行检测，则可以由物理载体上承 载的每个硬件分别采用各自的密钥对第一验证数据进行加密，得到密文。
绑定关系信息用于指示至少两个硬件之间的绑定关系，物理载体获取绑定关系信息的方式可以是建立该至少两个硬件之间的绑定关系，得到绑定关系信息。例如，物理载体将该至少两个硬件的密钥进行绑定，将密钥之间的绑定关系作为硬件之间的绑定关系。如果需要对物理载体上承载的所有硬件进行检测，则可以建立每个硬件之间的绑定关系。也就是说，无论是获取密文，还是获取绑定关系信息，涉及的物理载体上承载的多个硬件中的至少两个硬件可以是物理载体上承载的全部硬件，也可以是物理载体上承载的一部分硬件。
当需要检测的硬件的数量大于两个时，可将所有需要检测的硬件采用一个绑定关系来绑定，例如，一个绑定关系中包括需要检测的所有硬件的密钥。此外，当需要检测的硬件的数量大于两个时，也可以通过多个绑定关系来绑定，例如，每两个硬件之间建立一个绑定关系，或者每三个硬件之间建立一个绑定关系。本申请实施例不对建立绑定关系的硬件的数量进行限定，也不对建立的绑定关系的数量进行限定，保证每个需要被检测的硬件都能够通过绑定关系实现验证即可。且针对多个绑定关系的情况，每个绑定关系均可以采用下面的验证方式进行验证。例如，对于需要检测的硬件1而言，验证单元可以获取硬件1的密文，以及与硬件1有绑定关系的一个或多个硬件生成的密文，以及绑定关系，来检测硬件1是否正确可信。与硬件1有绑定关系的一个或多个硬件生成密文的方式与实施例中所述的方式类似，不再赘述。
关于硬件对第一验证数据进行加密时所使用的密钥，本申请实施例不加以限定。例如，硬件在生产制造过程中被注入根密钥，基于该根密钥可派生出身份密钥，则可以通过该身份密钥对第一验证数据进行加密。
除采用上述基于根密钥生成身份密钥的方式外，在一种示例性实施例中，由于硬件标识(ID)能够用于保证硬件的真实性及供应链的可追溯性，硬件ID是硬件的固有属性，具有唯一性、不可复制、受到硬件保护。但是，硬件ID当前局限在供应链的保护，未在安全技术方案中得到广泛应用。对此，本申请实施例提供的方法中，硬件所对应的密钥由至少两个硬件分别基于各自的硬件标识生成。由于硬件ID的存储由硬件提供保护，而基于生产时注入的根密钥派生身份密钥的方式中，身份密钥基于根密钥，根密钥的安全性严重依赖于硬件生产环境的安全性、密钥注入方式的安全性。因此，采用硬件ID生成密钥的方式与一般的密钥生成方式相比，具备更强的安全性。
示例性地，硬件ID包括但不限于硬件唯一密钥(hardware unique key，HUK)、物理不可克隆函数(physical unclonable function，PUF)、机密性受保护的一次性可编程(one time progra mable，OTP)中的标识信息或背书密钥(endorsement key，EK)。其中，HUK、PUF、OTP中的标识信息或EK等作为硬件标识具有唯一、随机、不可篡改、安全访问等特性，因而基于这些硬件标识生成密钥，可对密钥的安全性提供了安全保障。采用哪种硬件标识生成密钥，可以基于硬件来确定。无论是采用哪种硬件标识，生成的密钥可以是对称密钥，也可以是非对称密钥。如果是对称密钥，则对第一验证数据进行加密，以及建立绑定关系时均使用该对称密钥。
作为一种示例性实施例，当密钥是非对称密钥时，密钥包括公钥和私钥；密文是至少两个硬件分别采用各自的私钥对第一验证数据进行加密之后得到的，绑定关系信息基于至少两个硬件所对应的公钥之间的绑定关系得到。
另外，绑定关系信息可以是在接收到第一验证数据后，再建立硬件之间的绑定关系，从而得到绑定关系信息。也可以是在接收到第一验证数据之前，先建立好绑定关系，存储绑定关系信息。则获取绑定关系信息之前，还包括：获取至少两个硬件的密钥，基于至少两个硬件的密钥之间的绑定关系获取绑定关系信息，存储绑定关系信息。当接收到第一验证数据后，再获取已经存储的绑定关系信息。
示例性地，物理载体基于至少两个硬件的密钥之间的绑定关系获取绑定关系信息，存储绑定关系信息，包括：物理载体向CA注册至少两个硬件的密钥，CA确定需要建立的绑定关系后，建立绑定关系，对绑定关系进行签名，得到公证证书。除了由物理载体统一向CA注册至少两个硬件的密钥的方式之外，在一种示例性实施例中，物理载体上的硬件也可以将各自的密钥发送至CA进行注册。例如，每个被检测的硬件将各自的密钥和所在物理载体的标识一并发送至CA，CA根据各个硬件发送的物理载体的标识，将同一物理载体上的硬件的密钥进行绑定，得到绑定关系，对该绑定关系进行签名，得到公证证书。无论是物理载体统一注册还是物理载体上的各个硬件分别注册的方式，公证证书中的数字签名均是CA采用CA的私钥对绑定关系进行签名得到。CA得到公证证书之后，将公证证书发送至物理载体，由物理载体存储公证证书，公证证书中包括至少两个硬件所对应的密钥之间的绑定关系，还包括对该绑定关系进行签名之后得到的数字签名。针对绑定关系以证书形式实现的情况，物理载体获取绑定关系信息，包括：获取公证证书。通过密钥建立硬件之间的绑定关系，因而绑定关系受密码学方法保护。此外，绑定关系可以以证书形式表现。因此，具备易用性的特点。
关于获取证书的方式，如上述图1所示的实施环境中的介绍，物理载体或者物理载体上的硬件可以向CA注册密钥，即注册芯片1的密钥ID1Key和芯片2的密钥ID2Key。CA确定芯片1的密钥和芯片2的密钥的绑定关系后，建立芯片1的密钥ID1Key和芯片2的密钥ID2Key的绑定关系，之后再采用CA的私钥对建立的绑定关系进行签名，得到公证证书。也就是说，该公证证书包含建立绑定关系的硬件的密钥，公证证书还包括对绑定关系进行签名得到的数字签名。例如，如果各个硬件生成的密钥是对称密钥，则公证证书中包含的硬件之间的绑定关系是各个硬件的对称密钥之间的绑定关系。如果各个硬件生成的密钥是非对称密钥，则公证证书中包含的硬件之间的绑定关系可以是硬件的非对称密钥中的公钥，而硬件的私钥存储于硬件的安全环境中。安全环境包括但不限于可信执行环境(trusted execution environment，TEE)，即代码的安全运行环境，也可以为安全的生产环境。
步骤204，物理载体将密文和绑定关系信息发送至验证单元。
物理载体获取到密文和绑定关系信息后，将密文和绑定关系信息一起发送至验证单元。物理载体将密文和绑定关系信息发送至验证单元时，可以由物理载体上的被检测硬件中的任一硬件来发送，该种方式下，物理载体上的每个被检测硬件得到密文后，将密文发送至该任一硬件，由该任一硬件将密文和绑定关系信息一起发送至验证单元。除此之外，也可以是由物理载体上除被检测硬件之外的其他组件来发送密文和绑定关系信息，该种方式下，物理载体上的每个被检测硬件得到密文后，将密文发送至该其他组件，由该其他组件将密文和绑定关系信息一起发送至验证单元。示例性地，无论是由哪个主体将密文和绑定关系信息发送至验证单元，由于被检测硬件分别对第一验证数据进行加密得到了密文，密文的数量与被检测硬件的数量一致，则每个密文可以依次连接添加到数据格式中发送。例如， 密文的格式如下面表1所示。
表1
密文1 密文2
当然，除了发送密文和绑定关系信息之外，物理载体还可以向验证单元发送其他数据，也可以将验证单元发送的第一验证数据一并返回。则以第一验证数据为随机数Nonce为例，密文的格式如下面表2所示。其中，DATA可以是其他数据，本申请实施例对其他数据的内容不加以限定。
表2
DATA... Nonce 密文1 密文2
步骤205，验证单元接收物理载体返回的密文和绑定关系信息。
验证单元接收物理载体返回的密文和绑定关系信息，如果绑定关系信息是以公证证书的形式发送的，则验证单元接收物理载体返回的密文和绑定关系信息，包括：接收物理载体返回的密文和公证证书，公证证书中包括至少两个硬件所对应的密钥之间的绑定关系，还包括绑定关系的数字签名。
步骤206，验证单元对密文及绑定关系信息进行验证，基于验证结果确定至少两个硬件的安全性。
示例性地，绑定关系信息包括至少两个硬件所对应的密钥之间的绑定关系；验证单元对密文及绑定关系信息进行验证，包括：获取至少两个硬件所对应的密钥，基于至少两个硬件所对应的密钥验证绑定关系信息包括的绑定关系是否正确；采用至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致。
其中，验证单元获取至少两个硬件所对应的密钥的方式，可以是在物理载体建立绑定关系信息之后，将每个硬件的密钥发送至验证单元，由验证单元进行存储。其中，将每个硬件的密钥发送至验证单元，可以是由物理载体上的组件统一发送，也可以由每个硬件各自独立发送，本申请不对将每个硬件的密钥发送至验证单元的方式进行限定。以物理载体统一将每个硬件的密钥发送至验证单元为例，由于验证单元可能需要对多个物理载体上的硬件进行检测，因而验证单元可接收到多个物理载体发送过来的密钥。验证单元在存储密钥时，可将每个密钥与物理载体标识对应存储，以通过物理载体标识区分不同物理载体上的硬件的密钥。后续在检测该物理载体上的硬件时，验证单元再从存储的密钥中获取该物理载体所承载的该至少两个硬件的密钥。当然，也可以采用其他对应存储的方式，本申请实施例对此不进行限定。
获取到之前存储的该至少两个硬件的密钥后，验证单元基于该至少两个硬件所对应的密钥验证绑定关系信息包括的绑定关系是否正确。例如，验证绑定关系中的两个密钥是否与验证单元之前存储的密钥相同，如果绑定关系中的密钥与之前存储的密钥相同，则绑定关系正确，如果绑定关系中的密钥与之前存储的密钥不相同，则绑定关系不正确。除采用该种方式外，如果绑定关系是以证书形式实现的，公证证书中除了包括绑定关系，还包括对绑定关系进行签名之后得到的数字签名，则验证单元采用证书颁发机构反馈的密钥，基 于该证书颁发机构反馈的密钥对公证证书中的数字签名进行验证，如果验证成功，则绑定关系正确，如果验证失败，则绑定关系不正确。其中，公证证书中的数字签名是证书颁发机构采用证书颁发机构的私钥对绑定关系进行签名得到，则验证单元可基于证书颁发机构的公钥对公证证书中的数字签名进行验证。
当绑定关系正确时，再采用至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致。则基于验证结果确定至少两个硬件的安全性，包括：当验证结果为绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定至少两个硬件为安全状态。示例性地，当验证结果为绑定关系信息包括的绑定关系不正确，或者解密得到的第二验证数据与第一验证数据不一致时，则可以确定物理载体上的硬件为非安全状态，可能存在安全隐患，可以采取相应的异常处理。
需要说明的是，以上是以先获取至少两个硬件所对应的密钥，基于至少两个硬件所对应的密钥验证绑定关系信息包括的绑定关系是否正确；再采用至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致。作为一种示例性实施例，也可以获取至少两个硬件所对应的密钥，采用至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致。当验证解密得到的第二验证数据与第一验证数据一致时，再基于至少两个硬件所对应的密钥验证绑定关系信息包括的绑定关系是否正确。也就是说，本申请实施例不对验证单元验证密文和验证绑定关系信息的先后顺序进行限定。
此外，示例性地，验证单元验证第二验证数据与第一验证数据是否一致时，可以是将第一验证数据中的每个字段与第二验证数据中的每个字段一一比对，只有第二验证数据与第一验证数据的所有字段完全一致时，才可确认第二验证数据和第一验证数据是一致的。该种方式由于是将第一验证数据与第二验证数据中所有字段均进行了比对，因而验证结果较为准确，可靠性较高。示例性地，除了验证全部字段，还可将第二验证数据中的目标字段与第一验证数据中的目标字段进行比对，该目标字段可以随机选取或者将关键字段作为目标字段。当第二验证数据中的目标字段与第一验证数据中的目标字段匹配时，可以确认第二验证数据和第一验证数据是一致的。该种通过比对目标字段的方式由于无需将第二验证数据和第一验证数据中的所有字段一一比对，因而能够提高验证速度。至于采用哪种方式来验证第二验证数据与第一验证数据是否一致，本申请实施例不加以限定。
需要说明的是，无论采用哪种验证第二验证数据与第一验证数据是否一致的方式，该第一验证数据可以是物理载体发送的。也就是说，验证单元向物理载体发送第一验证数据后，物理载体向验证单元返回密文和绑定关系信息时，一并将第一验证数据也返回给验证单元。则验证单元对密文解密之后，将解密得到的第二验证数据与该第一验证数据进行比对。在一种示例性实施例中，物理载体也可以不返回该第一验证数据，则该种情况下，验证单元可以记录之前发送给该物理载体的第一验证数据，之后在接收到该物理载体发送的密文和绑定关系信息，对密文进行解密之后，将解密得到的第二验证数据与记录的第一验证数据进行比对。关于验证单元记录发送给物理载体的第一验证数据的方式，本申请实施例不加以限定，后续能够针对物理载体确定发送给该物理载体的第一验证数据的内容即可。
以物理载体为单板，物理载体上的硬件为芯片，获取绑定关系信息的过程如图3所示 为例。图3中，单板上的芯片基于芯片ID生成身份密钥之后，提交绑定关系信息签发证书申请请求。CA接收到单板发送的申请请求，当CA验证请求的合法性之后，颁发绑定关系信息，即公证证书。将公证证书即绑定关系信息发送至单板。单板验证绑定关系信息的有效性之后，在本地存储绑定关系信息。之后，当需要对单板上的芯片进行硬件检测时，如图4所示，图4示出了检测硬件的过程。图4中，验证单元向单板发起挑战，单板上的芯片生成身份密钥，使用身份密钥对验证单元发送的第一验证数据进行加密，得到密文。此外，单板获取基于芯片之间的绑定关系得到的绑定关系信息，如图3中获取的公证证书。之后，单板将密文及绑定关系信息一并发送至验证单元，由验证单元验证绑定关系信息的正确性，使用对应的身份密钥验证加密数据即密文的正确性。由于物理载体上承载的硬件进行绑定之后，如果被仿冒或者被替换，则硬件之间的绑定关系发生变化，无法通过后续的验证。由此，通过绑定关系及密文的验证方式能够确定单板上的硬件的安全性。其中，通过密文来验证单板上的硬件的真实性，通过绑定关系来验证单板上的硬件的完整性。
需要说明的是，上述检测硬件的方法针对单板上的硬件检测为例进行说明，本实施例提供的方法除了应用于单板，还可以针对整个设备上的多个单板分别进行硬件检测。每个单板上的硬件检测方式均可以采用上述方法实现。针对整个设备而言，如果某个单板未通过硬件检测，例如，如果插入未认证的单板，则设备将报警或拒绝服务。当然，在设备间进行单板替换也是能够实现报警，由此可以进一步保护整个设备的硬件完整性。
此外，作为一种示例性实施例，本申请实施例提供的方法在检测硬件的基础上，还可以将硬件检测结果与其他技术相结合。例如，将本申请实施例提供的方法所得到的硬件检测结果与联合测试工作组(joint test action group，JTAG)鉴权技术相融合。其中，JTAG鉴权功能保证未通过鉴权的仿真器或控制单元，不能获得芯片JTAG调试控制权。将本申请实施例提供的方法与JTAG鉴权技术相融合时，例如，可以在硬件通过检测的情况下，才授予JTAG权限，即通过JTAG权限使用JTAG鉴权功能。通过将JTAG鉴权技术与本申请实施例提供的检测硬件的方法相结合，能够更大限度地保障硬件的安全。
综上所述，本申请实施例提供的方法，基于物理载体上承载的硬件之间的绑定关系以及硬件采用各自的密钥加密的密文来验证硬件的安全性，能够防止硬件发生被替换以及被仿冒等攻击行为。
此外，利用硬件的密钥，通过密码学方法(如数字签名、非对称加解密)验证硬件的真实性。验证过程可以基于挑战-响应的机制，各个硬件分别利用私钥对挑战做出响应；验证单元通过各硬件的公钥验证响应的正确性，判断硬件是否被篡改。该验证过程可以与可信赖计算组织(trusted computing group，TCG)或因特网工程任务组(internet engineering task framework，IETF)-RATS验证规范兼容。
本申请实施例提供的检测硬件的方法可应用于多种场景，适用于多种类型的硬件的检测。接下来，基于上述检测硬件的方法，针对不同应用场景进行举例说明。
场景一：保护硬件可信根的场景
由于硬件可信根是单板安全启动、可信启动的基础，因而保护硬件可信根的完整性尤为重要。而单板的硬件可信根通常由处理器和TPM安全芯片组成。其中，处理器作为可信度量根，TPM芯片作为可信报告根和可信存储根。则针对单板上的处理器和TPM芯片进行 硬件检测，以处理器为系统芯片(system on a chip，SoC)为例，检测硬件的方法的实施环境如图5所示。结合图5所示的实施环境，本申请实施例提供的检测硬件的方法可如图6所示，以物理载体为单板，验证单元为远程验证(remote attestation，RA)服务器为例，该检测硬件的方法包括如下几个步骤。
步骤601，RA服务器向单板发送随机数，单板上承载有SoC和TPM。
RA服务器向单板发送的随机数用于后续的验证，本申请实施例不对随机数的内容加以限定。例如，RA服务器可以基于挑战-响应机制向单板发起挑战，以向单板发送随机数(Nonce)。此外，除了发送随机数，还可以发送其他由通信协议确定的数据，则随机数及其他由通信协议确定的数据均可以作为随机数。例如，在本申请实施例中，RA服务器向单板除了发送随机数，还可以发送端口命令寄存器(port command register，PCR)的值。
以仅发送随机数为例，由于单板上承载有SoC和TPM这两个硬件，因而该随机数可以发送给单板上的SoC，然后在单板内部再发送至TPM。也可以由单板上的数据接口来接收，之后传输至SoC和TPM中。
步骤602，单板接收RA服务器发送的随机数。
单板接收RA服务器发送的随机数后，为了使需要进行硬件检测的SoC和TPM均能够基于随机数进行加密，以进行后续的检测流程，该随机数需要传输至SoC和TPM上。
步骤603，单板获取密文和绑定关系信息。
密文是单板上承载的SoC和TPM分别采用各自的密钥对随机数进行加密之后得到的。如果RA服务器除了发送随机数，还发送了PCR寄存器的值，则密文是单板上承载的SoC和TPM分别采用各自的密钥对随机数和PCR寄存器的值进行加密之后得到的。在一种示例性实施例中，硬件所对应的密钥由硬件基于各自的硬件标识生成。
由于当前主流处理器均支持TEE，如精简指令集计算机微处理器(advanced reduced instruction set computing machines，ARM)处理器的可信区域(trust zone)，因特尔(Intel)处理器的软件保护扩展(software guard extensions，SGX)。TEE具有较高的安全特性，可以保证非对称密钥尤其是私钥的机密性和完整性。因此，如图5所示，SoC可基于TEE可信执行环境，如在可信区读取HUK信息并生成身份密钥对，即SoC采用HUK生成非对称密钥，包括公钥和私钥，将私钥安全存储于TEE中。例如，图5中SoC生成的密钥为ID key。
对于TPM芯片，根据可信赖计算组织(trusted computing group，TCG)技术规范，由EK生成证明标识密钥(attestation identity key，AIK)作为TPM芯片的身份密钥。此外，TPM芯片本身的安全属性，能够为密钥的存储、访问提供了较高的安全保护环境。
绑定关系信息用于指示SoC和TPM之间的绑定关系。示例性地，在进行硬件检测之前，可以基于SoC和TPM的密钥之间的绑定关系获取绑定关系信息，存储绑定关系信息。例如，单板向CA申请AIK证书。例如，单板通过注册SoC和TPM的公钥，CA向单板颁发AIK证书。单板将AIK证书存储于TPM中，AIK证书中包括SoC的公钥及TPM的AIK公钥之间的绑定关系，还包括数字签名，该数字签名是CA采用CA的私钥对绑定关系进行签名得到。AIK证书结构如图7所示。图7中，AIK证书包括基本域和扩展域。其中，基本域包括版本(version)、序列号(serial no.)、颁发者签名算法(issuer signature algorithm)、公钥信息(subject public key information)、颁发者签名(issuer’s signature)，其中，公钥信息内存储AIK公钥，颁发者签名即CA对绑定关系进行签名得到的数字签名。扩展域包括使用者可选名称 (subject alternative name)以及密钥用法(Key Usage)，其中，subject alternative name内存储HUK派生密钥的公钥信息。
此外，AIK证书可以采用X509.v3格式，也可以采用自定义格式。本申请实施例对此不加以限定，图7中以标准的X509.v3版本为例。由于AIK证书由CA提供背书，因此，本申请实施例提供的方法借用TCG中AIK证书表达处理器和TPM芯片的绑定关系。
该种情况下，单板获取绑定关系信息，包括：获取公证证书。如图5所示的实施环境，单板可以向CA注册密钥，得到公证证书，公证证书包含建立绑定关系的硬件的密钥，及绑定关系的数字签名。针对SoC和TPM生成的密钥，AIK证书中包含的绑定关系可以是ID key与AIK之间的绑定关系。即由AIK证书建立硬件可信根的绑定关系。绑定关系的数字签名可以是CA采用CA的私钥对绑定关系进行签名得到。
步骤604，单板将密文和绑定关系信息发送至RA服务器。
单板获取到密文和绑定关系信息后，将密文和绑定关系信息一起发送至RA服务器。示例性地，由于SoC和TPM分别对随机数进行加密得到了密文，密文的数量为两个。以SoC对随机数进行加密得到SoC签名，TPM对随机数进行加密得到AIK签名为例，则SoC签名和AIK签名可以依次连接添加到数据格式中发送。例如，数据格式如下面的表3所示。
表3
Figure PCTCN2020101699-appb-000001
当然，单板除了向RA服务器发送密文和绑定关系信息之外，单板向RA服务器还可以发送其他数据，也可以将RA服务器发送的随机数一并返回。例如，如果RA服务器向单板除了发送随机数，还发送了PCR寄存器的值，则单板除了将SoC签名和AIK签名发送至RA服务器之外，还可以将随机数及PCR寄存器的值一并发送给RA服务器。针对该种情况，例如，数据格式如下面的表4所示。
表4
Figure PCTCN2020101699-appb-000002
步骤605，RA服务器接收单板返回的密文和绑定关系信息。
RA服务器接收单板返回的密文和绑定关系信息，如图5所示，绑定关系信息是以公证证书的形式发送的，则RA服务器接收单板返回的密文和AIK证书，证书中包括SoC和TPM所对应的密钥之间的绑定关系。
步骤606，RA服务器对密文及绑定关系信息进行验证，基于验证结果确定SOC和TPM的安全性。
示例性地，绑定关系信息包括至少两个硬件所对应的密钥之间的绑定关系；RA服务器对密文及绑定关系信息进行验证，包括：获取SoC和TPM所对应的公钥，基于SoC和TPM所对应的公钥验证绑定关系信息包括的绑定关系是否正确；采用SoC和TPM所对应的公钥对SoC和TPM加密的密文分别进行解密，验证解密得到的数据与随机数是否一致。
其中，RA服务器获取SoC和TPM所对应的公钥的方式，可以是在单板建立绑定关系信息之后，将SoC和TPM的公钥发送至RA服务器，由RA服务器进行存储。由于RA服务器可能需要对多个单板上的硬件进行检测，因而RA服务器可接收到多个单板发送过来的密钥。RA服务器在存储密钥时，可将每个密钥与单板标识对应存储，以通过单板标识区分不同单 板上的硬件的密钥。后续在检测该单板上的硬件时，RA服务器再从存储的密钥中获取该单板所承载的该至少两个硬件的密钥。
获取到之前存储的SoC和TPM的公钥后，RA服务器基于该SoC和TPM所对应的公钥验证绑定关系信息包括的绑定关系是否正确。针对绑定关系是以证书形式实现的情况，公证证书中除了包括绑定关系，还包括对绑定关系进行签名之后得到的数字签名，该数字签名是证书颁发机构采用证书颁发机构的私钥对绑定关系进行签名得到，则RA服务器基于公证证书中的数字签名验证绑定关系信息包括的绑定关系是否正确。示例性地，RA服务器采用证书颁发机构的公钥对公证证书中的数字签名进行验证，如果验证成功，则绑定关系正确，如果验证失败，则绑定关系不正确。无论是否采用证书，如果验证绑定关系正确，再采用SoC和TPM所对应的密钥对SoC和TPM加密的密文分别进行解密，验证解密得到的数据与随机数是否一致。则基于验证结果确定SoC和TPM的安全性。例如，当验证结果为绑定关系信息包括的绑定关系正确，且解密得到的数据与随机数一致时，确定SoC和TPM为安全状态，说明SoC和TPM是真实的，不存在仿冒、替换等攻击。示例性地，当验证结果为绑定关系信息包括的绑定关系不正确，或者解密得到的数据与随机数一致时，则可以确定单板上的SoC和TPM为非安全状态，可能存在安全隐患，可以采取相应的异常处理。关于异常处理的方式，本申请实施例对此不加以限定。
综上所述，本申请实施例提供的方法，基于单板上承载的SoC和TPM之间的绑定关系，以及SoC和TPM采用各自的密钥加密的密文来验证SoC和TPM的安全性，能够防止SoC和TPM发生被替换以及被仿冒等攻击行为。此外，本申请实施例以RA服务器作为验证单元，对Nonce(随机数)的加解密操作可以采用TCG中的可信验证流程。以上业务流程可以建立在标准的可信计算流程的基础上，因此，能够不增加系统的硬件实现复杂度，具备可行性。
场景二：保护数据处理单元的场景
由于处理器和FPGA是单板中比较重要的数据处理单元，通常情况下，处理器倾向于实现控制、存储和数据处理功能；对于数据流处理性能有较高要求的场景，会使用FPGA实现硬件加速功能。例如，在密码卡中，FPGA通常负责密码运算的硬件加速；处理器则主要用于管理、板间数据通信功能。如果处理器和FPGA中含有硬件木马(Trojan)、间谍软件(Spyware)，将直接导致系统安全隐患。因此，保证单板中FPGA和处理器硬件的完整性、真实性尤为重要。以处理器为SoC为例，检测硬件的方法的实施环境如图8所示。结合图8所示的实施环境，本申请实施例提供的检测硬件的方法可如图9所示，包括如下几个步骤。
步骤901，验证单元向单板发送随机数，单板上承载有SoC和FPGA。
验证单元向单板发送的随机数用于后续的验证，本申请实施例不对随机数的内容加以限定。例如，验证单元可以基于挑战-响应机制向单板发起挑战，以向单板发送随机数(Nonce)。此外，除了发送随机数，还可以发送其他由通信协议确定的数据，则随机数及其他由通信协议确定的数据均可以作为随机数。
由于单板上承载有SoC和FPGA这两个硬件，因而该随机数可以发送给单板上的SoC，然后在单板内部再发送至FPGA。也可以由单板上的数据接口来接收，之后传输至SoC和 FPGA中。
步骤902，单板接收验证单元发送的随机数。
单板接收验证单元发送的随机数后，为了使需要进行硬件检测的SoC和FPGA均能够基于随机数进行加密，以进行后续的检测流程，该随机数需要传输至SoC和FPGA上。
步骤903，单板获取密文和绑定关系信息。
密文是单板上承载的SoC和FPGA分别采用各自的密钥对随机数进行加密之后得到的。在一种示例性实施例中，硬件所对应的密钥由硬件基于各自的硬件标识生成。
由于当前主流处理器均支持TEE，如精简指令集计算机微处理器(advanced reduced instruction set computing machines，ARM)处理器的可信区域(TrustZone)，因特尔(Intel)处理器的SGX。TEE具有较高的安全特性，可以保证非对称密钥尤其是私钥的机密性和完整性。因此，如图5所示，SoC可基于TEE可信执行环境，读取HUK信息并生成身份密钥对，即SoC采用HUK生成非对称密钥，包括公钥和私钥，将私钥安全存储于TEE中。例如，图8中SoC生成的密钥为ID1 key。
对于FPGA芯片，根据PUF生成非对称密钥作为FPGA芯片的身份密钥，如图8所示，FPGA生成的密钥为ID2Key。同时，FPGA芯片为密钥的存储、访问提供了较高的安全保护环境。
绑定关系信息用于指示SoC和FPGA之间的绑定关系。示例性地，在检测之前，可以基于SoC和FPGA的密钥之间的绑定关系获取绑定关系信息，存储绑定关系信息。例如，注册SoC和FPGA的公钥，得到公证证书，存储公证证书，公证证书中包括SoC和FPGA所对应的公钥之间的绑定关系，还包括绑定关系的数字签名；该种情况下，获取绑定关系信息，包括：获取公证证书。如图8所示的实施环境，单板可以向CA注册密钥，CA得到公证证书之后发送给单板，该公证证书包含建立绑定关系的硬件的密钥，及绑定关系的数字签名，该数字签名可以是CA采用CA的私钥对绑定关系进行签名得到。针对SoC和FPGA生成的密钥，公证证书中包含的绑定关系可以是ID1 key与ID2 key之间的绑定关系。
步骤904，单板将密文和绑定关系信息发送至验证单元。
单板获取到密文和绑定关系信息后，将密文和绑定关系信息一起发送至验证单元。示例性地，由于SoC和FPGA分别对随机数进行加密得到了密文，密文的数量为两个，则每个密文可以依次连接添加到数据格式中发送。当然，除了发送密文和绑定关系信息之外，单板向验证单元还可以发送其他数据，也可以将验证单元发送的随机数一并返回。在图8所示的实施环境中，单板将密文和证书发送给验证单元。
步骤905，验证单元接收单板返回的密文和绑定关系信息。
验证单元接收单板返回的密文和绑定关系信息，如图8所示，绑定关系信息是以公证证书的形式发送的，则验证单元接收单板返回的密文和AIK证书，证书中包括SoC和FPGA所对应的密钥之间的绑定关系，以及绑定关系的数字签名。
步骤906，验证单元对密文及绑定关系信息进行验证，基于验证结果确定SOC和FPGA的安全性。
示例性地，绑定关系信息包括至少两个硬件所对应的密钥之间的绑定关系；验证单元对密文及绑定关系信息进行验证，包括：获取SoC和FPGA所对应的公钥，基于SoC和FPGA所对应的公钥验证绑定关系信息包括的绑定关系是否正确；采用SoC和FPGA所对应的公钥 对SoC和FPGA加密的密文分别进行解密，验证解密得到的数据与随机数是否一致。
其中，验证单元获取SoC和FPGA所对应的公钥的方式，可以是在单板建立绑定关系信息之后，将SoC和FPGA的公钥发送至验证单元，由验证单元进行存储。由于验证单元可能需要对多个单板上的硬件进行检测，因而验证单元可接收到多个单板发送过来的密钥。验证单元在存储密钥时，可将每个密钥与单板标识对应存储，以通过单板标识区分不同单板上的硬件的密钥。后续在检测该单板上的硬件时，验证单元再从存储的密钥中获取该单板所承载的该至少两个硬件的密钥。
获取到之前存储的SoC和FPGA的公钥后，验证单元基于该SoC和FPGA所对应的公钥验证绑定关系信息包括的绑定关系是否正确。如果绑定关系正确，再采用SoC和FPGA所对应的密钥对SoC和FPGA加密的密文分别进行解密，验证解密得到的数据与随机数是否一致。则基于验证结果确定SoC和FPGA的安全性。针对绑定关系是以证书形式实现的情况，公证证书中除了包括绑定关系，还包括对绑定关系进行签名之后得到的数字签名，该数字签名是证书颁发机构采用证书颁发机构的私钥对绑定关系进行签名得到，则验证单元基于公证证书中的数字签名验证绑定关系信息包括的绑定关系是否正确。示例性地，验证单元采用该证书颁发机构的公钥对公证证书中的数字签名进行验证，如果验证成功，则绑定关系正确，如果验证失败，则绑定关系不正确。
例如，当验证结果为绑定关系信息包括的绑定关系正确，且解密得到的数据与随机数一致时，确定SoC和FPGA为安全状态。示例性地，当验证结果为绑定关系信息包括的绑定关系不正确，或者解密得到的数据与随机数一致时，则可以确定单板上的SoC和FPGA为非安全状态，可能存在安全隐患，可以采取相应的异常处理。例如，由验证单元发出报警，或由验证单元向显示设备发送提示信息，以提示单板上的硬件存在安全隐患。关于异常处理的方式，还可以采用其他的方式，本申请实施例对此不加以限定。
综上所述，本申请实施例提供的方法，基于单板上承载的SoC和FPGA之间的绑定关系，以及SoC和FPGA采用各自的密钥加密的密文来验证SoC和FPGA的安全性，能够防止SoC和FPGA发生被替换以及被仿冒等攻击行为。
针对硬件可信根的保护场景，相关技术提出了基于硬件标识检测硬件的方式。例如，如图10所示，设备上电后，首先执行安全启动业务流程，以确保启动软件的完整性；而后，由可信的软件操作系统(OS)验证硬件TPM的真实性。OS验证TPM安全芯片的唯一标识ID，并确认TPM安全芯片合法持有的证书。通过这一方式，确认TPM安全模块的真实性。也就是说，相关技术中，由安全启动保证软件的完整性，由可信软件保证硬件真实性。然而，该种方式具有一定的局限性，例如，相关技术提供的方案仅保证了TPM的真实性，并不具备硬件之间的绑定关系，对于单板中，其他硬件被替换的攻击场景没有防御能力，且针对其他硬件被仿冒的攻击场景也同样不具备防御能力。
本申请实施例提供的方法通过密钥进行加密得到密文，基于密文的验证来实现对单板中的硬件进行完整性的保护，有效防止单板中的硬件被仿冒、替换；且通过多个硬件之间的绑定进一步防止硬件被仿冒、替换。此外，本申请实施例提供的方法中，绑定关系可以通过证书的形式，可以兼容标准的TCG认证协议，能够在遵从TCG标准认证要求的同时，在协议中扩展硬件的绑定关系，从而具备较强的实用性。再有，本申请实施例提供的方法 中，密钥可以采用硬件ID来生成，充分应用了硬件的硬件ID、安全存储等安全特性，提高了安全性。因此，本申请实施例提供的方法具备可靠保障单板作为产品在发货、现网运行中的硬件真实性的能力。
参见图11，本申请实施例提供了一种检测硬件的装置，该装置可执行上述验证单元所执行的验证过程，该装置包括：
发送模块1101，用于向物理载体发送第一验证数据，物理载体上承载有多个硬件；
接收模块1102，用于接收物理载体返回的密文和绑定关系信息，密文是多个硬件中的至少两个硬件分别采用各自的密钥对第一验证数据进行加密之后得到的，绑定关系信息用于指示至少两个硬件之间的绑定关系；
验证模块1103，用于对密文及绑定关系信息进行验证，用于基于验证结果确定至少两个硬件的安全性。
作为一种示例性实施例，绑定关系信息包括至少两个硬件所对应的密钥之间的绑定关系；
验证模块1103，用于获取至少两个硬件所对应的密钥，基于至少两个硬件所对应的密钥验证绑定关系信息包括的绑定关系是否正确；采用至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致；
当验证结果为绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定至少两个硬件为安全状态。
作为一种示例性实施例，接收模块1102，用于接收物理载体返回的密文和公证证书，公证证书中包括至少两个硬件所对应的密钥之间的绑定关系，还包括绑定关系的数字签名；
验证模块1103，用于基于公证证书中的数字签名验证绑定关系信息包括的绑定关系是否正确；采用公证证书中至少两个硬件所对应的密钥对至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与第一验证数据是否一致；
当验证结果为绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定至少两个硬件为安全状态。
作为一种示例性实施例，至少两个硬件所对应的密钥由至少两个硬件分别基于各自的硬件标识生成。
作为一种示例性实施例，硬件标识包括HUK、PUF、机密性受保护的OTP中的标识信息或EK。
作为一种示例性实施例，密钥包括对称密钥或非对称密钥。
作为一种示例性实施例，当密钥是非对称密钥时，密钥包括公钥和私钥；
密文是至少两个硬件分别采用各自的私钥对第一验证数据进行加密之后得到的，绑定关系信息基于至少两个硬件所对应的公钥之间的绑定关系得到。
参见图12，本申请实施例提供了一种检测硬件的装置，该装置可执行上述物理载体的功能，该装置包括：
接收模块1201，用于接收验证单元发送的第一验证数据；
第一获取模块1202，用于获取密文和绑定关系信息，密文是物理载体上承载的多个硬 件中的至少两个硬件分别采用各自的密钥对第一验证数据进行加密之后得到的，绑定关系信息用于指示至少两个硬件之间的绑定关系；
发送模块1203，用于将密文和绑定关系信息发送至验证单元，由验证单元对密文及绑定关系信息进行验证，基于验证结果确定至少两个硬件的安全性。
作为一种示例性实施例，参见图13，该装置还包括：
第二获取模块1204，用于获取至少两个硬件的密钥，基于至少两个硬件的密钥之间的绑定关系获取绑定关系信息；
存储模块1205，用于存储绑定关系信息。
作为一种示例性实施例，第二获取模块1204，用于注册至少两个硬件的密钥，得到公证证书，公证证书中包括至少两个硬件所对应的密钥之间的绑定关系，还包括绑定关系的数字签名；
存储模块1205，用于存储公证证书；
第一获取模块1202，用于获取公证证书。
作为一种示例性实施例，至少两个硬件所对应的密钥由至少两个硬件分别基于各自的硬件标识生成。
作为一种示例性实施例，硬件标识包括HUK、PUF、机密性受保护的OTP中的标识信息或EK。
作为一种示例性实施例，密钥包括对称密钥或非对称密钥。
作为一种示例性实施例，当密钥是非对称密钥时，密钥包括公钥和私钥；密文是至少两个硬件分别采用各自的私钥对第一验证数据进行加密之后得到的，绑定关系信息基于至少两个硬件所对应的公钥之间的绑定关系得到。
应理解的是，上述提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
基于相同构思，本申请实施例还提供了一种检测硬件的设备，参见图14，该设备包括存储1401及处理器1402；存储器1401中存储有至少一条指令，至少一条指令由处理器1402加载并执行，以实现本申请实施例提供的上述任一种检测硬件的方法。
本申请实施例还提供了一种硬件检测设备1501、该存储器1502和该处理器1503通过内部连接通路互相通信，该存储器1502用于存储指令，该处理器1503用于执行该存储器存储的指令，以控制收发器1501接收信号，并控制收发器1501发送信号，并且当该处理器1503执行该存储器1502存储的指令时，使得该处理器1503执行上述任一种检测硬件的方法。
本申请实施例还提供了一种硬件检测系统，该系统包括上述图11所示的检测硬件的装置，以及上述图12或图13所示的检测硬件的装置。
本申请实施例还提供了一种计算机可读存储介质，存储介质中存储有至少一条指令， 指令由处理器加载并执行以实现本申请实施例提供的上述任一种检测硬件的方法。
本申请实施例还提供了一种芯片，包括处理器，处理器用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行上述任一种检测硬件的方法。
本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行上述任一种的检测硬件的方法。
应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field－programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced RISC machines，ARM)架构的处理器。
进一步地，在一种可选的实施例中，上述处理器为一个或多个，存储器为一个或多个。可选地，存储器可以与处理器集成在一起，或者存储器与处理器分离设置。上述存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。
该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用。例如，静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic random access memory，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
本申请提供了一种计算机程序，当计算机程序被计算机执行时，可以使得处理器或计算机执行上述方法实施例中对应的各个步骤和/或流程。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者 是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk)等。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (30)

  1. 一种检测硬件的方法，其特征在于，所述方法包括：
    向物理载体发送第一验证数据，所述物理载体上承载有多个硬件；
    接收所述物理载体返回的密文和绑定关系信息，所述密文是所述多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；
    对所述密文及所述绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
  2. 根据权利要求1所述的方法，其特征在于，所述绑定关系信息包括所述至少两个硬件所对应的密钥之间的绑定关系；
    所述对所述密文及所述绑定关系信息进行验证，包括：
    获取所述至少两个硬件所对应的密钥，基于所述至少两个硬件所对应的密钥验证所述绑定关系信息包括的绑定关系是否正确；
    采用所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；
    所述基于验证结果确定所述至少两个硬件的安全性，包括：
    当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
  3. 根据权利要求1所述的方法，其特征在于，所述接收所述物理载体返回的密文和绑定关系信息，包括：
    接收所述物理载体返回的密文和公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；
    所述对所述密文及所述绑定关系信息进行验证，包括：
    基于所述公证证书中的数字签名验证所述绑定关系信息包括的绑定关系是否正确；
    采用所述公证证书中所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；
    所述基于验证结果确定所述至少两个硬件的安全性，包括：
    当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
  4. 根据权利要求1-3任一所述的方法，其特征在于，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
  5. 根据权利要求4所述的方法，其特征在于，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
  6. 根据权利要求1-5任一所述的方法，其特征在于，所述密钥包括对称密钥或非对称密钥。
  7. 根据权利要求6所述的方法，其特征在于，当所述密钥是非对称密钥时，所述 密钥包括公钥和私钥；
    所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
  8. 一种检测硬件的方法，其特征在于，所述方法包括：
    接收验证单元发送的第一验证数据；
    获取密文和绑定关系信息，所述密文是物理载体上承载的多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；
    将所述密文和所述绑定关系信息发送至所述验证单元，由所述验证单元对所述密文及所述绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
  9. 根据权利要求8所述的方法，其特征在于，获取绑定关系信息之前，还包括：
    获取所述至少两个硬件的密钥，基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息，存储所述绑定关系信息。
  10. 根据权利要求9所述的方法，其特征在于，所述基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息，存储所述绑定关系信息，包括：
    注册所述至少两个硬件的密钥，得到公证证书，存储所述公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；
    所述获取绑定关系信息，包括：获取所述公证证书。
  11. 根据权利要求8-10任一所述的方法，其特征在于，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
  12. 根据权利要求11所述的方法，其特征在于，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
  13. 根据权利要求8-12任一所述的方法，其特征在于，所述密钥包括对称密钥或非对称密钥。
  14. 根据权利要求13所述的方法，其特征在于，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
  15. 一种检测硬件的装置，其特征在于，所述装置包括：
    发送模块，用于向物理载体发送第一验证数据，所述物理载体上承载有多个硬件；
    接收模块，用于接收所述物理载体返回的密文和绑定关系信息，所述密文是所述多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；
    验证模块，用于对所述密文及所述绑定关系信息进行验证，用于基于验证结果确定所述至少两个硬件的安全性。
  16. 根据权利要求15所述的装置，其特征在于，所述绑定关系信息包括所述至少两个硬件所对应的密钥之间的绑定关系；
    所述验证模块，用于获取所述至少两个硬件所对应的密钥，基于所述至少两个硬件所对应的密钥验证所述绑定关系信息包括的绑定关系是否正确；采用所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；
    当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
  17. 根据权利要求15或16所述的装置，其特征在于，所述接收模块，用于接收所述物理载体返回的密文和公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；
    所述验证模块，用于基于所述公证证书中的数字签名验证所述绑定关系信息包括的绑定关系是否正确；采用所述公证证书中所述至少两个硬件所对应的密钥对所述至少两个硬件加密的密文分别进行解密，验证解密得到的第二验证数据与所述第一验证数据是否一致；
    当验证结果为所述绑定关系信息包括的绑定关系正确，且解密得到的第二验证数据与第一验证数据一致时，确定所述至少两个硬件为安全状态。
  18. 根据权利要求15-17任一所述的装置，其特征在于，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
  19. 根据权利要求18所述的装置，其特征在于，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
  20. 根据权利要求15-19任一所述的装置，其特征在于，所述密钥包括对称密钥或非对称密钥。
  21. 根据权利要求20所述的装置，其特征在于，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；
    所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
  22. 一种检测硬件的装置，其特征在于，所述装置包括：
    接收模块，用于接收验证单元发送的第一验证数据；
    第一获取模块，用于获取密文和绑定关系信息，所述密文是物理载体上承载的多个硬件中的至少两个硬件分别采用各自的密钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息用于指示所述至少两个硬件之间的绑定关系；
    发送模块，用于将所述密文和所述绑定关系信息发送至所述验证单元，由所述验 证单元对所述密文及绑定关系信息进行验证，基于验证结果确定所述至少两个硬件的安全性。
  23. 根据权利要求20所述的装置，其特征在于，所述装置还包括：
    第二获取模块，用于获取所述至少两个硬件的密钥，基于所述至少两个硬件的密钥之间的绑定关系获取所述绑定关系信息；
    存储模块，用于存储所述绑定关系信息。
  24. 根据权利要求23所述的装置，其特征在于，所述第二获取模块，用于注册所述至少两个硬件的密钥，得到公证证书，所述公证证书中包括所述至少两个硬件所对应的密钥之间的绑定关系，还包括所述绑定关系的数字签名；
    所述存储模块，用于存储所述公证证书；
    所述第一获取模块，用于获取所述公证证书。
  25. 根据权利要求22-24任一所述的装置，其特征在于，所述至少两个硬件所对应的密钥由所述至少两个硬件分别基于各自的硬件标识生成。
  26. 根据权利要求25所述的装置，其特征在于，所述硬件标识包括硬件唯一密钥HUK、物理不可克隆函数PUF、机密性受保护的一次性可编程OTP中的标识信息或背书密钥EK。
  27. 根据权利要求22-26任一所述的装置，其特征在于，所述密钥包括对称密钥或非对称密钥。
  28. 根据权利要求27所述的装置，其特征在于，当所述密钥是非对称密钥时，所述密钥包括公钥和私钥；所述密文是所述至少两个硬件分别采用各自的私钥对所述第一验证数据进行加密之后得到的，所述绑定关系信息基于所述至少两个硬件所对应的公钥之间的绑定关系得到。
  29. 一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现权利要求1-7中任一所述的检测硬件的方法，或者实现权利要求8-14中任一所述的检测硬件的方法。
  30. 一种计算机程序产品，其特征在于，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被计算机运行时，使得所述计算机执行权利要求1-7中任一所述的检测硬件的方法，或者执行权利要求8-14中任一所述的检测硬件的方法。
PCT/CN2020/101699 2019-07-24 2020-07-13 检测硬件的方法、装置、设备及存储介质 WO2021012978A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
BR112022001162A BR112022001162A2 (pt) 2019-07-24 2020-07-13 Método e aparelho de detecção de hardware, dispositivo, e meio de armazenamento
EP20843600.6A EP3982610B1 (en) 2019-07-24 2020-07-13 Method, apparatus and device for detecting hardware, and storage medium
JP2021578090A JP7347895B2 (ja) 2019-07-24 2020-07-13 ハードウェア検出方法ならびに装置、デバイス、および記憶媒体
US17/581,212 US12047388B2 (en) 2019-07-24 2022-01-21 Hardware detection method and apparatus, device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910673176.6 2019-07-24
CN201910673176.6A CN112311718B (zh) 2019-07-24 2019-07-24 检测硬件的方法、装置、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/581,212 Continuation US12047388B2 (en) 2019-07-24 2022-01-21 Hardware detection method and apparatus, device, and storage medium

Publications (1)

Publication Number Publication Date
WO2021012978A1 true WO2021012978A1 (zh) 2021-01-28

Family

ID=74192744

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/101699 WO2021012978A1 (zh) 2019-07-24 2020-07-13 检测硬件的方法、装置、设备及存储介质

Country Status (6)

Country Link
US (1) US12047388B2 (zh)
EP (1) EP3982610B1 (zh)
JP (1) JP7347895B2 (zh)
CN (1) CN112311718B (zh)
BR (1) BR112022001162A2 (zh)
WO (1) WO2021012978A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022187089A1 (en) * 2021-03-03 2022-09-09 Rambus Inc. Module authentication
CN116248280A (zh) * 2023-05-09 2023-06-09 北京智芯微电子科技有限公司 免密钥发行的安全模组防盗用方法、安全模组及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11763018B2 (en) * 2021-02-22 2023-09-19 Imperva, Inc. System and method for policy control in databases
CN112804678B (zh) * 2021-04-15 2021-07-20 浙江口碑网络技术有限公司 设备注册、认证及数据传输方法和装置
CN116049826B (zh) * 2022-06-09 2023-10-13 荣耀终端有限公司 基于tpm的数据保护方法、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103136485A (zh) * 2011-11-28 2013-06-05 联想(北京)有限公司 一种实现计算机安全的方法和计算机
CN103200562A (zh) * 2012-01-10 2013-07-10 国民技术股份有限公司 通信终端锁定方法及通信终端
CN104838387A (zh) * 2012-10-11 2015-08-12 爱迪德技术有限公司 芯片验证
CN108234115A (zh) * 2016-12-15 2018-06-29 阿里巴巴集团控股有限公司 信息安全的验证方法、装置和系统
US20180367317A1 (en) * 2015-12-16 2018-12-20 Nagravision S.A. Hardware integrity check

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001082035A2 (en) * 2000-04-26 2001-11-01 Sun Microsystems, Inc. Method and apparatus verifying parts and parts lists in an assembly
US20160358264A1 (en) * 2002-06-03 2016-12-08 Research Affiliates, Llc Equity income index construction transformation system, method and computer program product
US20040199786A1 (en) * 2002-12-02 2004-10-07 Walmsley Simon Robert Randomisation of the location of secret information on each of a series of integrated circuits
US20090319802A1 (en) * 2002-12-02 2009-12-24 Silverbrook Research Pty Ltd Key Genaration In An Integrated Circuit
US20050039016A1 (en) 2003-08-12 2005-02-17 Selim Aissi Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution
CN101464932B (zh) * 2007-12-19 2012-08-22 联想(北京)有限公司 硬件安全单元间协作方法、系统及其应用设备
CN101465732B (zh) * 2007-12-19 2011-04-27 联想(北京)有限公司 保证数字证书安全的方法及保证数字证书安全的终端
US8516269B1 (en) * 2010-07-28 2013-08-20 Sandia Corporation Hardware device to physical structure binding and authentication
US8667265B1 (en) 2010-07-28 2014-03-04 Sandia Corporation Hardware device binding and mutual authentication
CN102063593B (zh) * 2011-01-07 2013-01-09 北京工业大学 主动控制功能的可信设备及其认证方法
EP2506176A1 (en) * 2011-03-30 2012-10-03 Irdeto Corporate B.V. Establishing unique key during chip manufacturing
CN105871867B (zh) * 2016-04-27 2018-01-16 腾讯科技（深圳）有限公司 身份认证方法、系统及设备
US10790978B2 (en) * 2016-05-25 2020-09-29 Intel Corporation Technologies for collective authorization with hierarchical group keys
CN107665308B (zh) * 2016-07-28 2023-04-07 华大半导体有限公司 用于构建和保持可信运行环境的tpcm系统以及相应方法
CN106899410B (zh) * 2016-09-13 2019-06-25 中国移动通信有限公司研究院 一种设备身份认证的方法及装置
CN106529271A (zh) * 2016-10-08 2017-03-22 深圳市金立通信设备有限公司 一种终端及其绑定校验方法
US10164778B2 (en) * 2016-12-15 2018-12-25 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
EP3340216B1 (en) * 2016-12-23 2020-01-29 Secure-IC SAS Secret key generation using a high reliability physically unclonable function
CN110009346A (zh) * 2019-03-11 2019-07-12 巍乾全球技术有限责任公司 用于拆分和恢复密钥的方法、程序产品、存储介质和系统
US11163896B2 (en) * 2019-03-25 2021-11-02 Micron Technology, Inc. Secure communications amongst connected dice

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103136485A (zh) * 2011-11-28 2013-06-05 联想(北京)有限公司 一种实现计算机安全的方法和计算机
CN103200562A (zh) * 2012-01-10 2013-07-10 国民技术股份有限公司 通信终端锁定方法及通信终端
CN104838387A (zh) * 2012-10-11 2015-08-12 爱迪德技术有限公司 芯片验证
US20180367317A1 (en) * 2015-12-16 2018-12-20 Nagravision S.A. Hardware integrity check
CN108234115A (zh) * 2016-12-15 2018-06-29 阿里巴巴集团控股有限公司 信息安全的验证方法、装置和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022187089A1 (en) * 2021-03-03 2022-09-09 Rambus Inc. Module authentication
CN116248280A (zh) * 2023-05-09 2023-06-09 北京智芯微电子科技有限公司 免密钥发行的安全模组防盗用方法、安全模组及装置

Also Published As

Publication number Publication date
EP3982610B1 (en) 2023-09-06
CN112311718B (zh) 2023-08-22
US12047388B2 (en) 2024-07-23
EP3982610A1 (en) 2022-04-13
JP2022541734A (ja) 2022-09-27
EP3982610A4 (en) 2022-08-24
BR112022001162A2 (pt) 2022-03-15
CN112311718A (zh) 2021-02-02
JP7347895B2 (ja) 2023-09-20
US20220150260A1 (en) 2022-05-12

Similar Documents

Publication Publication Date Title
US11921911B2 (en) Peripheral device
WO2021012978A1 (zh) 检测硬件的方法、装置、设备及存储介质
US10447486B2 (en) Remote attestation of a security module's assurance level
DiLuoffo et al. Robot Operating System 2: The need for a holistic security approach to robotic architectures
US10885197B2 (en) Merging multiple compute nodes with trusted platform modules utilizing authentication protocol with active trusted platform module provisioning
Tomlinson Introduction to the TPM
Wang et al. Enabling security-enhanced attestation with Intel SGX for remote terminal and IoT
CN109714168B (zh) 可信远程证明方法、装置和系统
Anati et al. Innovative technology for CPU based attestation and sealing
JP2022545627A (ja) 分散化されたデータ認証
US20050283826A1 (en) Systems and methods for performing secure communications between an authorized computing platform and a hardware component
US11252193B2 (en) Attestation service for enforcing payload security policies in a data center
CN111542820A (zh) 用于可信计算的方法和装置
WO2018112482A1 (en) Method and system for distributing attestation key and certificate in trusted computing
CN111371726B (zh) 安全代码空间的认证方法、装置、存储介质及处理器
Alzomai et al. The mobile phone as a multi OTP device using trusted computing
Khalil et al. TPM-based authentication mechanism for apache hadoop
Kushwah et al. PSec: programming secure distributed systems using enclaves
Fournaris Trust ensuring crisis management hardware module
CN114024702A (zh) 信息安全保护的方法以及计算设备
Sukhomlinov et al. Supply Chain Verification of Hardware Components Using Open-Source Root of Trust
Κασαγιάννης Security evaluation of Android Keystore
Denzel Malware tolerance: Distributing trust over multiple devices
CN110059489A (zh) 安全电子设备
Abdulrazak et al. MOBILE PROVISIONING INFRASTRUCTURE FOR TRUSTED COMPUTING

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20843600

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021578090

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020843600

Country of ref document: EP

Effective date: 20220104

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112022001162

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112022001162

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20220121