Joint authentication method based on TPM and TEE

Abstract

The invention discloses a joint authentication method based on TPM and TEE, and belongs to the technical field of information security. The method is used for solving the technical problems that joint authentication in an existing scheme depends on spliced evidence, it cannot be guaranteed that a TPM state and a TEE state belong to the same execution context, and the risk of time window attack or context switching cheating exists. Through bidirectional authentication of an endorsement key and a secure start root key, independent hardware trust roots are fused into a unified joint trust root, and splicing dependence of authentication evidences is avoided; a hardware-level key negotiation and timestamp mechanism can resist man-in-the-middle attack and replay attack; the joint trust root serves as a unique trust source for subsequent state measurement and authentication, and it is ensured that TPM and TEE state measurement values are generated in the same trust domain; through time binding and space binding, space-time two-dimensional association of TPM and TEE measurement data is realized, and it can be effectively proved that the TPM and the TEE measurement data belong to the execution state of the same equipment at the same moment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, in particular to a joint authentication method based on TPM and TEE. BACKGROUND

[0002] The joint authentication based on TPM (trusted platform module) and TEE (trusted execution environment) is a deep security mechanism that combines hardware-level trust root and runtime isolation protection, aiming to realize end-to-end trusted verification from system startup to application execution. This joint authentication is widely used in high-security scenarios such as industrial edge devices, smart cars, cloud-native security, and confidential computing.

[0003] The existing joint authentication method maintains independent trust roots and measurement mechanisms for TPM and TEE during implementation: TPM records the startup chain hash through PCR; TEE proves the runtime state through Enclave Identity or remote proof Quote, but there is a lack of strong binding between the two, and attackers may load malicious hardware-protected private memory areas in TEE while proving the system clean in TPM, resulting in joint authentication relying on spliced evidence, but unable to guarantee that TPM state and TEE state belong to the same execution context, and there is a risk of time window attack or context switching fraud. SUMMARY

[0004] The purpose of the present application is to provide a joint authentication method based on TPM and TEE, which solves the technical problems of existing joint authentication methods relying on spliced evidence, unable to guarantee that TPM state and TEE state belong to the same execution context, and the risk of time window attack or context switching fraud.

[0005] The purpose of the present application can be achieved by the following technical solutions: The joint authentication method based on TPM and TEE comprises: Performing mutual authentication between the endorsement key of TPM and the secure boot root key of TEE, generating a shared session key across trust domains as a joint trust root, and storing the joint trust root in the non-volatile storage area of TPM and the secure storage unit of TEE, respectively; Based on the generated joint trust root, synchronously collecting the platform configuration register measurement value of TPM and the runtime environment measurement log of TEE, binding the platform configuration register measurement value of TPM and the runtime environment measurement log of TEE as the same execution context through hardware timestamp and physical address hash value, and generating a context-bound joint measurement sequence; The verification end verifies the validity of the joint measurement sequence through the joint trust root, and checks the context consistency of TPM and TEE state summaries, and dynamically completes the joint authentication according to the checking result.

[0006] Preferably, when performing two-way authentication using the TPM's endorsement key and the TEE's secure boot root key, the TPM will share its unique device identifier and public key. The TPM firmware version number is concatenated to form an authentication request message. The authentication request message is then RSA-SHA256 signed using the EK private key to generate the TPM authentication request message. It is sent to the TEE via the system bus; TEE received Then, the validity of the EK signature is verified using the pre-set TPM vendor public key. If the verification fails, the authentication is terminated and an exception log is recorded.

[0007] Preferably, after successful verification, the TEE will send its unique identifier and public key. The TEE security version number is concatenated with the response message, and an ECC-SHA384 signature is performed using the SRK private key to generate a TEE authentication response message. Return to TPM; TPM Validation The secure boot root key SRK signature validity is verified before use. private key and Perform ECDH key exchange to generate the original shared key. .

[0008] Preferably, the original shared key Perform key derivation function processing to obtain the joint root of trust. .

[0009] Preferably, the TPM completes the TPM platform configuration register list. After data acquisition, read the low-power real-time clock timestamp and record it as... ; TEE completes structured logs After acquisition, read the same low-power real-time clock timestamp and record it as... ; Calculate the time difference Furthermore, if ΔT > 5ms, it is determined that the synchronization has failed, the current measurement data is discarded, and data is collected again. If ΔT≤5ms, the binding timestamp is obtained through calculation. , serves as the time identifier for the joint context; min() is the function to obtain the minimum value.

[0010] Preferably, the TPM reads the TPM platform configuration register list through internal registers. The first starting address in the physical memory of the TPM chip and the first occupied size ; TEE obtains structured log through memory management unit second start address in TEE secure memory and second size of occupation ; Splice the obtained start address and size of occupation, calculate the space binding hash using SHA256, the expression involved is: wherein, is a 256-bit physical hash evidence, uniquely identifying the physical storage location of the current measurement data; || represents byte stream splicing; When performing data splicing and joint signing, splice the TPM platform configuration register list , structured log , binding timestamp , space binding hash into an original joint data block in a fixed order .

[0011] Preferably, calculate the HMAC-SHA256 message authentication code for the original joint data block using the joint root of trust, to ensure data integrity and authenticity; According to the original joint data block , HMAC-SHA256 message authentication code , encapsulate to generate the final joint measurement sequence.

[0012] Preferably, the verification end uses the same joint root of trust as the generation end to recalculate the HMAC-SHA256 for the extracted original joint data block , obtaining a verification message authentication code , and comparing the verification message authentication code with the HMAC-SHA256 message authentication code in the evidence: If , the signature is valid, and it is determined that the original joint data block has not been tampered with and is trustworthy; Otherwise, the evidence is invalid, and it is determined that the data has been tampered with or the signature has been forged.

[0013] Preferably, when verifying the context consistency, the verification end obtains the TPM and TEE physical storage information of the local device, and uses the obtained TPM and TEE physical storage information of the local device to recalculate the local physical hash ; Compare the local physical hash with the physical hash evidence : If yes, it is determined that the physical storage location matches, and the context binding is valid. Otherwise, it is determined that it is replay evidence across devices / memory regions.

[0014] Preferably, the TPM and TEE of the local device store physical storage information, including the local TPM physical start address , the local TPM data length , the local TEE physical start address , and the local TEE data length .

[0015] Compared with the prior art, the present application has the beneficial effects of: The present application fuses independent hardware roots of trust into a unified joint root of trust through bidirectional authentication of the endorsement key and the secure boot root key, avoids splicing-type dependence of authentication evidence, and can solve the problem of fragmented roots of trust; the hardware-level key negotiation and the timestamp mechanism can resist man-in-the-middle attacks and replay attacks, and the secure storage ensures that the joint root of trust cannot be tampered with or stolen; the joint root of trust serves as the only trust source for subsequent state measurement and authentication, ensures that the TPM and TEE state measurement values are generated in the same trust domain, and fundamentally eliminates the risk of time window attacks.

[0016] The present application realizes time-space two-dimensional association of TPM and TEE measurement data through time binding and space binding, can effectively prove that the two belong to the execution state of the same device at the same time, solves the defects of independent measurement results and inability to trace the common context in the traditional scheme; by strongly binding the physical address hash and the device hardware physical memory, an attacker cannot replay the measurement data of the current device by copying the measurement data of other devices, and the physical environment uniqueness of the measurement sequence can be ensured; based on the HMAC-SHA256 message authentication code signature of the joint root of trust, the joint measurement sequence can be ensured to be tamper-proof from generation to storage, and a verifiable and context-specific complete evidence chain is provided for subsequent remote authentication; by synchronously collecting TEE runtime environment logs, full-life-cycle measurement of static configuration plus dynamic execution is realized, and compared with the traditional TPM which only measures the static measurement start phase, the detection capability for runtime attacks can be effectively improved.

[0017] In the present application, the TPM and TEE measurement data and context information are bound as a whole through the original joint data block and the HMAC-SHA256 message authentication code, and a part cannot be tampered with individually; the physical hash evidence and the binding timestamp ensure that the evidence is strongly associated with a specific physical location and a specific time, and can resist replay attacks; based on HMAC-SHA256 and structured Header, the verification end can quickly complete parsing and verification; through the joint root of trust, joint signature of TPM and TEE is realized, and the authentication consistency problem in the multi-root-of-trust scenario can be solved. Attached Figure Description

[0018] The invention will now be further described with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating the operation of the joint authentication method based on TPM and TEE according to the present invention. Detailed Implementation

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

[0021] like Figure 1 As shown, this invention is a joint certification method based on TPM and TEE, comprising: The TPM's endorsement key and the TEE's secure boot root key are used for two-way authentication to generate a shared session key across trust domains as a joint trust root. This joint trust root is then stored in the TPM's non-volatile storage area and the TEE's secure storage unit, respectively. The specific steps include: Once the TPM chip and TEE environment have completed hardware initialization, and both the TPM's endorsement key EK and the TEE's secure boot root key SRK are pre-loaded into the hardware fuse area and cannot be exported, the TPM generates a temporary asymmetric key pair using its internal random number generator, where the public key is... The private key is stored in the protected memory area of ​​the TPM; TEE loads the secure boot root key SRK through the secure boot process and generates a temporary session key pair, with the public key being... The private key is stored in the secure execution environment of the TEE; When performing two-way authentication using the TPM's endorsement key and the TEE's secure boot root key, the TPM will display its own unique device identifier, The TPM firmware version number is concatenated to form an authentication request message. The authentication request message is then RSA-SHA256 signed using the EK private key to generate the TPM authentication request message. It is sent to the TEE via the system bus; TEE received Then, the validity of the EK signature is verified using the pre-set TPM vendor public key. If the verification fails, the authentication is terminated and an error log is recorded. After successful verification, the TEE will send its unique identifier, Spliced with TEE security version number as response message, ECC-SHA384 signature is performed using SRK private key to generate TEE authentication response message , return to TPM; TPM verifies the validity of SRK signature, and after verification, performs ECDH key exchange with using the private key of to generate the original shared key ; Among them, TPM verifies through the verification mode combining asymmetric cryptography verification and structured data check, which is the existing conventional technical solution, and the specific implementation steps are not described here; ECDH (Elliptic Curve Diffie-Hellman, Elliptic Curve Diffie-Hellman) is a key agreement protocol based on elliptic curve cryptography, which allows communication parties to calculate a shared symmetric key through exchanging public information on an insecure public channel, and a third party cannot derive the key through eavesdropping public information; Its core is to replace the finite field discrete logarithm problem of traditional Diffie-Hellman (DH) key exchange with elliptic curve discrete logarithm problem (ECDLP), which realizes shorter key length and higher calculation efficiency under the same security level.

[0022] The original shared key is processed by a key derivation function to obtain a joint trust root, and the expression involved is: Among them, is the joint trust root; is the original shared key generated by ECDH key exchange; is a hash message authentication code algorithm based on SHA-512; is an iteration counter, which increases from 1 to 10000, and 10000 is the total number of iterations; is the global unique identifier of the TPM chip; is the unique identifier of the TEE environment; is the timestamp generated by the hardware clock; i is the iteration calculation number index of HMAC-SHA512; is the first 256 bits of the intercepted hash result; The HMAC outputs of 10000 iterations are XORed bit by bit; TPM encrypts the joint trust root and writes it to its non-volatile storage area NVRAM, address range 0x1000-0x2000, and the encryption key is the storage root key SRK of TPM; TEE encrypts the joint trust root Stored in a secure storage unit, such as SecureStorage in OP-TEE, it is protected by hardware isolation mechanisms to ensure that the rich execution environment REE cannot access it; Both parties generate and store verification values ​​respectively. H is the SHA3-256 hash function. This is the physical hardware identifier of the device, used to verify the integrity of the federated root of trust during subsequent startup.

[0023] In this embodiment of the invention, by using bidirectional authentication between the endorsement key and the secure boot root key, independent hardware trust roots are merged into a unified joint trust root, avoiding the splicing dependency of authentication evidence and solving the problem of trust root fragmentation. Hardware-level key negotiation and timestamp mechanisms can resist man-in-the-middle attacks and replay attacks, and secure storage ensures that the joint trust root cannot be tampered with or stolen. As the sole trust source for subsequent state measurement and authentication, the joint trust root ensures that the TPM and TEE state measurement values ​​are generated within the same trust domain, fundamentally eliminating the risk of time window attacks.

[0024] This step, through a closed-loop design encompassing hardware initialization, two-way authentication, key negotiation, and secure storage, achieves the fusion of trust anchors between the TPM and TEE, providing an unforgeable trust foundation for joint authentication. Based on the generated joint trust root, the platform configuration register metrics of the TPM and the runtime environment metric logs of the TEE are collected synchronously. Using hardware timestamps and physical address hashes, the platform configuration register metrics of the TPM and the runtime environment metric logs of the TEE are bound to the same execution context, generating a context-bound joint metric sequence. Specific steps include: When the TPM is loaded, it reads the encrypted federated root of trust from the non-volatile memory area NVRAM. After being decrypted using the TPM storage root key SRK, it is loaded into the protected memory area of ​​the TPM metrics engine; verification is then performed using a pre-stored checksum. Completeness: If the value is equal to the stored checksum, and they do not match, a hardware reset is triggered and a measurement failure log is recorded. When the TEE is loaded, it reads the union root of trust from the secure storage unit. Calculated through the TEE's internal hash engine It is compared with the pre-stored verification value. After verification, it will be... Loaded into the security register of the TEE measurement module; When collecting the platform configuration register metric values ​​of TPM, select the dynamic PCR indexes that are strongly related to the runtime environment in TPM, such as PCR[8]~PCR

[15] , which correspond to dynamic loading components such as OS kernel modules, drivers, and user-mode processes, as well as static basic PCRs, such as PCR[0]~PCR[7], which correspond to firmware, BIOS, bootloader, etc. The TPM metrics engine reads PCR values ​​in indexed order. Each PCR value contains a PCR index, a 256-bit SHA256 hash value, and a metric timestamp, forming a list of TPM platform configuration registers. ; Among them, the PCR index corresponds to 1 byte, the 256-bit SHA256 hash value corresponds to 32 bytes, the measurement timestamp corresponds to 8 bytes, and it is generated by the TPM internal hardware clock. TPM platform configuration register list Calculate the overall hash value This serves as the base data for subsequent binding; When collecting runtime environment measurement logs of TEE, the collection targets are key components of the TEE's internal runtime environment, including trusted application loading information, memory security attributes, and peripheral access records. Among them, the trusted application loading information includes the trusted application unique identifier, loading address, and code segment hash value, which correspond to 16 bytes, 64 bits, and 32 bytes, respectively. Memory security attributes: TEE memory page table, shared memory region; where the TEE memory page table contains read-only, write, and execute permission flags; the shared memory region contains the physical addresses of memory blocks that interact with the REE and access control policies; Peripheral access logs: TEE's access permission configuration for trusted peripherals such as encryption chips and sensors, such as I2C / SPI bus access keys; The TEE metrics module generates structured logs in chronological order. Each log entry is formatted as log type, object ID, hash value, and operation timestamp, with a total length ≤ 4096 bytes; Among them, the log type corresponds to 1 byte, the object ID corresponds to 16 bytes, the hash value corresponds to 32 bytes, the operation timestamp corresponds to 8 bytes, and the TEE hardware clock is generated. For structured logs Calculate the overall hash value This serves as the base data for subsequent binding; When the platform configuration register measurement value of the TPM and the runtime environment measurement log of the TEE are bound to the same execution context through the hardware timestamp and the physical address hash value, the built-in low-power real-time clock (RTC) of the device is used as the time reference. The TPM and the TEE directly read the RTC timestamp through the hardware bus, avoiding software layer time tampering. The TPM completes the TPM platform configuration register list After collection, the RTC timestamp is read and recorded as , which corresponds to 64 bits, in the format of Unix timestamp plus microseconds, for example, 1717260000123456. The TEE completes the structured log After collection, the same RTC timestamp is read and recorded as . The time difference is calculated and analyzed. If ΔT > 5ms, it is determined that the synchronization fails, the measurement data is discarded, and the collection is restarted. If ΔT≤5ms, the binding timestamp is obtained through calculation , which is used as the time identifier of the joint context; min() is the minimum value function. The TPM reads the TPM platform configuration register list from the first starting address in the physical memory of the TPM chip and the first size . The TEE obtains the structured log from the second starting address in the TEE secure memory and the second size . The obtained starting address and size are spliced, and the spatial binding hash is calculated using SHA256. The expression involved is: wherein is a 256-bit physical hash evidence, uniquely identifying the physical storage location of the current measurement data; || represents byte stream splicing. When splicing data and jointly signing, the TPM platform configuration register list , the structured log , the binding timestamp , and the spatial binding hash are spliced into the original joint data block in a fixed order : . The original joint data block is calculated using the joint trust root HMAC-SHA256 message authentication code Ensure data integrity and authenticity:

[0025] Wherein, HMAC-SHA256 is a hash message authentication code algorithm based on SHA256, outputting a 256-bit hash value; According to the field Header, the original joint data block , the HMAC-SHA256 message authentication code Encapsulation generates the final joint measurement sequence; Wherein, the field Header is the metadata part of the joint measurement sequence, located at the most initial position of the sequence, used to describe the basic attributes, format version and integrity check information of the entire measurement sequence; Its core functions include parsing guidance, integrity pre-check and scene adaptation; Parsing guidance: through fixed fields such as version number and total length, inform the receiver how to correctly parse the subsequent data; Integrity pre-check: built-in header checksum, prevent Header itself from being tampered with, such as attackers modifying the total length field to cause parsing errors; Scene adaptation: distinguish measurement scenarios through type identification, such as startup measurement and runtime measurement, support parsing rule switching in different scenarios; Header adopts a fixed-length structured format, 12 bytes, all fields are encoded using big-endian, ensuring consistent parsing across hardware architectures, the specific structure includes version number Version, total length , type identification Type, reserved field Reserved, header checksum , corresponding to 2 bytes, 4 bytes, 1 byte, 1 byte, 4 bytes respectively.

[0026] In the embodiment of the application, through time binding and space binding, the time and space two-dimensional association of TPM and TEE measurement data is realized, which can effectively prove that the two belong to the same device at the same time execution state, solving the defects of independent measurement results and inability to trace the common context in traditional schemes; By strongly binding the physical address hash with the device hardware physical memory, attackers cannot replay the measurement data of other devices to attack the current device, which can ensure the uniqueness of the physical environment of the measurement sequence; Based on the HMAC-SHA256 message authentication code signature of the joint root of trust, the whole process from generation to storage of the joint measurement sequence can be ensured to be tamper-proof, providing a verifiable and context-specific complete evidence chain for subsequent remote authentication; By synchronously collecting TEE runtime environment logs, the full life cycle measurement of static configuration plus dynamic execution is realized, which can effectively improve the detection capability of runtime attacks compared with the traditional TPM which only measures the startup phase statically.

[0027] The verification end verifies the validity of the joint measurement sequence through the joint root of trust, and checks the context consistency of the TPM and TEE state digest, and dynamically completes the joint authentication according to the checking result. The specific steps include: The verification end receives the joint measurement sequence, reads the field Header in the joint measurement sequence, and parses the key fields: Check the version number Version = 0x0100 and the type identifier Type = 0x01; check the corresponding supported version and the corresponding start-up time measurement scene; Verify the header checksum At this time, the first 8 bytes of the field Header are extracted and the verification checksum is calculated, and the calculated verification checksum is compared with the header checksum If they are not the same, the evidence is invalid; The first 8 bytes of Header correspond to the version number Version, the total length , the type identifier Type, and the reserved field Reserved; the calculation of the verification checksum is a conventional technical means, such as the standard CRC32 algorithm, and the specific implementation steps are not described here; According to the total length , the total bytes corresponding to the total length , it is checked whether the total length of the received evidence is the same as the total length corresponding to the total bytes, to prevent data truncation; Through Header parsing and pre-checking, it is ensured that the evidence format is legal and the length is complete, laying a foundation for subsequent verification.

[0028] According to the total length and the fixed offset, the original joint data block , the HMAC-SHA256 message authentication code is extracted; The original joint data block is located after the field Header, and the length is Length-Header length- Length; is located at the end of the evidence, and the length is 32 sub-segments, and the offset is Length-32; The verification end uses the same joint root of trust as the generation end, pre-shares through a secure channel, re-computes the HMAC-SHA256 of the extracted original joint data block , and obtains the verification message authentication code , compares the verification message authentication code with the HMAC-SHA256 message authentication code in the evidence: If , the signature is valid, and it is determined that the original joint data block is not tampered and the source is credible; Otherwise, the evidence is invalid, and it is determined that the data is tampered or the signature is forged; When verifying the consistency of the context, the verification end obtains the TPM and TEE physical storage information of the local device, including the local TPM physical starting address , the local TPM data length , the local TEE physical starting address , and the local TEE data length , and recalculates the local physical hash by using the obtained TPM and TEE physical storage information of the local device The expression involved is: Compare the local physical hash With the physical hash evidence : If consistent, it is determined that the physical storage location matches, and the context binding is valid; Otherwise, it is determined as a cross-device / memory area replay evidence.

[0029] In the embodiment of the application, the TPM and TEE measurement data and context information are bound as a whole by the original joint data block and the HMAC-SHA256 message authentication code, and a part cannot be tampered with alone; the physical hash evidence and the binding timestamp ensure that the evidence is strongly associated with a specific physical location and a specific time, and can resist replay attacks; based on HMAC-SHA256 and structured Header, the verification end can quickly complete parsing and verification; the joint signature of TPM and TEE is realized by joint root of trust, and the authentication consistency problem in the multi-root of trust scenario can be solved. Through the above steps, the joint authentication evidence realizes the security goals of trusted measurement data, traceable context, and verifiable signature, and provides core technical support for device authentication in a cross-root of trust environment.

[0030] In several embodiments provided by the present application, it should be understood that the disclosed system can be implemented in other manners. For example, the above described embodiments of the application are merely schematic, and the division of the modules is merely a logical function division, and there can be another division manner in actual implementation.

[0031] The modules illustrated as separated components can or can not be physically separated, and the components illustrated as modules can or can not be physical modules, and can be located in one place or distributed on multiple network modules. According to actual needs, some or all of the modules can be selected to achieve the purpose of the embodiments of the present application.

[0032] In addition, each functional module in each embodiment of the present application can be integrated in one processing module, or each module can exist physically alone, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of hardware plus software functional module.

[0033] It is obvious for those skilled in the art that the present application is not limited to the details of the above exemplary embodiments, and the present application can be realized in other specific forms without departing from the essential characteristics of the present application.

[0034] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the spirit and scope of the technical solutions of the present application.

Claims

1. A joint certification method based on TPM and TEE, characterized in that, include: By performing two-way authentication using the TPM's endorsement key and the TEE's secure boot root key, a shared session key across trust domains is generated as a joint trust root, and this joint trust root is stored in the TPM's non-volatile storage area and the TEE's secure storage unit, respectively. Based on the generated joint root of trust, the platform configuration register metric of TPM and the runtime environment metric log of TEE are collected synchronously. The platform configuration register metric of TPM and the runtime environment metric log of TEE are bound to the same execution context through hardware timestamp and physical address hash value, and a context-bound joint metric sequence is generated. The verification end verifies the validity of the joint metric sequence through the joint root of trust and verifies the contextual consistency between the TPM and the TEE state digest, and dynamically completes the joint authentication based on the verification results.

2. The joint certification method based on TPM and TEE according to claim 1, characterized in that, When performing two-way authentication using the TPM's endorsement key and the TEE's secure boot root key, the TPM will share its unique device identifier and public key. The TPM firmware version number is concatenated to form an authentication request message. The authentication request message is then RSA-SHA256 signed using the EK private key to generate the TPM authentication request message. It is sent to the TEE via the system bus; TEE received Then, the validity of the EK signature is verified using the pre-set TPM vendor public key. If the verification fails, the authentication is terminated and an exception log is recorded.

3. The joint certification method based on TPM and TEE according to claim 2, characterized in that, After successful verification, the TEE will send its unique identifier and public key. The TEE security version number is concatenated with the response message, and an ECC-SHA384 signature is performed using the SRK private key to generate a TEE authentication response message. Return to TPM; TPM Validation The secure boot root key SRK signature validity is verified before use. private key and Perform ECDH key exchange to generate the original shared key. .

4. The joint certification method based on TPM and TEE according to claim 3, characterized in that, For the original shared key Perform key derivation function processing to obtain the joint root of trust. .

5. The joint certification method based on TPM and TEE according to claim 4, characterized in that, TPM completes the TPM platform configuration register list. After data acquisition, read the low-power real-time clock timestamp and record it as... ; TEE completes the structured log. After acquisition, read the same low-power real-time clock timestamp and record it as... ; Calculate the time difference Furthermore, if ΔT > 5ms, it is determined that the synchronization has failed, the current measurement data is discarded, and data is collected again. If ΔT≤5ms, the binding timestamp is obtained through calculation. , serving as a time marker for the joint context; min() is a function that retrieves the minimum value.

6. The joint certification method based on TPM and TEE according to claim 5, characterized in that, TPM reads the TPM platform configuration register list through internal registers. The first starting address in the physical memory of the TPM chip and the first occupied size ; TEE obtains structured logs through the memory management unit. The second starting address in TEE safe memory Second occupied size ; The obtained starting address and occupied size are concatenated, and the space binding hash is calculated using SHA256. The relevant expression is: in, A 256-bit physical hash, uniquely identifying the physical storage location of the current metric data; || indicates byte stream concatenation; When performing data concatenation and joint signature, the TPM platform configuration register list is used. Structured logs Binding timestamp Space-bound hash Concatenate them into original joint data blocks in a fixed order. .

7. The joint certification method based on TPM and TEE according to claim 6, characterized in that, Use the joint root of trust on the original joint data block Calculate HMAC-SHA256 message authentication code To ensure data integrity and authenticity; Based on the original joint data block HMAC-SHA256 message authentication code The final joint metric sequence is generated by encapsulation.

8. The joint certification method based on TPM and TEE according to claim 7, characterized in that, The verification end uses the same federated root of trust as the generation end. For the extracted raw combined data blocks Recalculate HMAC-SHA256 to obtain the authentication code for the verification message. The verification message authentication code will be used. With the HMAC-SHA256 message authentication code in the evidence Comparison: like If the signature is valid, the original combined data block is determined. It has not been tampered with and its source is reliable; Otherwise, the evidence is invalid, and the data is determined to have been tampered with or the signature to be forged.

9. The joint certification method based on TPM and TEE according to claim 8, characterized in that, When verifying context consistency, the verification end obtains the TPM and TEE physical storage information of the local device, and recalculates the local physical hash using the obtained TPM and TEE physical storage information. ; Compare local physical hash With physical hash evidence : If they match, the physical storage location is determined to be a match, and the context binding is valid; Otherwise, it is considered evidence of replay across device / memory regions.

10. The joint certification method based on TPM and TEE according to claim 9, characterized in that, Local device TPM and TEE physical storage information, including the local TPM physical starting address. Local TPM data length Local TEE physical starting address Local TEE data length .

Images