Implementation method for customizable trusted execution environment during operation supported by TPM (Trusted Platform Module) 2.0 standard facing FPGA-SoC (Field Programmable Gate Array-SoC)
By building an FPGA-vTPM architecture that supports TPM 2.0, the problem of FPGA-SoC TEE lacks runtime customization is solved, and security-enhanced TEE is achieved, which improves user trust and cloud platform compatibility, and supports dynamic measurement and execution of sensitive operations.
Patent Information
- Application Number
- CN202510397382.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-31
- Publication Date
- 2025-07-18
AI Technical Summary
The existing FPGA-SoC TEE solutions lack dynamic measurement and verification sensitive operations, and cannot customize TEE at runtime, resulting in reduced user trust and a lack of unified security standards limiting its widespread adoption on cloud platforms.
Build a FPGA-vTPM architecture that combines vTPM and FPGA-SoC that supports TPM 2.0, including SRAM PUF, Trusted Management Module (TMM), TPM Agent and vTPM components, providing a secure runtime customizable TEE, supporting initialization, key generation and update of TPM 2.0 standard, and extending TEE functions.
Provide users with secure enhanced TEE, supports dynamic measurement and unified execution of sensitive operations, improves user trust, and provides FPGA-SoC TEE with TPM 2.0-compatible solutions on the cloud platform, with broad applicability and the potential of unified TEE platform.
Smart Images

Figure CN120337227A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of computer technology and information security technology, and particularly relates to a method for implementing a runtime customizable trusted execution environment supporting the TPM2.0 standard for FPGA-SoC. Background Art
[0002] With the rapid development of computer network technology, hardware-based acceleration devices, such as Field Programmable Gate Arrays (FPGAs), especially FPGA-SoC devices, have been introduced into the cloud to meet the needs of large-scale parallel computing. However, the security issues in cloud data centers have reduced the confidence of end users in cloud FPGAs, thus preventing end users from transferring sensitive work such as their Intellectual Property (IP) to cloud FPGAs. Existing security solutions, such as using a Trusted Execution Environment (TEE), provide a secure and verifiable execution environment for sensitive data and code. However, existing FPGA-SoC TEE solutions lack dynamic measurement and verification of sensitive operations and cannot customize the TEE at runtime, thus reducing user trust. In addition, the lack of a unified security standard also restricts their wide adoption on cloud platforms. To address the above issues, the Trusted Platform Module standard, as a unified security standard, has been widely applied to cloud TEEs, which provides a good solution to the above problems. However, existing solutions based on the TPM standard cannot provide a secure runtime customizable solution for FPGA-SoC TEEs, which reduces users' confidence in using them. Summary of the Invention
[0003] In view of the above problems, the present invention proposes a method for implementing a runtime customizable trusted execution environment supporting the TPM 2.0 standard for FPGA-SoC. This method solves the problem that existing solutions based on the TPM standard cannot provide secure runtime customization for FPGA-SoC TEEs, constructs a runtime customizable TEE on FPGA-SoC using user-controllable vTPMs, provides a security-enhanced TEE for users, and also provides a method compatible with TPM 2.0 for performing sensitive operations.
[0004] Provide an FPGA-vTPM architecture that combines a vTPM supporting TPM 2.0 with an FPGA-SoC. The architecture includes:
[0005] Four components for constructing the FPGA-vTPM architecture;
[0006] Initialization scheme for initializing the FPGA-vTPM architecture and securely generating session keys;
[0007] Key update scheme for securely updating session keys.
[0008] Furthermore, for the four components, the description is as follows:
[0009] 1) SRAM PUF, which is used to provide a truly random number seed for generating security keys and authenticate the device using the challenge-response process by leveraging the characteristics of the PUF;
[0010] 2) Trusted Management Module (TMM), which provides TPM management and FPGA-SoC management functions; TPM management includes functions such as vTPM initialization and authentication, and session key update; FPGA-SoC management includes the trusted boot scheme of the FPGA-SoC, secure verifiable deployment, and user IP call functions;
[0011] 3) TPM proxy, which is used to forward encrypted TPM commands and responses;
[0012] 4) vTPM, which runs on user nodes supporting the full TPM 2.0 standard and extends the functions of the FPGA-SoC TEE.
[0013] Furthermore, for the initialization scheme, it is as follows:
[0014] 1) Device registration phase, including:
[0015] (1-1) FPGA-SoC registration includes the trusted third party (TTP) generating a device key pair and burning it into the BBRAM, generating a customized bootable image, and generating authentication information;
[0016] (1-2) User vTPM registration includes generating a vTPM device key and authentication information;
[0017] 2) Device startup phase, including:
[0018] (2-1) FPGA-SoC startup, securely loading the bootable image generated by the TTP and generating verification information;
[0019] (2-2) Startup of the user's vTPM instance, obtaining the FPGA-SoC authentication information from the TTP and initializing the vTPM;
[0020] 3) Remote authentication and session key generation phase, including:
[0021] (3-1) Starting the vTPM to generate a random number r0 for this communication;
[0022] (3-2) The vTPM sends an authentication request to the TMM of the FPGA-SoC, including the public key certificate Ca(PK TpM ) of the vTPM, the challenge value C1 of the PUF, and the random number r0;
[0023] (3-3) The TMM first verifies the public key certificate, and then generates a key pair PK ATTEST / SK ATTEST for this authentication process. Further, the TMM generates verification information H1 containing the measurement data of the bootable image;
[0024] (3-4) The TMM uses C1 as a challenge to call the SRAM PUF to obtain the response R1;
[0025] (3-5) The TMM generates a session key containing H1 and R1, and generates response information H2;
[0026] (3-6) The vTPM verifies H2, and generates the corresponding session key after passing.
[0027] Further, for the key update scheme, as follows:
[0028] 1) The vTPM concatenates the values from PCR0 to PCR23 and calculates H PCR as the current system state;
[0029] 2) The vTPM generates H1 containing H PCR and the device ID (#DI), and selects a new pair of challenge-response value pairs (C2 and R2);
[0030] 3) The vTPM combines H1 and R2 to generate a new session key;
[0031] 4) The vTPM sends H1 and C2 to the TMM for verification;
[0032] 5) The TMM calculates the new session key and encrypts R2 and sends it to the vTPM to enable the new session key.
[0033] Provide a secure enhanced runtime customizable FPGA-SoC TEE system based on the FPGA-vTPM architecture, the system includes:
[0034] A TPM 2.0 supported FPGA-SoC trusted boot scheme for supporting the trusted boot and remote authentication of the FPGA-SoC;
[0035] A TPM 2.0 supported IP deployment scheme for dynamically verifiable deployment of user IP at runtime;
[0036] TPM 2.0 supports IP calling scheme, which is used to dynamically and verifiably call user IP at runtime.
[0037] Furthermore, the FPGA-SoC trusted boot solution supported by TPM 2.0 is described as follows:
[0038] The BootROM is immutably fixed in the device as the system's CRTM. The device key is programmed into the BBRAM by the TTP during the initialization phase and used as the root trust key. The startup steps are as follows:
[0039] 1) After the FPGA-SoC is powered on, the BootROM executes and decrypts the customized FSBL using the root key and loads it into the OCM.
[0040] 2) FSBL performs decryption, authentication and measurement of subsequent boot partitions in sequence, including:
[0041] (2-1) Complete bitstream of the SRAM PUF configured on the FPGA;
[0042] (2-2) Load PMU_FW;
[0043] (2-3) Load ATF;
[0044] (2-4) Load the OP-TEE kernel;
[0045] (2-5) Load the boot program U-Boot;
[0046] 3)U-Boot starts and measures REE OS (Linux) and Rootfs;
[0047] 4) vTPM is initialized, the measurement value is read and expanded into the corresponding PCR.
[0048] Furthermore, for the IP deployment solution supported by TPM 2.0, the steps are as follows:
[0049] 1) The user sends a request to vTPM to deploy an IP. The request should include information about the IP, such as the IP encryption key.
[0050] 2) vTPM obtains the encrypted IP bitstream, encryption key and IP hash value according to the request, generates the corresponding signature and sends it to TMM;
[0051] 3) TMM verifies the signature, deploys the IP by calling the interface in the OP-TEE kernel and measures the process;
[0052] 4) After successful deployment, the TMM sends the encrypted measurement value to the vTPM for verification;
[0053] 5) The vTPM verifies the measurement value, extends the value into PCR8, and finally returns the response information.
[0054] Furthermore, for the IP call scheme supported by TPM 2.0, the steps are as follows:
[0055] 1) The user sends a request to the vTPM to call an IP. The request should include information about the IP, input data, address, output address, etc.;
[0056] 2) The vTPM measures the input data according to the request and extends it into PCR9;
[0057] 3) The vTPM encrypts the address and data and sends them to the TMM;
[0058] 4) After decrypting, the TMM calls the interface in the OP-TEE kernel to call the IP to obtain the output;
[0059] 5) The TMM calculates the measurement of the output, encrypts the output data and the measurement value, and sends them to the vTPM;
[0060] 6) The vTPM verifies the measurement value, extends the value into PCR10, and finally returns the output information.
[0061] Provide an extended TPM command and response set that complies with the TPM2.0 specification. The command set includes:
[0062] The session key dynamic update command and response of the FPGA-vTPM architecture that complies with the TPM 2.0 specification;
[0063] The dynamically verifiable user IP deployment command and response of the FPGA-vTPM architecture that complies with the TPM 2.0 specification;
[0064] The dynamically verifiable user IP call command and response of the FPGA-vTPM architecture that complies with the TPM 2.0 specification.
[0065] The beneficial effects of the embodiments of the present application are as follows:
[0066] In the embodiments of the present application, by using the user-controllable vTPM to build a runtime-customizable TEE on the FPGA-SoC, a security-enhanced TEE is provided for users, and at the same time, a method compatible with TPM 2.0 is provided for performing sensitive operations; moreover, for sensitive operations of user IP on the FPGA-SoC TEE, such as IP deployment and call, the embodiments of the present application provide a dynamic measurement method and a unified execution method; in addition, the embodiments of the present application use the vTPM to build a TEE with wide applicability and have the potential to be integrated with other vTPM-based TEE architectures to jointly build a unified TEE platform in the cloud.
[0067] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0068] Figure 1 The framework schematic diagram provided for the embodiment of the present application;
[0069] Figure 2 The system schematic diagram provided for the embodiment of the present application; DETAILED DESCRIPTION OF THE EMBODIMENTS
[0070] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.
[0071] As Figure 1 shown, it is the framework schematic diagram of the embodiment of the present application, which includes three participating parties:
[0072] (1) Participating Party 1, which is a trusted third party (TTP). In this embodiment, it is assumed that the trusted third party plays the role of a trusted authority in the manufacturing and initialization of the FPGA-SoC device cloud and the initialization process of the user-controllable vTPM. The functions it provides include programming the device key in the battery-backed RAM (BBRAM) of the FPGA-SoC to support trusted boot, generating SRAM PUF challenge-response pairs for the FPGA-SoC, and providing signature and certificate issuance functions for the FPGA-SoC and vTPM;
[0073] (2) Participating Party 2, which is a cloud service provider (CSP). It owns and maintains physical devices and provides services to remote users through the network, such as providing services for remote users to deploy IP in cloud FPGA-SoC devices;
[0074] (3) Participating Party 3, which is a user node. It is a host owned by a remote user, and the remote user is a consumer of the CSP. We assume that the user node is secure and all local applications and data are protected. The user develops IP locally through this node or deploys a secure and trusted vTPM instance on this node. It is assumed that the communication between the user node and the TTP is secure.
[0075] It includes four components:
[0076] (1) SRAM PUF component, which is used to provide a truly random number seed to generate a security key, and authenticate the device using the challenge-response process by utilizing the characteristics of the PUF;
[0077] (2) Trusted Management Module (TMM) component, providing TPM management and FPGA-SoC management functions; TPM management includes functions such as initialization and authentication of vTPM, and session key update; FPGA-SoC management includes the trusted boot solution of FPGA-SoC, secure verifiable deployment, and user IP invocation functions;
[0078] (3) TPM proxy component, used to forward encrypted TPM commands and responses;
[0079] (4) vTPM component, running on user nodes that support the complete TPM 2.0 standard and extending the functions of FPGA-SoC TEE.
[0080] The following content will be described in detail taking the example of a user wishing to deploy and invoke the user's IP on an FPGA-SoC device of an untrusted cloud service provider as follows:
[0081] (1) Step 1, the CSP registers the cloud FPGA-SoC device with the TTP;
[0082] Step 1 includes:
[0083] (1-1) The TTP obtains and stores the device ID (#DI) generated by the device vendor as the device identifier;
[0084] (1-2) The TTP generates the device key pair for the FPGA-SoC: PK DEV and SK DEV , and burns SK DEV into the BBRAM of the FPGA-SoC;
[0085] (1-3) The TTP generates the key pair for the TMM of this FPGA-SoC: PK TMM and SK TMM , and generates a customized bootable image for this FPGA-SoC;
[0086] (1-4) The TTP measures the bootable image and collects the SRAM PUF challenge response values of the device;
[0087] (1-5) The TTP stores information such as the #DI, PK DEV / SK DEV of the corresponding device, the list of challenge response value pairs, and the measurement value of the bootable image in a secure database.
[0088] (2) Step 2, user-controlled vTPM registration;
[0089] Step 2 includes:
[0090] (2-1) The user requests the TTP to generate a key pair: PK TPM and SK TPM , and generate a certificate: Ca(PK TPM );
[0091] (2-2) The TTP stores the user's PK TPM / SK TPM and information such as Ca(PK TPM ) in a secure database;
[0092] (3) Step 3, the device starts up, including the power-on of the FPGA-SoC and the trusted boot, as well as the startup of the user's vTPM instance;
[0093] The specific steps of Step 3 are as follows:
[0094] (3-1) The FPGA-SoC securely loads the bootable image generated by the TTP. Among them, the BootROM measures and executes the bitstreams of the securely customized FSBL, SRAM PUF, PMU_FW, ATF, OP-TEE, U-Boot, Linux, and Rootfs respectively, and generates verification information;
[0095] (3-2) The vTPM starts up, obtains the information of the FPGA-SoC device from the TTP, including #DI, the list of challenge-response value pairs, the measurement value of the bootable image, PK TMM . After the vTPM completes its initialization, it starts an incrementing counter.
[0096] (4) Step 4, remote authentication and session key generation;
[0097] The specific steps of Step 4 are as follows:
[0098] (4-1) The vTPM starts to generate a random number r0 for this communication;
[0099] (4-2) The vTPM sends an authentication request to the TMM of the FPGA-SoC, including the public key certificate Ca(PK TPM ) of the vTPM, the challenge value C1 of the PUF, and the random number r0;
[0100] (4-3) The TMM first verifies the public key certificate, and then generates a key pair PK ATTEST / SK ATTEST for this authentication process. Further, the TMM generates verification information H1 containing the measurement data of the bootable image;
[0101] (4-4) The TMM uses C1 as a challenge to call the SRAM PUF to obtain a response R1;
[0102] (4-5) The TMM generates a session key containing H1 and R1, and generates response information H2;
[0103] (4-6) The vTPM verifies H2, and generates the corresponding session key after passing the verification.
[0104] (5) Step 5, user IP deployment;
[0105] Step 5 is as follows:
[0106] (5-1) The user sends a request to the vTPM to deploy the IP. This request should include information about the IP, such as the IP encryption key, etc.;
[0107] (5-2) The vTPM obtains the encrypted IP bitstream, encryption key, and hash value of the IP according to the request, generates the corresponding signature, and sends it to the TMM;
[0108] (5-3) The TMM verifies the signature, and after passing the verification, calls the interface in the OP-TEE kernel to deploy the IP and measure the process;
[0109] (5-4) After successful deployment, the TMM sends the encrypted measurement value to the vTPM for verification;
[0110] (5-5) The vTPM verifies the measurement value, extends the value to PCR8, and finally returns the response information.
[0111] (6) Step 6, user IP call;
[0112] Step 6 is as follows:
[0113] (6-1) The user sends a request to the vTPM to call the IP. This request should include information about the IP, input data, address, output address, etc.;
[0114] (6-2) The vTPM measures the input data according to the request and extends it to PCR9;
[0115] (6-3) The vTPM encrypts the address and data and sends them to the TMM;
[0116] (6-4) After the TMM decrypts, it calls the interface in the OP-TEE kernel to call the IP to obtain the output;
[0117] (6-5) The TMM calculates the measurement of the output, encrypts the output data and the measurement value, and sends them to the vTPM;
[0118] (6-6) The vTPM verifies the measurement value, extends the value to PCR10, and finally returns the output information.
[0119] Thus, the process of the user deploying the user's IP on an FPGA-SoC device on an untrusted cloud service provider and making a call is completed.
[0120] The above examples are only used to illustrate the technical method of the present invention rather than limit it. Those of ordinary skill in the art can modify the technical solution of the present invention or make equivalent substitutions without departing from the spirit and scope of the present invention. The protection scope of the present invention shall be subject to the claims.
Claims
1. An FPGA-vTPM architecture that combines vTPM supporting TPM 2.0 with FPGA-SoC, characterized in that, The architecture includes: Four components for constructing the FPGA-vTPM architecture; An initialization scheme for initializing the FPGA-vTPM architecture and securely generating session keys; A key update scheme for securely updating session keys.
2. The architecture according to claim 1, wherein The four components include: SRAM PUF, which is used to provide a truly random number seed to generate a security key, and authenticate the device using the challenge-response process with the characteristics of PUF; Trusted Management Module (TMM), which provides TPM management and FPGA-SoC management functions; TPM management includes functions such as vTPM initialization and authentication, and session key update; FPGA-SoC management includes the trusted boot scheme of FPGA-SoC, secure verifiable deployment, and user IP call functions; TPM proxy, which is used to forward encrypted TPM commands and responses; vTPM, which runs on user nodes supporting the full TPM 2.0 standard and extends the functions of the FPGA-SoC TEE.
3. The architecture according to claim 1, characterized in that The initialization scheme includes: Device registration phase, including: FPGA-SoC registration includes that a trusted third party (TTP) generates a device key pair and burns it into the BBRAM, generates a customized bootable image, and generates authentication information; User vTPM registration includes generating vTPM device keys and authentication information; Device startup phase, including: FPGA-SoC startup, securely loading the bootable image generated by the TTP and generating verification information; The user's vTPM instance starts up, obtains the FPGA-SoC authentication information from the TTP and initializes the vTPM; Remote authentication and session key generation phase, including: The vTPM starts to generate a random number r0 for this communication; The vTPM sends an authentication request to the TMM of the FPGA-SoC, including the public key certificate Ca(PK TPM ) of the vTPM, the challenge value C1 of the PUF, and the random number r0; The TMM first verifies the public key certificate and then generates a key pair PK ATTEST / SK ATTEST for this authentication process. Further, the TMM generates verification information H1 containing measurement data of the bootable image; The TMM uses C1 as a challenge to call the SRAM PUF to obtain the response R1; The TMM generates a session key containing H1 and R1, and generates response information H2; The vTPM verifies H2, and after passing, generates the corresponding session key.
4. The architecture according to claim 1, wherein The key update scheme includes: The vTPM concatenates the values from PCR0 to PCR23 to calculate H PCR as the current system state; The vTPM generates an H1 that contains H PCR and the device ID (#DI), and selects a new pair of challenge-response value pairs (C2 and R2); The vTPM combines H1 and R2 to generate a new session key; The vTPM sends H1 and C2 to the TMM for verification; The TMM calculates the new session key and encrypts R2 and sends it to the vTPM to enable the new session key.
5. A secure enhanced runtime customizable FPGA-SoC TEE system based on the FPGA-vTPM architecture, characterized in that, The system includes: FPGA-SoC trusted boot scheme supported by TPM 2.0 for supporting the trusted boot and remote authentication of FPGA-SoC; IP deployment scheme supported by TPM 2.0 for dynamically verifiable deployment of user IP at runtime; IP call scheme supported by TPM 2.0 for dynamically verifiable call of user IP at runtime.
6. The system according to claim 5, wherein The FPGA-SoC trusted boot scheme supported by TPM 2.0 includes: using BootROM as the CRTM, respectively measuring and executing the bitstreams of securely customized FSBL, SRAM PUF, PMU_FW, ATF, 0P-TEE, U-Boot, Linux, and Rootfs, and extending them to PCR0 to PCR7 of the vTPM.
7. The system according to claim 5, wherein The IP deployment scheme supported by TPM 2.0 includes: The user sends a request to deploy an IP to the vTPM, and this request should include information about the IP, such as the IP encryption key, etc.; The vTPM obtains the encrypted IP bitstream, the encryption key, and the hash value of the IP according to the request, generates a corresponding signature and sends it to the TMM; The TMM verifies the signature. After passing, it calls the interface in the 0P-TEE kernel to deploy the IP and measures this process; After the deployment is successful, the TMM sends the encrypted measurement value to the vTPM for verification; The vTPM verifies the measurement value, extends this value to PCR8, and finally returns the response information.
8. The system according to claim 5, wherein The IP invocation scheme supported by TPM 2.0 includes: The user sends a request to invoke an IP to the vTPM, and this request should include information about the IP, the input data, address, output address, etc.; The vTPM measures the input data according to the request and extends it to PCR9; The vTPM encrypts the address and data and sends them to the TMM; After the TMM decrypts, it calls the interface in the 0P-TEE kernel to invoke the IP to obtain the output; The TMM calculates the measurement of the output, encrypts the output data and the measurement value and sends them to the vTPM; The vTPM verifies the measurement value, extends this value to PCR10, and finally returns the output information.
9. An extended TPM command and response set compliant with the TPM2.0 specification, characterized in that, The system includes: The session key dynamic update command and response of the FPGA-vTPM architecture compliant with the TPM 2.0 specification; The dynamically verifiable user IP deployment command and response of the FPGA-vTPM architecture compliant with the TPM 2.0 specification; The dynamically verifiable user IP invocation command and response of the FPGA-vTPM architecture compliant with the TPM 2.0 specification.