Dual authentication methods, equipment, and media based on TPM Quote and HMAC responses

Abstract

The application provides a dual authentication method based on TPM Quote and HMAC response, equipment and medium, the method comprises the following steps: receiving the device end sends the device end random number and device identification; according to the service end private key, the service end random number and device identification generated randomly by the service end are signed, and the service end signature is obtained; the service end random number and the service end signature are sent to the device end; receiving the TPM Quote data and the HMAC response value returned by the device end; the TPM Quote data and the HMAC response value are verified, if the verification result is verified, a session key is generated; the session key is encrypted according to the device encryption public key, and the first encryption key is obtained; the first encryption key is sent to the device end to establish a secure channel. By constructing the dual authentication system of TPM Quote and HMAC response, the security of device authentication can be improved.

Description

Technical Field

[0001] This application relates to the field of device authentication technology, and in particular to a dual authentication method, device and medium based on TPM Quote and HMAC response. Background Technology

[0002] In distributed systems, devices must undergo authentication before accessing the network to ensure communication security. Currently, although remote authentication technology based on trusted platform modules is used to verify device software status, combined with key management mechanisms for encrypted communication, insufficient authentication security still exists in practical deployments: software status verification and key verification are independent, and a breach in a single step can lead to overall authentication failure; session keys are at risk of leakage during transmission; furthermore, replay attack protection mechanisms are still inadequate in complex network environments.

[0003] Therefore, improving the security of device certification is an urgent issue that needs to be addressed. Summary of the Invention

[0004] This application provides a dual authentication method, device, and medium based on TPM Quote and HMAC response. By combining hardware integrity verification with key identity verification, a dual authentication system is constructed. Combined with mechanisms such as dynamic random numbers and asymmetric encryption transmission session keys, the security of device authentication is improved.

[0005] In a first aspect, embodiments of this application provide a dual authentication method based on TPM Quote and HMAC response, applied to the server side, the method comprising: The receiving device sends a device-side random number and a device identifier; Based on the preset server private key, the server-generated random number and the device identifier are signed to obtain the server signature; Send the server-side random number and the server-side signature to the device. The device receives TPM Quote data and HMAC response value returned by the device. The TPM Quote data is generated and signed by the device based on the device's random number and the server's random number. The HMAC response value is calculated by the device using the target encryption key on the device's random number, the server's random number, and the TPM Quote data. The TPM Quote data and the HMAC response value are verified to obtain the target verification result; If the target verification result is successful, a session key is generated; The session key is encrypted using the device encryption public key corresponding to the device to obtain the first encryption key; The first encryption key is sent to the device to establish a secure channel between the server and the device.

[0006] Secondly, embodiments of this application provide a dual authentication method based on TPM Quote and HMAC response, applied to the device side, the method comprising: Send the randomly generated device number and the device identifier corresponding to the device to the server. Receive the server-side random number and server-side signature returned by the server, and determine whether the server-side random number and server-side signature meet the preset verification conditions; If the server-side random number and the server-side signature meet the preset verification conditions, then TPMQuote data and HMAC response value are generated; The TPM Quote data and the HMAC response value are sent to the server. After both the TPM Quote data and the HMAC response value are verified, the first encryption key sent by the server is received. The first encryption key is decrypted using the device encryption private key corresponding to the device to obtain the session key; A secure channel is established between the server and the device based on the session key.

[0007] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0010] As can be seen, this application's embodiment adopts a dual authentication architecture. On one hand, the TPM Quote data is bound to bidirectional random numbers from both the device and server sides and signed, which verifies that the device's hardware status has not been tampered with and prevents authentication data from being intercepted and replayed. On the other hand, the HMAC response value is generated by jointly operating multiple sets of data using a dedicated key, which can accurately verify whether the device holds a legitimate key and resist unauthorized device impersonation access. Simultaneously, asymmetric encryption of the session key further mitigates the risk of session key hijacking and leakage. In summary, this application's embodiment establishes a multi-dimensional security protection system through layered verification, dynamic data binding, and end-to-end encrypted transmission, effectively improving the anti-attack capability and overall security level of device access authentication. Attached Figure Description

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

[0012] Figure 1 This is a system architecture diagram of a device authentication system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a secure channel between a server and a device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a dual authentication method based on TPM Quote and HMAC response provided in an embodiment of this application. Figure 5 This is a schematic diagram of a process for determining a fourth verification result provided in an embodiment of this application; Figure 6 This is a flowchart illustrating another dual authentication method based on TPM Quote and HMAC response provided in this application embodiment; Figure 7 This is a block diagram of the functional modules of a dual authentication device based on TPM Quote and HMAC response provided in an embodiment of this application; Figure 8 This is a block diagram of the functional modules of another dual authentication device based on TPM Quote and HMAC response provided in this application embodiment. Detailed Implementation

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

[0014] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0015] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0016] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0017] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

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

[0019] The following is an explanation of the relevant terms used in this application: TPM Quote: Platform state proof data generated by the Trusted Platform Module (TPM) includes a summary of the current value of the specified Platform Configuration Register (PCR) and external data provided by the caller (such as the hash value of the session random number), and is digitally signed by the authentication key inside the TPM. The server can verify the signature and PCR value to confirm that the current trusted boot state of the device has not been tampered with.

[0020] Hash-based Message Authentication Code (HMAC): This refers to an authentication code calculated using the HMAC-SHA256 algorithm. The target encryption key unsealed from the TPM on the device is used as the symmetric key. The code is calculated from input data such as random numbers on the device, random numbers on the server, and the target hash value in the TPM Quote. The server verifies whether the device holds a valid target encryption key and whether the current platform status meets the TPM unsealing conditions by recalculating and comparing the HMAC value.

[0021] In distributed systems, devices must undergo authentication before accessing the network to ensure communication security. Currently, although remote authentication technology based on trusted platform modules is used to verify device software status, combined with key management mechanisms for encrypted communication, insufficient authentication security still exists in practical deployments: software status verification and key verification are independent, and a breach in a single step can lead to overall authentication failure; session keys are at risk of leakage during transmission; furthermore, replay attack protection mechanisms are still inadequate in complex network environments.

[0022] Therefore, improving the security of device certification is an urgent issue that needs to be addressed.

[0023] To address the aforementioned issues, this application provides a dual authentication method, device, and medium based on TPM Quote and HMAC response. First, the device receives a random number and device identifier sent by the device itself. Then, based on a preset server private key, the server-generated random number and the device identifier are signed to obtain a server signature. Next, the server random number and the server signature are sent to the device. Finally, the device returns TPM Quote data and an HMAC response value. The TPM Quote data is generated and signed by the device based on the device random number and the server random number. The HMAC response value is obtained by the device using a target encryption key to verify the device random number, the server random number, and the TPM Quote response. Quote data is calculated; then, the TPMQuote data and the HMAC response value are verified to obtain the target verification result; if the target verification result is successful, a session key is generated; the session key is encrypted according to the device encryption public key corresponding to the device to obtain a first encryption key; the first encryption key is sent to the device to establish a secure channel between the server and the device.

[0024] As can be seen, by adopting a dual authentication architecture, on the one hand, TPM Quote data is bound to bidirectional random numbers from both the device and server sides and signed, which verifies that the device hardware status has not been tampered with and prevents authentication data from being intercepted and replayed. On the other hand, the HMAC response value is generated by jointly operating multiple sets of data using a dedicated key, which can accurately verify whether the device holds a legitimate key and resist unauthorized device impersonation. Meanwhile, asymmetric encryption of the session key further mitigates the risk of session key hijacking and leakage. In this multi-dimensional security protection system, built through layered verification, dynamic data binding, and end-to-end encrypted transmission, the anti-attack capability and overall security level of device access authentication can be effectively improved.

[0025] For easier understanding, please refer to Figure 1 , Figure 1This is a system architecture diagram of a device authentication system provided in an embodiment of this application. The device authentication system includes a server and a device. The device is a connector device (such as an IoT gateway, industrial controller, etc.) embedded with a Trusted Platform Module (TPM), which includes a TPM chip, firmware storage unit, random number generator, and secure storage area. It is used to generate device-side random numbers, call the TPM to generate TPM Quote data, decrypt the target encryption key (KEK), and calculate the HMAC response value. The server is an authentication server deployed on a cloud platform or enterprise data center, which includes a device registration library, a blacklist management module, a session key generation module, a signature verification module, and a PCR benchmark value calculation unit. It is used to verify device signatures, verify PCR status, verify HMAC responses, and distribute session keys. The device and the server communicate bidirectionally through a secure transport layer. During the registration phase, they exchange device certificates and server public keys. During the authentication phase, they exchange random numbers, signatures, TPM Quote data, HMAC response values, and encrypted session keys, and finally establish a secure data channel based on the session key.

[0026] It is evident that this device authentication system, through a dual verification mechanism of TPM Quote and HMAC response, enables remote verification of device identity and platform trustworthiness, thereby improving the security of device authentication.

[0027] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of a secure channel between a server and a device, provided in an embodiment of this application. The server and device complete identity and integrity verification through device registration and two-way authentication processes, and after negotiating a session key, establish a secure channel based on that session key. Subsequent business data interactions between the server and device can be encrypted and transmitted through this secure channel, effectively preventing data eavesdropping, tampering, or hijacking, and ensuring secure and reliable communication throughout the entire process.

[0028] The following is combined Figure 3 The electronic devices in the embodiments of this application will be described. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 3 As shown, the electronic device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface via an internal communication bus.

[0029] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0030] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0031] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0032] It is understood that the electronic device may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that the electronic device may incorporate elements such as... Figure 1 The system architecture described above.

[0033] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 4 This application describes a dual authentication method based on TPMQuote and HMAC responses in its embodiments. Figure 4 This is a flowchart illustrating a dual authentication method based on TPMQuote and HMAC responses, provided in an embodiment of this application. Applied to the server side, it specifically includes the following steps: Step S11: Receive the device random number and device identifier sent by the device.

[0034] Specifically, the server can receive a random number (e.g., 32 bytes) and a device identifier sent by the device in JSON or TLV format through a preset API interface. First, the server performs format validation and length checks on the random number and device identifier. Then, it queries the local registry based on the device identifier to confirm that the device is registered and not disabled. If the validation fails, it returns an error and records an audit log.

[0035] Before the device-side random number and device identifier sent by the receiving device, the method further includes the following steps: S111. During the device registration phase, receive device registration information sent by the device; the device registration information includes the device identifier, device signature public key, firmware hash value and device registration signature. S112. If the device identifier is not in the preset device blacklist and the validity of the device signature public key is verified, then the device registration signature is verified based on the device signature public key, the device identifier and the firmware hash value. S113. If the device registration signature verification passes, a device certificate is generated based on the device identifier, the device signature public key, and the certificate validity period. S114. Send the server public key corresponding to the server private key and the device certificate to the device.

[0036] In a specific embodiment, during the device registration phase, the server receives device registration information sent by the device through a pre-deployed registration interface. This device registration information includes at least a device identifier, a device signature public key, a firmware hash value, and a device registration signature, without specific limitations. The device identifier is a unique identifier for the device and can be a device serial number, MAC address, or a universally unique identifier. The device signature public key is the public key portion of an asymmetric key pair generated by the device and is used for subsequent verification of the device registration signature. The firmware hash value is a digest value obtained by the device performing SHA-256 calculation on its own firmware (e.g., bootloader, operating system kernel, application image). The device registration signature is a digital signature calculated by the device using its device signature private key corresponding to the device signature public key, concatenating the device identifier, device signature public key, and firmware hash value. After receiving the above information, the server first performs a format validity check, including whether the fields are complete, whether the device identifier length is compliant, whether the device signature public key is a valid encoding, whether the hash value is a 64-bit hexadecimal string, and whether the signature length meets the algorithm requirements. If the format verification fails, the server directly returns an error response and terminates the registration process.

[0037] Then, using the received device identifier as an index, the server queries the locally maintained device blacklist. This blacklist records device identifiers that have been revoked, compromised, or are obsolete. If the query result indicates that the device identifier exists in the blacklist, the server rejects the registration request, records the audit log, and returns a failure response. If the device identifier is not in the blacklist, the server continues to verify the validity of the device signature public key. The specific method of validity verification is as follows: the server uses a pre-installed root certificate or device vendor certificate chain to verify whether the certificate chain corresponding to the device signature public key is complete and valid (e.g., checking the certificate signature, validity period, and revocation status). Once the validity verification of the device signature public key is successful, the server uses the device signature public key to verify the device registration signature. During verification, the server concatenates the device identifier, device signature public key, and firmware hash value sequentially into the data to be verified, following the same concatenation order as the device, and then calls a signature verification algorithm (such as RSA-PSS-SHA256 or ECDSA-SHA256) to verify the device registration signature. If the signature verification fails, it means that the device registration information has been tampered with or the device identity is untrusted. The server will refuse to register and record the security log.

[0038] If the device registration signature verification passes, the server confirms that the device identifier, device signature public key, and firmware hash value have a correct binding relationship, and that the device possesses the device signature private key corresponding to the device signature public key. Then, the server generates a device certificate for the device, which includes the device identifier, device signature public key, and certificate validity period (including effective and expiration times). The certificate validity period can be set to short-term (e.g., 24 hours) or long-term (e.g., one year) according to a preset security policy. Short-term certificates require frequent device re-registration but offer higher security. After generating the certificate, the server associates the certificate serial number with the device identifier and stores it in a local database for quick lookup during subsequent authentication. Finally, the server sends the server's public key corresponding to its private key and the device certificate to the device.

[0039] As can be seen, the signature verification, blacklist check and certificate issuance mechanism during device registration achieves a reliable binding between device identity and firmware hash, effectively preventing device forgery, identity impersonation and firmware tampering, and facilitating subsequent dual authentication.

[0040] Step S12: Sign the server-generated random number and the device identifier according to the preset server private key to obtain the server signature.

[0041] Specifically, first, a server-side random number (e.g., 32 bytes) is generated by calling a preset random number generator. Then, the server-side random number and the device identifier are concatenated byte by byte in sequence. The concatenated data is digitally signed using a preset server-side private key (e.g., RSA-2048 or ECDSA P-256 private key) and the SHA-256 hash algorithm, and finally, the server-side signature is obtained.

[0042] Step S13: Send the server-side random number and the server-side signature to the device.

[0043] Specifically, the server encapsulates the server-side random number and the calculated server-side signature according to a preset data format (such as JSON or CBOR). The server-side random number is represented by Base64 encoding or raw hexadecimal string, and the server-side signature is also Base64 encoded for easy text transmission. The server can send the encapsulated message to the device via an HTTPS POST response or a preset encrypted channel.

[0044] Step S14: Receive the TPM Quote data and HMAC response value returned by the device.

[0045] The TPM Quote data is generated and signed by the device based on the device's random number and the server's random number; the HMAC response value is calculated by the device using the target encryption key on the device's random number, the server's random number, and the TPM Quote data.

[0046] Step S15: Verify the TPM Quote data and the HMAC response value to obtain the target verification result.

[0047] The TPM Quote data includes a target hash value, authentication data, and a target signature. The specific steps for verifying the TPM Quote data and the HMAC response value to obtain the target verification result include: Step S121: Verify the target signature based on the device signature public key to obtain a first verification result; Step S122: Obtain a preset first PCR value; the first PCR value is calculated based on the firmware hash value and a preset standard metric sequence; Step S123: Extract the second PCR value from the authentication data, and compare the first PCR value with the second PCR value to obtain the second verification result; Step S124: Determine a reference hash value based on the device-side random number and the server-side random number; Step S125: Compare the reference hash value with the target hash value to obtain a third verification result; Step S126: Verify the HMAC response value to obtain the fourth verification result; Step S127: If the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified successfully, then the target verification result is determined to be verified successfully.

[0048] In a specific embodiment, the server extracts the target signature from the TPM Quote data and verifies the target signature using the locally stored device signature public key corresponding to the device identifier (i.e., the device signature public key obtained during the registration phase). During verification, the server first parses the authentication data from the TPM Quote data, then uses the authentication data as the original message to be verified, and calls the corresponding signature verification algorithm (e.g., RSA-PSS-SHA256 or ECDSA-SHA256) on the device side, using the target signature and the device signature public key as inputs for the signature verification operation. The authentication data includes, but is not limited to: structure type, clock information, binding information (i.e., the target hash value to prevent replay attacks), and the second PCR value (i.e., the PCR value corresponding to the PCR register information), which are not specifically limited here. If the signature verification passes, it indicates that the TPM Quote data was indeed signed by the device's device signature private key (e.g., the AIK private key) and has not been tampered with during transmission; in this case, the first verification result is recorded as "verification passed"; otherwise, it is recorded as "verification failed," and subsequent verification is terminated.

[0049] During the registration phase, the server stores the firmware hash value from the device. Based on the standard metric order of the trusted boot chain (e.g., UEFI firmware, bootloader, kernel image, etc., sequentially expanding to PCR0~PCR7), the server uses the TPM simulation library to recursively derive the expected values ​​of each PCR register according to a preset expansion algorithm. The server then determines the specific PCR index to be compared based on the PCR selection mask chosen for this verification and records the corresponding expected PCR value as the first PCR value.

[0050] The server extracts the second PCR value from the authentication data in the TPM Quote data. In TPM 2.0, this authentication data includes a pcrDigest field, which is the aggregated hash value of the PCR register selected by the device's TPM. The server uses this as the second PCR value. Subsequently, the server compares the first PCR value and the second PCR value byte by byte. If they are completely identical, it means that the device's current PCR state matches the server's expected trusted state, the device firmware has not been tampered with or rolled back, and the second verification result is recorded as "verification passed"; otherwise, it is recorded as "verification failed," and subsequent verification is terminated.

[0051] The server concatenates bytes using random numbers from both the device and server sides, following the same concatenation order as the device. Then, it uses the SHA-256 hash function to calculate a 32-byte hash value, resulting in a reference hash value. This reference hash value is then compared to the target hash value to obtain the third verification result. If they are identical, it proves that the TPMQuote data was generated for the current session and has not been replayed to other sessions; the third verification result is recorded as "verification passed." Otherwise, it is recorded as "verification failed," and subsequent verification is terminated.

[0052] The server verifies the HMAC response value to obtain a fourth verification result, which includes "verification passed" and "verification failed". If the first, second, third, and fourth verification results are all "verification passed", the target verification result is determined to be successful, and the server continues to execute subsequent steps such as session key generation and encrypted transmission. If any verification result is "verification failed", the target verification result is determined to be a verification failure, the server rejects this authentication request, records detailed audit logs (including failure reason, device identifier, timestamp, etc.), and may choose to return a general error code to the device to prevent information leakage.

[0053] As can be seen, through multi-level verification, triple protection is achieved for the authenticity of device identity, the integrity of the platform startup chain, and the consistency of session binding, which significantly improves the security of the authentication process.

[0054] For easier understanding, please refer to Figure 5 , Figure 5 This is a flowchart illustrating a method for determining a fourth verification result according to an embodiment of this application. The specific steps for verifying the HMAC response value to obtain the fourth verification result include: Step S131: Concatenate the device-side random number, the server-side random number, and the target hash value to obtain HMAC input data; Step S132: Obtain the corresponding target encryption key from the device, and calculate the HMAC input data based on the target encryption key to obtain the HMAC reference value; Step S133: Compare the HMAC reference value with the HMAC response value to obtain the fourth verification result.

[0055] In a specific embodiment, the server concatenates the device-side random number, the server-side random number, and the target hash value in the same concatenation order as the device-side data to obtain the HMAC input data. The server then queries the local security database for the target encryption key (e.g., KEK) corresponding to the device based on its device identifier. The server invokes the HMAC-SHA256 algorithm, using the target encryption key as the HMAC key and the HMAC input data as the message content, to calculate a 32-byte HMAC reference value. The HMAC reference value is then compared with the HMAC response value to obtain the fourth verification result. If they are completely equal, the fourth verification result is recorded as "verification passed," indicating that the device holds the correct KEK and its current PCR status meets the KEK unblocking conditions, thus proving the authenticity of the device identity and the trustworthiness of the platform status. If they are not equal, the fourth verification result is recorded as "verification failed," and the server immediately terminates the authentication process and records an audit log (including the device identifier, failure reason, and timestamp).

[0056] As can be seen, by binding the device-side random number, the server-side random number, and the target hash value, and calculating the HMAC reference value based on the device's unique target encryption key and then comparing them, efficient verification of the device's possession of a legitimate key and the trustworthiness of the current platform status is achieved, effectively preventing replay and forgery attacks.

[0057] Step S16: If the target verification result is successful, then a session key is generated.

[0058] Specifically, the server can call a preset random number generator to generate a 32-byte (256-bit) random number as the session key. This session key is a symmetric key, used for subsequent encrypted communication between the server and the device (e.g., using the AES-256-GCM algorithm).

[0059] Step S17: Encrypt the session key according to the device encryption public key corresponding to the device to obtain the first encryption key.

[0060] Specifically, the server retrieves the device encryption public key provided during device registration from the local database based on the device identifier. The server then uses this device encryption public key, combined with an encryption algorithm agreed upon with the device (such as RSA-OAEP or ECIES), to encrypt the session key (a 32-byte symmetric key) to obtain the first encryption key.

[0061] Step S18: Send the first encryption key to the device to establish a secure channel between the server and the device.

[0062] Specifically, the server can encapsulate the first encryption key (i.e., the encrypted session key ciphertext) into a response message, typically in JSON or CBOR format, containing a session identifier, the first encryption key (Base64 encoded), and an optional timestamp. The server then sends this first encryption key to the device via an HTTPS response or a pre-defined secure channel. Upon receiving it, the device uses its internal TPM-stored device encryption private key to decrypt and obtain the plaintext session key. Subsequently, both the server and the device use this session key as a symmetric key (such as AES-256-GCM) to encrypt and protect subsequent communication data, thereby establishing a two-way secure channel.

[0063] It is evident that by securely distributing session keys through asymmetric encryption and establishing an efficient two-way secure channel in conjunction with symmetric encryption, confidentiality and identity binding during the key distribution process are guaranteed, while high-performance data encryption protection is provided for subsequent communications.

[0064] For easier understanding, please refer to Figure 6 , Figure 6 This is a flowchart illustrating another dual authentication method based on TPM Quote and HMAC response provided in this application embodiment, applied to the device side, specifically including the following steps: Step S21: Send the randomly generated device number and the corresponding device identifier to the server.

[0065] Before sending the randomly generated device number and the corresponding device identifier to the server, the method further includes the following steps: S211. During the device registration phase, obtain the device identifier, device signature public key and firmware hash value corresponding to the device. S212. Sign the device identifier, the device signature public key and the firmware hash value according to the device signature private key corresponding to the device signature public key to obtain the device registration signature; S213. Send device registration information to the server. The device registration information includes the device identifier, the device signature public key, the firmware hash value, and the device registration signature. S214. Receive and store the device certificate and server public key returned by the server to complete the registration of the device.

[0066] In a specific embodiment, during the device registration phase, the device first obtains its own device identifier, device signature public key, and firmware hash value. The device identifier can be the device's unique serial number, MAC address, or UUID generated by the TPM, which the device reads from non-volatile memory or is pre-configured by the manufacturer. The device signature public key is the public key portion of an RSA-2048 or ECC P-256 key pair generated by the device, with the private key portion securely stored on the device (e.g., within the TPM). The firmware hash value is calculated by the device using the SHA-256 algorithm on the currently running firmware (including the bootloader, operating system kernel, and critical system images), ensuring that the server can verify device integrity subsequently.

[0067] The device constructs the data to be signed according to a preset concatenation order (e.g., the order of device identifier, device signing public key, and firmware hash value), and then calls a preset cryptographic library (such as the signature interface of OpenSSL or TPM) to perform the signing operation. The signing algorithm uses RSA-PSS-SHA256 or ECDSA-SHA256. The calculated signature result is the device registration signature, used to prove to the server the binding relationship between the device identifier, public key, and firmware hash and that it has not been tampered with. Then, the device encapsulates the device identifier, device signing public key, firmware hash value, and device registration signature into device registration information and sends it to the server through a pre-configured server registration interface. The device waits for the server's registration response. If the server verifies the registration, it returns the device certificate and server public key (or provides them in the form of a server certificate). After receiving the device certificate and server public key, the device first verifies the integrity of the server's response message (e.g., verifies the server signature), and then extracts and stores the device certificate and server public key from the response message to complete the device registration.

[0068] As can be seen, by generating a registration signature containing the device identifier, signing public key, and firmware hash value on the device side and sending it to the server, the server can verify the binding relationship between the device identity and firmware integrity, thereby establishing a trusted device registration benchmark for subsequent two-way authentication and effectively preventing identity forgery and firmware tampering.

[0069] Step S22: Receive the server-side random number and server-side signature returned by the server, and determine whether the server-side random number and the server-side signature meet the preset verification conditions.

[0070] The specific steps for determining whether the server-side random number and the server-side signature meet the preset verification conditions include: S221. Verify the server signature based on the server public key, the server random number, and the device identifier to obtain a signature verification result; S222. Obtain the local historical records corresponding to the device. S223. Check if the server-side random number exists in the local historical records to obtain the random number verification result; S224. When the signature verification result is successful and the random number verification result is non-existent, it is determined that the preset verification condition is met.

[0071] In a specific embodiment, the device concatenates the server's random number and device identifier byte-wise in the same order as when the server generates the signature, to obtain the message to be verified. Then, it calls the signature verification algorithm, using the server's public key, the message to be verified, and the server's signature as inputs to perform the signature verification operation. If the signature verification passes, it means that the server signature was indeed generated by a legitimate server holding the server's private key, and that the server's random number and device identifier were not tampered with during transmission. The signature verification result is recorded as "verification passed"; otherwise, it is recorded as "verification failed".

[0072] The device then reads the local history from local secure storage (such as TPM non-volatile memory or encrypted persistent files). This local history is used to store all server-side random numbers received before this session, for subsequent checks to prevent replay attacks. Each entry in the local history can have an expiration time (e.g., 10 minutes), after which it is automatically deleted. The device then compares the server-side random number with each random number in the local history. If a record with the exact same server-side random number already exists in the local history, it indicates that the random number was used in a previous authentication session, potentially indicating a replay attack; the result is recorded as "exists." If the server-side random number does not exist in the local history, it is recorded as "does not exist."

[0073] Next, when the signature verification result is "verification passed" and the random number verification result is "not found", the device determines that the server random number and server signature meet the preset verification conditions and can continue to execute the subsequent TPM Quote data generation and HMAC response value calculation. If either condition is not met (e.g., signature verification fails, or the random number already exists), it is determined that the preset verification conditions are not met, and the device should immediately terminate this authentication process, discard the received server random number and server signature, and record the security audit log (including the reason for failure, timestamp, and device identifier).

[0074] As can be seen, by verifying the server's signature to ensure the authenticity of the server's identity, and by checking the uniqueness of the random number in conjunction with local historical records to prevent replay attacks, reliable authentication of the server by the device is achieved, laying a foundation of mutual trust for the subsequent establishment of a two-way secure channel.

[0075] Step S23: If the server-side random number and the server-side signature meet the preset verification conditions, then generate TPM Quote data and HMAC response value.

[0076] The specific steps for generating TPM Quote data and HMAC response values ​​include: S231. Concatenate the random number from the device and the random number from the server to obtain a reference random number; S232. Calculate the hash value corresponding to the reference random number to obtain the target hash value; S233. Obtain the PCR register information corresponding to the device. S234. Call the trusted platform module corresponding to the device, input the target hash value, PCR register information and the device signature private key into the trusted platform module, and output authentication data and target signature; the authentication data at least includes the PCR value corresponding to the PCR register information; the target signature is the signature of the authentication data by the trusted platform module based on the device signature private key. S235. Determine the TPM Quote data based on the target hash value, the authentication data, and the target signature; S236. Obtain the target encryption key corresponding to the device from the trusted platform module; S237. Determine the HMAC input data based on the device-side random number, the server-side random number, and the target hash value; S238. Calculate the HMAC input data according to the target encryption key to obtain the HMAC response value.

[0077] In a specific embodiment, the device concatenates a random number from both the device and the server according to a preset concatenation order (consistent with the order used by the server in subsequent verification) to obtain a reference random number. Then, the SHA-256 hash function is called to calculate the target hash value from the reference random number. Next, the device obtains the corresponding PCR register information (i.e., the PCR selection mask) to specify the PCR registers to be read in this TPM Quote. The PCR register set includes PCR0 to PCR7, corresponding to different stages in the system boot chain (such as BIOS, UEFI, bootloader, operating system kernel, etc.). The device can read the PCR register information from its local configuration or TPM context, for example, selecting PCR0, PCR2, PCR4, etc., with the specific values ​​consistent with the PCR set expected by the server.

[0078] Next, the device invokes the TPM2_Quote command of the Trusted Platform Module (TPM chip) to input the target hash value and PCR register information into the TPM. Internally, the TPM reads the actual value of the currently specified PCR register to construct authentication data, and then signs the authentication data using the device's signature private key, outputting the authentication data and the target signature. The authentication data includes, but is not limited to: structure type, clock information, binding information (i.e., the target hash value, to prevent replay attacks), and a second PCR value (i.e., the PCR value corresponding to the PCR register information), which are not specifically limited here. This authentication data can be used by the server to verify the platform status; the target signature is used to prove that the authentication data was generated by a legitimate TPM. Then, the device combines the target hash value, authentication data, and target signature according to a preset data structure to form the TPM Quote data.

[0079] Then, the device invokes the TPM's desealing command to deseale the pre-sealed target encryption key (KEK) from the TPM. The desealing operation requires that the current PCR state exactly match the PCR value bound when sealing the KEK; if the current system boot chain has not been tampered with (i.e., the current PCR value matches the PCR value at the time of sealing), the TPM releases the KEK to the device; otherwise, desealing fails. The device obtains the KEK as the target encryption key, which is a symmetric key (e.g., AES-256) for subsequent HMAC calculation. If desealing fails, the device immediately terminates the authentication process and logs an error. Next, the device concatenates the device-side random number, the server-side random number, and the target hash value byte-wise to obtain the HMAC input data. The device uses the target encryption key (KEK) as the HMAC key and calls the HMAC-SHA256 algorithm to calculate the HMAC response value. The HMAC response value is used to indicate that the device holds the correct KEK and the current PCR status meets the unblocking conditions. At the same time, it binds the complete session information (i.e., the device random number, the server random number, and the target hash value) together to complete two-way authentication.

[0080] As can be seen, by generating TPM Quote data and HMAC response values, dual hardware-level proof of platform trust status and device identity is achieved, providing the server with an unforgeable authentication basis.

[0081] Step S24: Send the TPM Quote data and the HMAC response value to the server.

[0082] Specifically, the device encapsulates the generated TPM Quote data (including the target hash value, authentication data, and target signature) and HMAC response value in a preset JSON format. Each binary field is converted to Base64 encoding and then sent to the server's authentication interface via an HTTPS POST request, with a timeout timer set. If the transmission fails, a limited number of retransmissions are performed according to the preset retry policy. If no response is received after the timeout, the authentication is terminated and logged.

[0083] Step S25: After both the TPM Quote data and the HMAC response value are verified, the first encryption key issued by the server is received.

[0084] Specifically, if the server verifies both the TPM Quote data and the HMAC response value, it returns a response message containing the first encryption key. Upon receiving the response message, the device first checks if its status field is successful and verifies if the session identifier matches the current authentication session. If the verification passes, the device extracts the first encryption key field from the response and stores it temporarily. If the response times out (e.g., not received within 30 seconds), the status field is failed, or the format is incorrect, the device determines that the authentication has failed and records it in the audit log.

[0085] Step S26: Decrypt the first encryption key according to the device encryption private key corresponding to the device to obtain the session key.

[0086] Specifically, the device reads the device encryption private key corresponding to the device encryption public key reported during registration from a secure storage area (such as the non-volatile memory of the TPM). The device decrypts the first encryption key using the device encryption private key to obtain the session key. If decryption fails (e.g., key mismatch or ciphertext corruption), the device terminates the authentication process and records an error log; if decryption succeeds, the obtained session key is temporarily stored in memory for subsequent establishment of a secure channel.

[0087] Step S27: Establish a secure channel between the server and the device based on the session key.

[0088] Specifically, the device uses this session key as the root key for symmetric encryption and negotiates the encryption algorithm (e.g., AES-256-GCM) and session parameters (e.g., initialization vector generation method, key update cycle) with the server. Then, the device uses this session key to encrypt a pre-set confirmation message and sends it to the server. Successful decryption by the server indicates that a secure channel has been established. Afterward, all business data between the device and server (e.g., configuration distribution, status reporting, etc.) is transmitted using this session key with encryption. Simultaneously, the device enables session timeout management (e.g., 10 minutes of inactivity or a 24-hour validity period). Upon timeout, the session key is automatically destroyed and re-authentication is triggered, thus ensuring the confidentiality and integrity of communication.

[0089] In one possible embodiment, the device and server maintain their respective time sources (such as NTP synchronization). During the two-way authentication process, when the server generates a server-side random number, it also attaches its current server-side timestamp. Upon receiving this, the device first checks if the absolute difference between its current time and the server-side timestamp is less than a preset threshold (e.g., 5 minutes). If the clock deviation exceeds 5 minutes, the device rejects the authentication and returns a time synchronization error, requiring the device to recalibrate its time. Simultaneously, the server sets an expiration time (e.g., 10 minutes) for the generated server-side random number and caches this expiration time along with the random number. When the server subsequently receives TPM Quote data and HMAC response values ​​from the device, it checks if the current time exceeds the sum of the server-side random number's generation time and expiration time. If a timeout occurs, the authentication request is rejected and logged. The device also checks the validity of the received server-side random number to ensure its generation time is within a reasonable window. Therefore, this two-way time verification can prevent replay attacks and delay attacks.

[0090] In one possible implementation, the device maintains a monotonically increasing authentication counter in the non-volatile storage area of ​​the TPM. Each time the device initiates a complete two-way authentication process (i.e., before generating TPM Quote data), it increments the authentication counter by 1 and sends this current counter value as part of the authentication request (e.g., included in an extended field of the device's random number, or as additional input to the TPM Quote data) to the server. The server queries its local records for the last successfully authenticated historical counter value based on the device identifier. Upon receiving the authentication request, the server verifies not only the TPM Quote data and the HMAC response value but also checks whether the current counter value reported by the device is strictly greater than the previously stored historical counter value. If the current counter value is not greater than the historical counter value, it indicates a possible replay or rollback attack; the server rejects authentication and marks the device as abnormal. If the verification passes, the server updates the current counter value to the database. Simultaneously, the device-side TPM must ensure that the counter value can only increment (achieved through the TPM's monotonically increasing counter function) to prevent device tampering.

[0091] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0092] This application embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0093] When dividing each function into modules according to its corresponding function. Figure 7 This is a functional module block diagram of a dual authentication device based on TPM Quote and HMAC response provided in an embodiment of this application, applied to a server. The dual authentication device 700 based on TPM Quote and HMAC response includes: The first receiving module 710 is used to receive a device-side random number and a device identifier sent by the device. The first signature module 720 is used to sign the server random number randomly generated by the server and the device identifier according to the preset server private key to obtain the server signature; The first sending module 730 is used to send the server-side random number and the server-side signature to the device. The second receiving module 740 is further configured to receive TPM Quote data and HMAC response value returned by the device; the TPM Quote data is generated and signed by the device based on the device's random number and the server's random number; the HMAC response value is calculated by the device using the target encryption key on the device's random number, the server's random number, and the TPM Quote data; The first verification module 750 is used to verify the TPM Quote data and the HMAC response value to obtain the target verification result; The first generation module 760 is used to generate a session key if the target verification result is successful. The first encryption module 770 is used to encrypt the session key according to the device encryption public key corresponding to the device end to obtain the first encryption key; The second sending module 780 is used to send the first encryption key to the device to establish a secure channel between the server and the device.

[0094] Optionally, before the device-side random number and device identifier sent by the receiving device, the dual authentication device 700 based on TPMQuote and HMAC response is specifically used for: During the device registration phase, the device registration information sent by the device is received; the device registration information includes the device identifier, the device signature public key, the firmware hash value, and the device registration signature. If the device identifier is not in the preset device blacklist and the validity of the device signature public key is verified, then the device registration signature is verified based on the device signature public key, the device identifier, and the firmware hash value. If the device registration signature verification passes, a device certificate is generated based on the device identifier, the device signature public key, and the certificate validity period. Send the server public key corresponding to the server private key and the device certificate to the device.

[0095] Optionally, the TPM Quote data includes a target hash value, authentication data, and a target signature. Regarding the verification of the TPM Quote data and the HMAC response value to obtain the target verification result, the first verification module 750 is specifically used for: The target signature is verified using the device signature public key to obtain a first verification result; Obtain a preset first PCR value; the first PCR value is calculated based on the firmware hash value and a preset standard metric sequence. The second PCR value is extracted from the authentication data, and the first PCR value is compared with the second PCR value to obtain the second verification result; A reference hash value is determined based on the device-side random number and the server-side random number. The reference hash value is compared with the target hash value to obtain the third verification result; The HMAC response value was verified to obtain the fourth verification result; If the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified successfully, then the target verification result is determined to be verified successfully.

[0096] Optionally, in verifying the HMAC response value to obtain a fourth verification result, the first verification module 750 is further specifically used for: The device-side random number, the server-side random number, and the target hash value are concatenated to obtain HMAC input data; Obtain the corresponding target encryption key from the device, and calculate the HMAC reference value based on the target encryption key; The HMAC reference value is compared with the HMAC response value to obtain the fourth verification result.

[0097] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiment shown above. The dual authentication device 700 based on TPM Quote and HMAC response can be used to execute the method embodiment of this application, and will not be described again here.

[0098] When dividing each function into modules according to its corresponding function. Figure 8 This is a functional block diagram of another dual authentication device based on TPM Quote and HMAC response provided in this application embodiment, applied to the device side. The dual authentication device 700 based on TPM Quote and HMAC response includes: The third sending module 810 is used to send a random number generated by the device terminal and the device identifier corresponding to the device terminal to the server. The third receiving module 820 is used to receive the server random number and server signature returned by the server, and determine whether the server random number and the server signature meet the preset verification conditions. The second generation module 830 is used to generate TPM Quote data and HMAC response value if the server-side random number and the server-side signature meet the preset verification conditions. The fourth sending module 840 is used to send the TPM Quote data and the HMAC response value to the server. The fourth receiving module 850 is used to receive the first encryption key sent by the server after both the TPM Quote data and the HMAC response value have been verified. The first decryption module 860 is used to decrypt the first encryption key according to the device encryption private key corresponding to the device end to obtain the session key; The first establishment module 870 is used to establish a secure channel between the server and the device based on the session key.

[0099] Optionally, before sending the randomly generated device-side random number and the corresponding device identifier to the server, the dual authentication device 700 based on TPM Quote and HMAC response is specifically used for: During the device registration phase, the device identifier, device signature public key, and firmware hash value corresponding to the device are obtained; Based on the device signature private key corresponding to the device signature public key, the device identifier, the device signature public key, and the firmware hash value are signed to obtain the device registration signature; Send device registration information to the server. The device registration information includes the device identifier, the device signature public key, the firmware hash value, and the device registration signature. Receive and store the device certificate and server public key returned by the server to complete the registration of the device.

[0100] Optionally, in determining whether the server-side random number and the server-side signature meet the preset verification conditions, the third receiving module 820 is specifically used for: The server signature is verified based on the server public key, the server random number, and the device identifier to obtain the signature verification result; Obtain the local historical records corresponding to the device. Check if the server-side random number exists in the local historical records to obtain the random number verification result; When the signature verification result is successful and the random number verification result is non-existent, it is determined that the preset verification condition is met.

[0101] Optionally, in generating TPM Quote data and HMAC response values, the second generation module 830 is specifically used for: The device-side random number and the server-side random number are concatenated to obtain a reference random number; Calculate the hash value corresponding to the reference random number to obtain the target hash value; Obtain the PCR register information corresponding to the device. The trusted platform module corresponding to the device is invoked, and the target hash value, PCR register information and the device signature private key are input into the trusted platform module. The authentication data and the target signature are output. The authentication data at least includes the PCR value corresponding to the PCR register information. The target signature is the signature of the authentication data by the trusted platform module based on the device signature private key. The TPM Quote data is determined based on the target hash value, the authentication data, and the target signature; Obtain the target encryption key corresponding to the device from the trusted platform module; The HMAC input data is determined based on the device-side random number, the server-side random number, and the target hash value. The HMAC response value is obtained by calculating the HMAC input data based on the target encryption key.

[0102] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiment shown above. The dual authentication device 700 based on TPM Quote and HMAC response can be used to execute the method embodiment of this application, and will not be described again here.

[0103] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0104] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0105] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0106] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0107] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0108] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0109] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0110] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip module, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0111] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A dual authentication method based on TPM Quote and HMAC response, applied to the server side, characterized in that, The method includes: The receiving device sends a device-side random number and device identifier; Based on the preset server private key, the server-generated random number and the device identifier are signed to obtain the server signature; Send the server-side random number and the server-side signature to the device. The device receives TPM Quote data and HMAC response value returned by the device. The TPM Quote data is generated and signed by the device based on the device's random number and the server's random number. The HMAC response value is calculated by the device using the target encryption key on the device's random number, the server's random number, and the TPM Quote data. The TPM Quote data and the HMAC response value are verified to obtain the target verification result; If the target verification result is successful, a session key is generated; The session key is encrypted using the device encryption public key corresponding to the device to obtain the first encryption key; The first encryption key is sent to the device to establish a secure channel between the server and the device.

2. The method as described in claim 1, characterized in that, Before the receiving device sends the device-side random number and device identifier, the method further includes: During the device registration phase, the device registration information sent by the device is received; the device registration information includes the device identifier, the device signature public key, the firmware hash value, and the device registration signature. If the device identifier is not in the preset device blacklist and the validity of the device signature public key is verified, then the device registration signature is verified based on the device signature public key, the device identifier, and the firmware hash value. If the device registration signature verification passes, a device certificate is generated based on the device identifier, the device signature public key, and the certificate validity period. Send the server public key corresponding to the server private key and the device certificate to the device.

3. The method as described in claim 2, characterized in that, The TPM Quote data includes a target hash value, authentication data, and a target signature. The verification of the TPM Quote data and the HMAC response value to obtain the target verification result includes: The target signature is verified using the device signature public key to obtain a first verification result; Obtain a preset first PCR value; the first PCR value is calculated based on the firmware hash value and a preset standard metric sequence. The second PCR value is extracted from the authentication data, and the first PCR value is compared with the second PCR value to obtain the second verification result; A reference hash value is determined based on the device-side random number and the server-side random number. The reference hash value is compared with the target hash value to obtain the third verification result; The HMAC response value was verified to obtain the fourth verification result; If the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified successfully, then the target verification result is determined to be verified successfully.

4. The method as described in claim 3, characterized in that, The verification of the HMAC response value to obtain a fourth verification result includes: The device-side random number, the server-side random number, and the target hash value are concatenated to obtain HMAC input data; Obtain the corresponding target encryption key from the device, and calculate the HMAC reference value based on the target encryption key; The HMAC reference value is compared with the HMAC response value to obtain the fourth verification result.

5. A dual authentication method based on TPM Quote and HMAC response, applied to the device side, characterized in that, The method includes: Send the randomly generated device number and the device identifier corresponding to the device to the server. Receive the server-side random number and server-side signature returned by the server, and determine whether the server-side random number and server-side signature meet the preset verification conditions; If the server-side random number and the server-side signature meet the preset verification conditions, then TPM Quote data and HMAC response value are generated; The TPM Quote data and the HMAC response value are sent to the server. After both the TPM Quote data and the HMAC response value are verified, the first encryption key sent by the server is received. The first encryption key is decrypted using the device encryption private key corresponding to the device to obtain the session key; A secure channel is established between the server and the device based on the session key.

6. The method as described in claim 5, characterized in that, Before sending the randomly generated device number and the device identifier corresponding to the device to the server, the method further includes: During the device registration phase, the device identifier, device signature public key, and firmware hash value corresponding to the device are obtained; Based on the device signature private key corresponding to the device signature public key, the device identifier, the device signature public key, and the firmware hash value are signed to obtain the device registration signature; Send device registration information to the server. The device registration information includes the device identifier, the device signature public key, the firmware hash value, and the device registration signature. Receive and store the device certificate and server public key returned by the server to complete the registration of the device.

7. The method as described in claim 6, characterized in that, The step of determining whether the server-side random number and the server-side signature meet the preset verification conditions includes: The server signature is verified based on the server public key, the server random number, and the device identifier to obtain the signature verification result; Obtain the local historical records corresponding to the device. Check if the server-side random number exists in the local historical records to obtain the random number verification result; When the signature verification result is successful and the random number verification result is non-existent, it is determined that the preset verification condition is met.

8. The method as described in claim 6 or 7, characterized in that, The generation of TPM Quote data and HMAC response values ​​includes: The device-side random number and the server-side random number are concatenated to obtain a reference random number; Calculate the hash value corresponding to the reference random number to obtain the target hash value; Obtain the PCR register information corresponding to the device. The trusted platform module corresponding to the device is invoked, and the target hash value, PCR register information and the device signature private key are input into the trusted platform module. The authentication data and the target signature are output. The authentication data at least includes the PCR value corresponding to the PCR register information. The target signature is the signature of the authentication data by the trusted platform module based on the device signature private key. The TPM Quote data is determined based on the target hash value, the authentication data, and the target signature; Obtain the target encryption key corresponding to the device from the trusted platform module; The HMAC input data is determined based on the device-side random number, the server-side random number, and the target hash value. The HMAC response value is obtained by calculating the HMAC input data based on the target encryption key.

9. An electronic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-8.

Images