Auditable key management method based on trusted execution environment

Abstract

The invention discloses an auditing key management method based on a trusted execution environment, which comprises the following steps that: a data provider encrypts original data by using k to obtain a ciphertext C, and calculates a hash value id of the C; t; id, kgt; storing the result in association locally, and storing the result; d, Cgt; uploading to a cloud server; the data provider formulates and signs a data use strategy, the data processor formulates and signs a data processing strategy, and the data use strategy and the data processing strategy are both sent to the security service program of the trusted execution environment; verifying the signature and the authorization state of the processing strategy, and sending a key request and a remote authentication report to a data provider; after the data provider remotely verifies the remote report, if the request is agreed, the key k is sent to the security service program through the security channel, and a key use record is stored in the block chain; and the security service program downloads the ciphertext C, decrypts the data after verification, executes processing operation, and returns an encryption result to a specified receiver. According to the invention, real-time auditing and evidence storage can be carried out on the use process of the secret key, and cross-domain management and control of data can be realized.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and more specifically, to an auditable key management method based on a trusted execution environment. Background Art

[0002] At present, against the backdrop of the rapid growth of the digital economy, data, as a new type of production factor and the foundation of digitalization, networking, and intelligence, has quickly integrated into all aspects such as production, distribution, circulation, consumption, and social service management, profoundly changing production methods, lifestyles, and social governance methods. However, in real life, data often contains various privacy information of enterprises and users, making it very difficult to collect and circulate data elements. With the development of trusted execution environment technology, new solutions have been provided for the circulation, processing, and processing of data elements. Users store their encrypted data and keys in the trusted execution environment. For the trusted execution environment, implementing a user key management scheme that can be audited in real time is a very valuable issue.

[0003] The trusted execution environment can ensure the privacy and security of data during the execution process through hardware means, ensuring that the user's original data will not be leaked. The trusted execution environment is a very important technology in the field of information security.

[0004] In most existing key management solutions for the trusted execution environment, ciphertext data and decryption keys are usually stored in the trusted execution environment. The data provider cannot realize real-time audit management of each key usage, so there are still some limitations. For example, when data is authorized to multiple data processing parties, the data provider can only know the general range of data users, but cannot determine the specific identity of the users and the specific number of times the data is used in real time, which brings some potential risks to cross-domain control and real-time key management of data. Summary of the Invention

[0005] In view of this, the present invention provides an auditable key management method based on a trusted execution environment, which ensures the security of user data and keys during the data flow process, and at the same time can audit and store the key usage process in real time to achieve cross-domain control of data.

[0006] To achieve the above object, the present invention adopts the following technical solutions:

[0007] The present invention provides an auditable key management method based on a trusted execution environment, including the following steps:

[0008] S1. The data provider generates an asymmetric key pair (sk, pk) and a symmetric key k, uses k to encrypt the original data to obtain ciphertext C, and calculates the hash value id of C;

[0009] S2. The data provider stores the <id, k> association locally and uploads <id, C> to the cloud server;

[0010] S3. The data provider formulates a data usage policy and signs it, and after signing with sk, sends it to the security service program in the trusted execution environment together with pk;

[0011] S4. The data processor formulates a data processing policy and signs it, and sends it to the security service program in the trusted execution environment;

[0012] S5. The security service program in the trusted execution environment verifies the signature and the authorization status of the processing policy, and sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider;

[0013] S6. After the data provider remotely verifies the remote authentication report, if it agrees to the request, it sends the key k to the security service program through a secure channel and stores the key usage record on the blockchain;

[0014] S7. The security service program downloads the ciphertext C from the cloud server, decrypts the data after verifying that id = hash(C), performs the processing operation, and encrypts the result and returns it to the specified recipient.

[0015] In one embodiment, in step S3, the data usage policy includes:

[0016] Authorized usage participants, authorized types of processing operations, hash values corresponding to the ciphertext data, cloud service addresses where the ciphertext data is stored, data usage scope, and recipients of data processing results.

[0017] In one embodiment, in step S4, the data processing policy includes: the specific method of processing, processing parameters, data required for processing, recipient of the processing result, and its own signature.

[0018] In one embodiment, step S5 includes:

[0019] S51. The security service program in the trusted execution environment uses the public key to verify whether the signatures of the data provider and the data processor are correct; and checks whether the processing data required in the data processing policy has been authorized for use;

[0020] S52. If the authorization is verified, the security service program requests the corresponding ciphertext data from the cloud server according to the data authorization policy;

[0021] S53. The cloud server sends the corresponding ciphertext hash value and ciphertext <id, C> to the security service program according to the request of the security service program;

[0022] The security service program determines whether there is fraud in the cloud server by verifying whether id = hash(C). If so, the service is stopped;

[0023] The security service program sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider.

[0024] In one embodiment, in step S5, the remote authentication report includes:

[0025] The identity information of the data processor, the unique identifier of the trusted execution environment, the hash value of the execution program, and is signed by the hardware private key of the trusted execution environment.

[0026] In one embodiment, in step S6, the blockchain evidence storage includes:

[0027] Timestamp, data provider identifier, key identifier, operation type, digital signature;

[0028] Automatically verified and written into the blockchain network through a smart contract.

[0029] In one embodiment, step S7 further includes: After the decrypted data is processed in the security service program of the trusted execution environment, it is destroyed.

[0030] In one embodiment, in step S1, the symmetric encryption algorithms adopted include the national cipher SM4 and AES; the asymmetric encryption algorithms include the national cipher SM2 and the quantum-resistant cryptography algorithm.

[0031] From the above technical solutions, it can be seen that compared with the prior art, the present invention discloses the following technical effects:

[0032] 1. The data key of the data provider is stored locally and instantaneously requested by the security service program in the trusted execution environment. The user can instantaneously audit and store evidence for the data user. Once the data provider no longer trusts the data processor, the data flow can be terminated immediately, effectively realizing cross-domain control during the data flow process.

[0033] 2. In the present invention, the data provider stores the encrypted original data in the cloud server and only maintains the hash value corresponding to the ciphertext data and the key locally, greatly saving local storage resources. Since the cloud server cannot obtain the decryption key, the user's original data is guaranteed not to be cracked. Even if the cloud server has malicious behavior and tampers with the ciphertext data, the user or the security service program can also verify the integrity of the data by verifying whether the hash values are the same.

[0034] 3. The decryption and processing of data are both performed in a trusted execution environment. The data provider can ensure that during the data processing, neither the security service program nor the trusted execution environment has been attacked by external adversaries through means such as starting measurement and remote authentication reports, thereby ensuring the privacy and security of its own data and ensuring that the recipient of the result can only obtain the processed data result and not the original data. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0036] Figure 1 It is a flowchart of an auditable key management method based on a trusted execution environment provided by the present invention.

[0037] Figure 2 It is a flowchart of the interaction of multiple parties involved in the method provided by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0039] The embodiments of the present invention disclose an auditable key management method based on a trusted execution environment. In specific implementation, the entities involved include: users, cloud servers, trusted execution environments, and blockchain networks;

[0040] Among them, the user provides data and implements key management, and the user can be further divided into a data provider and a data processing and using party (the identities of the two can coexist);

[0041] The data provider is used to generate keys, encrypt data, formulate authorization policies, and audit and store evidence;

[0042] The data processor is used to submit a processing request and provide a processing strategy;

[0043] The cloud server provides storage services and stores ciphertext data;

[0044] The trusted execution environment (TEE) provides computing services, including: performing secure computing, verifying policies, and managing key requests.

[0045] Blockchain network: Record of the use of the deposit key (such as Hyperledger Fabric).

[0046] Refer to Figure 1 as shown, specifically including:

[0047] S1. The data provider generates an asymmetric key pair (sk, pk) and a symmetric key k, encrypts the original data with k to obtain the ciphertext C, and calculates the hash value id of C;

[0048] S2. The data provider stores <id, k> locally in an associated manner and uploads <id, C> to the cloud server;

[0049] S3. The data provider formulates a data usage policy and signs it, and sends it to the security service program in the trusted execution environment after signing with sk and together with pk;

[0050] S4. The data processor formulates a data processing policy and signs it, and sends it to the security service program in the trusted execution environment;

[0051] S5. The security service program in the trusted execution environment verifies the signature and the authorization status of the processing policy, and sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider;

[0052] S6. After the data provider remotely verifies the remote authentication report, if it agrees to the request, it sends the key k to the security service program through a secure channel and records the use of the deposit key in the blockchain;

[0053] S7. The security service program downloads the ciphertext C from the cloud server, decrypts the data after verifying that id = hash(C), performs the processing operation, and encrypts the result and returns it to the specified recipient.

[0054] This method ensures the data security and key security of users during the data flow process. At the same time, it can audit and deposit the key usage process in real time, and realize cross-domain control of data.

[0055] The above S1 - S7 are described in detail through the following 18 refined sub - steps:

[0056] 1. The data provider generates a pair of asymmetric keys <sk, pk> and a symmetric key k locally. The symmetric encryption algorithm used supports multiple symmetric encryption algorithms such as the national cipher SM4 and AES. The asymmetric encryption algorithm used by the user also supports multiple asymmetric encryption algorithms including SM2 and post - quantum cryptography algorithms.

[0057] 2. The data provider encrypts the original plaintext data into C using the symmetric encryption algorithm and the key k.

[0058] 3. The data provider uses a hash algorithm to map the ciphertext C to an id.

[0059] 4. The data provider saves the id corresponding to the ciphertext mapping and the encryption key k in an associated form of <id, k> locally.

[0060] 5. The data provider sends the ciphertext C and the hash value id of the ciphertext mapping to the cloud server for storage.

[0061] 6. The data provider formulates the usage policy for the original data, including the parties authorized to use the data, the types of operations that can be performed, the hash value corresponding to the ciphertext data, the cloud service address corresponding to the ciphertext data, the data usage scope, and the recipient of the data processing result.

[0062] 7. The data provider signs the usage policy and sends the usage policy and the public key pk to the trusted execution environment.

[0063] 8. If the data processor is also the data provider, it needs to repeat steps 1 - 7.

[0064] 9. The data processor formulates the policy for data processing, including the specific processing method, processing parameters, data required for processing, the recipient of the processing result, and its own signature.

[0065] 10. The data processor sends the data processing policy and its own signature to the security service program in the trusted execution environment.

[0066] 11. The security service program in the trusted execution environment uses the public key to verify whether the signatures of the data provider and the data processor are correct.

[0067] 12. The security service program in the trusted execution environment checks whether the processing data required in the data processing policy has been authorized for use.

[0068] 13. If the authorization is verified successfully, the security service program requests the corresponding ciphertext data from the cloud service according to the data authorization policy.

[0069] 14. The cloud server sends the corresponding ciphertext hash value and the ciphertext <id, C> to the security service program according to the request of the security service program.

[0070] 15. The security service program determines whether the cloud server has fraudulent behavior by checking whether id = hash(C) is equal. If so, it stops the service.

[0071] 16. The security service program sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider. After the data processor submits a data processing policy to the security service program in the trusted execution environment, the security service program generates an authentication request. The remote authentication report includes: the identity information of the data processor, the unique identifier of the trusted execution environment, and the hash value of the execution program. The trusted execution environment signs it using its own unique private key built into the hardware and sends it to the data provider.

[0072] 17. The data provider verifies the remote authentication report. After receiving the remote authentication report sent by the security service program, the data provider uses the public key of the trusted execution environment hardware to verify the digital signature of the report to ensure the authenticity and integrity of the report.

[0073] The data provider and the trusted execution environment use advanced encryption protocols (such as TLS / SSL) to protect the confidentiality and integrity during data transmission. TLS / SSL establishes a secure session through the handshake protocol to ensure that data is not eavesdropped or tampered with during transmission. It verifies the identities of both communication parties through a mutual authentication mechanism (such as client certificate authentication) to ensure that only legitimate entities can access the secure channel and refreshes the session key regularly to ensure that even if the session key is leaked, attackers cannot decrypt the previous session data. If the data provider agrees to the data processor's use of the data, it sends the symmetric key k to the security service program in the trusted execution environment through the secure channel and instantaneously stores the record of key usage locally. To ensure the immutability and transparency of the key usage record, this solution uses blockchain technology for the instant storage of key usage records.

[0074] The data provider stores the key usage record through a suitable blockchain network (such as Hyperledger Fabric, Ethereum, or a self-built consortium chain). The format of the key usage record includes, but is not limited to:

[0075] Timestamp: Records the specific time of key usage;

[0076] Data provider identifier: The unique identifier of the data provider;

[0077] Key identifier: The unique identifier of the key;

[0078] Operation type: The specific operation of key usage (such as transmission, decryption, etc.);

[0079] Signature information: The digital signature of the data provider for the record content to ensure the authenticity and integrity of the record, as well as the number of times the data has been used.

[0080] The data provider configures the corresponding smart contract, which can automatically execute the predetermined rules on the blockchain to ensure the consistency and integrity of the data. Whenever a key usage event occurs, the data provider immediately writes the record to the blockchain through the smart contract. The smart contract will automatically verify the integrity of the record and the validity of the signature. The data provider and other authorized relevant entities can query the key usage records through the smart contract to ensure the transparency and traceability of the records. If the data provider no longer trusts the data processor, it will refuse to provide the decryption key, and the service will terminate immediately.

[0081] 18. After waiting for all data providers to return the decryption keys, the security service program decrypts the ciphertext data used in the processing policy and performs the corresponding data processing operations. All data processing is executed in a trusted execution environment. After the decrypted data is used, it is destroyed by the security service program. After successful execution, the security service program verifies the authorization policy of the data used, checks whether the verification results are consistent with the recipient, and encrypts the processing results using the public key of the specified participating party (the public key was provided at the beginning stage) and returns them to the result recipient specified by the authorization policy.

[0082] In this embodiment, the data processor hopes to use the data of the data provider for data processing and analysis. However, for the data provider, it does not want its original data to be obtained by the data processor and only hopes that the data processor can obtain the processed data results. During the data processing, the data provider can immediately audit and retain evidence for each data processing request made by the data processor. At the same time, to save local storage resources, the data provider stores the ciphertext data in the cloud server.

[0083] In the solution, the user uses technologies such as symmetric encryption, hash algorithms, asymmetric encryption algorithms, blockchain, and trusted execution environments to ensure the secure storage of data provided by the data provider and the management and auditing of keys. First, the data provider encrypts all the original data through a symmetric encryption algorithm, ensuring the encryption efficiency at the user side. At the cloud storage server, the cloud server obtains the <id, C> data encrypted by the symmetric encryption algorithm. Without the private key, the cloud server cannot obtain any privacy information from the ciphertext. The security service program in the trusted execution environment can ensure that the ciphertext data sent by the cloud server has not been tampered with by verifying whether the hash value of the ciphertext has changed. Through the above means, the storage resources required by the data provider locally can be greatly saved, and at the same time, the security and availability of the data are ensured. When processing data, each processing request of the data processor will be sent by the security service program to the data provider. The data provider can verify the security of the security service program and the trusted execution environment in real time to ensure the security of the data during program execution. At the same time, the data provider can record evidence for each decryption request to ensure the traceability of the data flow process.

[0084] As Figure 2 shown, in this example, there is a data provider A, a data processor B, a trusted execution environment, and a cloud server (which may have malicious behavior). During this process, it is assumed that all data providers and data processors have negotiated offline in advance to synchronize the necessary information, as well as the measurement values of the trusted execution environment and the security service program for subsequent verification.

[0085] 1) The data provider A and the data processor B respectively generate a pair of public and private keys locally , , and the private key and save them locally.

[0086] 2) The data provider A and the data processor B respectively use their own key pairs to symmetrically encrypt the original data to obtain . Next, the data provider A and the data processor B respectively perform a hash operation on the ciphertext and to obtain .

[0087] 3) The data provider A and the data processor B respectively maintain the hash value of the mapped ciphertext and the corresponding symmetric key locally.

[0088] 4) The data provider A and the data processor B send their respective ciphertexts and the hash values corresponding to the ciphertexts to their respective cloud servers for storage.

[0089] 5) Data providers A and B formulate signature policies for their respective data, specifying information such as the authorized users of the data, the processing operations authorized for use, the hash value corresponding to the ciphertext data, the service interface where the ciphertext data is stored, and the recipient of the data processing result. Data providers A and B sign their respective authorization files.

[0090] 6) Data providers A and B respectively send their data authorization policies, authorization policy signatures, and public keys to the security service program in the trusted execution environment. The security service program verifies whether the signature is correct and saves the authorization policy.

[0091] 7) Data processor B formulates a data processing policy, specifying the data to be used during the processing, the processing operations selected in the security service program, the recipient of the processing result, and the signature authentication information of its own identity. Data processor B signs the data processing policy and sends the signed processing policy to the security service program. The security service program verifies whether the signature is correct and saves the authorization policy.

[0092] 8) After receiving the data processing instruction from the data processor, the security service program in the trusted execution environment detects the input data required in the processing policy and checks whether there is an authorization policy file for this data in the trusted execution environment. If not, the service is terminated. If so, it authorizes all the required authorization policy files for the input data, verifies whether the data processing operation and the data processor corresponding to this data processing operation are authorized to use the data. If the verification is successful, it sends a decryption request, a remote authentication report, and the data signature of the data processor to the corresponding data owner.

[0093] 9) After receiving the decryption request sent by the security service program, the data owner first conducts a remote authentication of the security service program. Through security measurement, it ensures that the security service program and the trusted execution environment have not been compromised by an adversary and are secure and trustworthy. The data provider can judge in real time whether it still agrees that this data processor processes its own data. If not, it rejects the request and interrupts the processing process. If it agrees that this data processor processes its own data, it sends the decryption key to the security service program and conducts local evidence preservation to facilitate cross-domain control of the key management and use and traceability audit of data usage.

[0094] 10) After receiving the decryption keys of all data providers, the security service program requests to download the corresponding ciphertext data file from the cloud server according to the hash value corresponding to the ciphertext to the cloud server.

[0095] 11) After receiving the download request sent by the security service program, the cloud server provides the corresponding ciphertext data Sent to the security server program, and the security service program verifies , to resist possible malicious behaviors of the cloud server or external adversaries.

[0096] 12) After the security service program passes the verification, use the key to decrypt the ciphertext data to obtain the plaintext data , and perform corresponding operations according to the data processing strategy.

[0097] 13) After the security service program completes the processing operation, the security service program also needs to verify the authorization policies of all the data used, check whether the verification results are consistent with the recipient, and if so, return the processing result to the result recipient specified by the authorization policy.

[0098] For example, in the medical data analysis scenario:

[0099] Data provider A: The hospital encrypts the patient data (SM4) and formulates a policy to authorize research institution B for statistical analysis;

[0100] Processor B: Submits an aggregation analysis request, and the TEE verifies and then requests the key;

[0101] Audit and evidence preservation: The hospital queries the number of times B uses the data through the blockchain (such as the decryption operation at 10:00:00 on May 1, 2025);

[0102] Risk control: If B accesses over the limit, the hospital rejects subsequent key requests and terminates the service.

[0103] In practical applications, after hospital A encrypts the patient data, it authorizes pharmaceutical factory B to analyze but not see the original data. Each time an analysis is performed, pharmaceutical factory B must operate through a secure environment. Hospital A can see in real time when pharmaceutical factory B uses which data, and can immediately cut off the permission once an anomaly is found, which not only promotes data circulation but also ensures security. Hospital A always maintains control over the original data during the data analysis process of pharmaceutical factory B. All key requests need to pass double authentication (TEE integrity verification + dynamic policy check), and an immutable audit record is generated for each key use.

[0104] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and reference can be made to the description in the method part for related parts.

[0105] The foregoing description of the disclosed embodiments enables those skilled in the art to practice or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An auditable key management method based on a trusted execution environment, characterized in that It includes the following steps: S1. The data provider generates an asymmetric key pair (sk, pk) and a symmetric key k, encrypts the original data with k to obtain the ciphertext C, and calculates the hash value id of C; S2. The data provider stores <id, k> associated locally and uploads <id, C> to the cloud server; S3. The data provider formulates a data usage policy and signs it, and after signing with sk, sends it to the security service program in the trusted execution environment together with pk; S4. The data processor formulates a data processing policy and signs it, and sends it to the security service program in the trusted execution environment; S5. The security service program in the trusted execution environment verifies the signature and the authorization status of the processing policy, and sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider; S6. After remotely verifying the remote authentication report, if the data provider agrees to the request, it sends the key k to the security service program through a secure channel and stores the key usage record on the blockchain; S7. The security service program downloads the ciphertext C from the cloud server, decrypts the data after verifying id = hash(C), performs the processing operation, and encrypts the result and returns it to the specified recipient.

2. The auditable key management method based on a trusted execution environment according to claim 1, wherein In step S3, the data usage policy includes: Authorized usage participants, types of processing operations authorized for use, hash value corresponding to the ciphertext data, cloud service address where the ciphertext data is stored, data usage scope, and recipient of the data processing result.

3. The auditable key management method based on a trusted execution environment according to claim 1, characterized in that In step S4, the data processing policy includes: specific processing methods, processing parameters, data required for processing, recipient of the processing result, and its own signature.

4. The auditable key management method based on a trusted execution environment according to claim 1, characterized in that, Step S5 includes: S51. The security service program in the trusted execution environment uses the public key to verify whether the signatures of the data provider and the data processor are correct; and checks whether the processing data required in the data processing policy has been authorized for use; S52. If the authorization is verified to pass, the security service program requests the corresponding ciphertext data from the cloud server according to the data authorization policy; S53. The cloud server sends the corresponding ciphertext hash value and ciphertext <id, C> to the security service program according to the request of the security service program; S54. The security service program determines whether there is fraud on the cloud server by checking whether id = hash(C) is equal. If so, it stops the service; S55. The security service program sends a key request, a remote authentication report, and the identity signature of the data processor to the data provider.

5. The auditable key management method based on a trusted execution environment according to claim 4, characterized in that, In step S5, the remote authentication report includes: Data processor identity information, unique identifier of the trusted execution environment, execution program hash value, and signed by the hardware private key of the trusted execution environment.

6. The auditable key management method based on a trusted execution environment according to claim 1, wherein In step S6, the blockchain deposit includes: Timestamp, data provider identifier, key identifier, operation type, and digital signature; Automatically verified and written into the blockchain network through a smart contract.

7. A method for auditable key management based on a trusted execution environment according to claim 1, wherein Step S7 also includes: The decrypted data is destroyed after being processed in the security service program of the trusted execution environment.

8. The auditable key management method based on a trusted execution environment according to claim 1, wherein In step S1, the symmetric encryption algorithms adopted include the national cipher SM4 and AES; the asymmetric encryption algorithms include the national cipher SM2 and post-quantum cryptographic algorithms.

Images