Two-stage authorization management and control method for trusted execution environment based on HSM

Abstract

The invention discloses an HSM-based trusted execution environment two-stage authorization management and control method, which establishes a hardware-level two-factor authorization architecture, simultaneously solves the problems of access control and data sovereignty guarantee in a TIPU trusted execution environment through physical UKey binding and a cryptographic policy chain, breaks through the defect that a traditional TEE cannot give consideration to both system security and data security, and improves the reliability of the TIPU trusted execution environment. And a new normal form is provided for privacy calculation in combination with the TIPU. As an important component in a TIPU trusted execution environment system, the architecture can be widely applied to scenes such as data elements and intelligent model training and promotion, provides data privacy protection for the scenes, is high in technical innovation, has leading performance, can promote development of related industries, and has extremely high commercial value.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, in particular to a two-level authorization management and control method for a trusted execution environment based on a hardware full module HSM. BACKGROUND

[0002] The current trusted execution environment (TEE) technology has the following security risks: 1. Coarse access control: traditional TEE lacks end-to-end access control from the management end to the computing end, and the interface exposure risk is high; 2. Loss of data sovereignty: user data is easily lost in the sharing process, and existing encryption mechanisms cannot achieve fine-grained dynamic management and control. The TIPU board card provides a hardware trusted root and file virtualization offloading (with encryption and decryption capabilities) to improve security, but still needs to solve the problem of cross-level authorization and data sovereignty separation. SUMMARY

[0003] The purpose of the present application is to provide a two-level authorization management and control method for a trusted execution environment based on HSM to solve the access control and data sovereignty problems in the trusted execution environment technology, and to achieve: 1) end-to-end controlled access of TIPU interfaces in the trusted execution environment system; 2) controlled sharing of user data in the trusted sandbox, which ensures that the data ownership is never transferred, and the operation instructions of the sandbox are trusted throughout the link.

[0004] The technical solution of the present application is as follows: A two-level authorization management and control method for a trusted execution environment based on HSM, applied to a trusted computing system with a DPU / TIPU architecture, includes the following steps: First-level board card access control: generate an asymmetric key pair through HSM / UKey physically connected to the TIPU board card , and all board card interface calls need to be attached with a UKey signed authorization token, and the TIPU board card dynamically verifies the token signature through a preset certificate chain, and returns a hardware error code 0xE0_ACCESS_DENIED for unauthorized access; Second-level data sovereignty control: generate a file key through a user UKey Encrypt the data, and the trusted sandbox sends a dynamic authorization request to the user UKey, and the TIPU board card verifies the time window, geofencing and application fingerprint based on the policy engine, and releases the key within the time limit after verification, otherwise triggers the key self-destruction.

[0005] Further, the first-level board card access control further includes: ​The UKey is bound to the hardware trusted root TCM of the TIPU board card to form a multi-level verification chain from T-UKey to TIPU TCM to Host vTCM to U-UKey to a trusted sandbox, and the verification result is cross-verified in the trusted sandbox.

[0006] Further, the dynamic authorization request comprises: An application fingerprint of the user is used to generate an SGX remote attestation report; Geofencing information, including physical nodes and TIPU, is verified by a hardware signature of a GPS module integrated in the TIPU board card; A time window parameter is checked by a secure clock inside the HSM in [t_start, t_end].

[0007] Further, the key self-destruction is implemented by the following method: The policy engine of the TIPU board card sends an overwrite instruction to the HSM to physically overwrite the storage area, and generates a self-destruction audit log.

[0008] Further, the encrypted data is generated by the following method: The user UKey generates a file key , and then encrypts the data file when uploading the data file, so that the data file is stored in the secure storage area in the form of ciphertext, and the ciphertext storage formula is: , which includes: user ID, ownership policy hash.

[0009] Further, it also includes: creating a zero-trust data channel through the SR-IOV or vDPA virtualization offload technology of the TIPU board card, which enables the cooperative signature of the board card UKey and the user UKey to be verified at the same time.

[0010] Further, the policy engine performs the following: The backend secure storage accesses the TIPU board card in the network file system protocol, and a virtualized file system device is created by the TIPU and directly passed to the trusted sandbox on the host; The data access control policy is executed in the trusted and closed environment of the TIPU; according to the dynamic authorization rules, the use time period, the user and the trusted sandbox, and the sandbox running physical node are limited, and when all the rule conditions are met, the key exchange and decryption are completed , and finally the data file is decrypted under control, otherwise the key is self-destructed and the data copy is cleaned up.

[0011] Further, the data sovereignty adopts a three-ownership separation model: Ownership: controlled by user UKey key generation; usage rights: controlled by TIPU board card policy execution engine dynamic authorization; operation rights: controlled by management center audit log, real-time monitoring of key life cycle.

[0012] Further, the operation rights also include: when the policy engine detects abnormal operation, triggering the TIPU board card hardware fuse mechanism to interrupt the data channel, and writing the audit log to the blockchain after signing by the user UKey.

[0013] The application also includes a two-level authorization management system based on a HSM trusted execution environment, using a two-level authorization management method based on a HSM trusted execution environment, comprising: The TIPU board card and the HSM module are physically bound; User UKey and key management service; Trusted sandbox integrated with policy execution engine; Multi-level verification chain module based on hardware trusted root (TCM).

[0014] Compared with the existing technology, the beneficial effects of the present application are: 1. Improved security performance: 100% interception rate of illegal interface access (hardware level rejection, complete and perfect security access mechanism); significantly reduced data leakage risk (based on NIST SP 800-193 test); 2. Sovereignty protection innovation: first to create a hardware-enforced ownership separation model; support for "one-time password" dynamic authorization (RFC 4226 HOTP evolution). BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 The figure is a schematic diagram of the overall architecture of the application.

[0016] Figure 2 The figure is a flowchart of the authorization mechanism of the application. DETAILED DESCRIPTION

[0017] It should be noted that the terms "first" and "second" and the like relational terms are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without further limitation, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.

[0018] The features and performance of the present application will be further described in detail below in connection with embodiments.

[0019] Please refer to Figures 1-2 , a two-level authorization management method based on HSM trusted execution environment, as Figure 2 shown, applied to DPU / TIPU architecture trusted computing system, comprising the following steps: First-level board access control (end-to-end trusted) : Exclusive HSM (also known as UKey) supports SKF standard, generates asymmetric key pair by digital certificate system , where the private key is protected by hardware protection mechanism and cannot be read out of the domain; Physical binding: each TIPU board card is inserted into the UKey, and the TIPU and its UKey are bound by the system super administrator during the initialization of the trusted execution environment system, and an authorization token is generated, signed by the UKey and securely stored therein; System authorization: the trusted execution environment system authorizes the system management center and virtualization service components as the legal requesters of TIPU by default, and grants them tokens; Encrypted request: when the management center and virtualization service call the TIPU interface, the request parameters are encrypted by the authorization token; Interface authentication: all external interface calls on the board card need to be authenticated and verified by the authorization token signed by the UKey on the board card; Interception mechanism: the legal request verification of the management center and virtualization service will pass, and unauthorized access requests will directly return a hardware error code 0xE0_ACCESS_DENIED, the request is intercepted, realizing the access security between each component in the trusted execution environment system and the hardware, ensuring the end-to-end access trust.

[0020] Second-level data sovereignty control (three rights separation) : User binding: the ordinary users of the trusted execution environment system are created by the super administrator and each user is bound to a dedicated UKey, i.e. user UKey; Data encryption: the user UKey generates a file key , and then encrypts the data file when uploading the data file , the data file is stored in the secure storage area in ciphertext, and the ciphertext storage formula is: , including: user ID, ownership policy hash, etc. Dynamic authorization: When data is used, the trusted sandbox (data user) sends an authorization request to the user UKey, including: application fingerprint, geofencing (physical node, TIPU, etc.) information, time window (start and end time ) and the like; Policy execution: After the backend security storage accesses the TIPU board card in the network file system protocol (such as NFS, etc.), the TIPU creates a virtual file system device and directly passes it to the trusted sandbox on the host, and the data access control policy is executed in the TIPU trusted and closed environment. According to the dynamic authorization rule, the use time period, the user and his trusted sandbox (including the application), the sandbox running physical node and the like are limited, when all the rule conditions are met, the key exchange and decryption are completed , and finally the data file is decrypted under control, otherwise the key is self-destroyed and the data copy is cleaned up; Instant destruction: After the data is used by the application in the specified trusted sandbox, the expired trusted sandbox, data copy and temporary key are automatically destroyed.

[0021] Through the above method, the following is achieved: Hardware-level trust chain extension: The certificate chain of the TIPU board card UKey is bound with the virtual trusted root, realizing multi-level verification of T-UKey->TIPU TCM->Host vTCM->U-UKey->trusted sandbox, and the control chain and data chain verification finally converge in the trusted sandbox and support each other.

[0022] Data three rights separation model:

[0023] Zero trust data channel: A VirtIO device is created through the virtualization offloading technology such as SR-IOV and vDPA of the TIPU board card to build a data direct channel, and the channel needs to be authorized by double UKey (board card UKey and user UKey).

[0024] As shown in Figure 1 , the application further includes a two-level authorization management system based on a HSM trusted execution environment, and uses a two-level authorization management method based on a HSM trusted execution environment, including: The TIPU board card and the HSM module are physically bound; User UKey and key management service; Trusted sandbox integrated with policy execution engine; Multi-level verification chain module based on hardware trusted root (TCM).

[0025] In another specific embodiment, the data sharing scenario flow is as follows: 1. Researcher Alice inserts the user UKey to upload genetic data (automatically encrypted); 2. Hospital BioAPP application use data, trigger authorization request; 3. Alice approval: Beijing machine room only (geofencing), 72 hours (time limit); 4. TIPU board card: Verify BioAPP hash value (tamper-proof); Confirm server GPS location; Dynamically release the key to the trusted sandbox; 5. Key is automatically destroyed at the end of use, and audit logs are stored on the chain.

[0026] The above-described embodiments only express the specific implementation of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the protection scope of the present application. It should be pointed out that for ordinary skilled persons in the art, without departing from the technical concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application.

Claims

1. A method for two-level authorization management based on HSM trusted execution environment, characterized in that, A trusted computing system applied to a DPU / TIPU architecture, comprising the following steps: First level board card access control: Asymmetric key pair generated by HSM / UKey physically plugged into TIPU board card All board card interface calls require a UKey signed authorization token, TIPU board card dynamically verifies token signature through pre-installed certificate chain, unauthorized access returns hardware error code 0xE0_ACCESS_DENIED; Second level data sovereignty control: file key generated by user UKey Encrypt data, trusted sandbox sends dynamic authorization request to user UKey, TIPU board card verifies time window, geofence and application fingerprint based on policy engine, and releases in time after verification , otherwise trigger key self-destruction.

2. The two-level authorization management method based on the HSM trusted execution environment according to claim 1, characterized in that, The first-level board card access control further comprises: The UKey is bound to the hardware trusted root TCM of the TIPU board card to form a multi-level verification chain from T-UKey→TIPU TCM→Host vTCM→U-UKey→trusted sandbox, and the verification result is cross-verified in the trusted sandbox.

3. The two-level authorization management method based on the HSM trusted execution environment according to claim 1, characterized in that, The dynamic authorization request comprises: The application fingerprint is generated based on the SGX remote attestation report; The geofencing information comprises physical nodes and TIPUs, and is verified by hardware signature of a GPS module integrated in the TIPU board card; The time window parameter is checked by a secure clock inside the HSM [t_start, t_end].

4. The two-level authorization management method based on the HSM trusted execution environment according to claim 1, characterized in that, The key self-destruction is achieved by the following method: The TIPU board's policy engine sends overwrite commands to the HSM, physically overwriting... The storage area is set up, and a self-destruct audit log is generated.

5. The two-level authorization management method based on HSM trusted execution environment according to claim 1, characterized in that, The encrypted data adopts the following method: User UKey generates file key Then when uploading data file, by encryption The data file, the data file is stored in the form of ciphertext in the secure storage area, and the ciphertext storage formula is: , Including: user ID, right ownership policy hash.

6. The HSM-based trusted execution environment two-level authorization management method according to claim 1, characterized in that, Further comprising: A zero-trust data channel is created by SR-IOV or vDPA virtualization offloading technology of the TIPU board card, and the channel enables the cooperative signature of the board card UKey and the user UKey.

7. The two-level authorization management method of a trusted execution environment based on an HSM according to claim 1 or 4, characterized in that, The policy engine performs the following: After the backend secure storage accesses the TIPU board card in the network file system protocol, the TIPU creates a virtualized file system device and directly passes it to the trusted sandbox on the host; The data access control policy is executed in the TIPU trusted and closed environment; according to the dynamic authorization rules, the use time period, the user and the trusted sandbox, the sandbox running physical node are limited, when all the rule conditions are met, the key exchange and unsealing are completed to obtain , and finally the data file is decrypted under control, otherwise the key is self-destroyed and the data copy is cleaned.

8. The two-level authorization management method of a trusted execution environment based on an HSM according to claim 1, characterized in that, The data sovereignty adopts a three-ownership separation model: Ownership: controlled by the user UKey to generate keys; usage right: controlled by the policy execution engine of the TIPU board card to dynamically authorize; operation right: controlled by the management center to audit logs and monitor the key life cycle in real time.

9. The HSM-based trusted execution environment two-level authorization management method of claim 8, wherein, The operation right further comprises: when the policy engine detects abnormal operation, the hardware fuse mechanism of the TIPU board card interrupts the data channel, and the audit log is written into the blockchain after being signed by the user UKey. 10.A two-level authorization management system based on HSM trusted execution environment, characterized in that, A two-level authorization control method based on the HSM trusted execution environment according to any one of claims 1-9, comprising: The physically bound TIPU board card and HSM module; The user UKey and key management service; The trusted sandbox integrated with the policy execution engine; The multi-level verification chain module based on the hardware trusted root (TCM).

Images