Method and system for safely sharing data in untrusted cloud environment

Abstract

The invention discloses a method and a system for safely sharing data in an untrusted cloud environment. The method comprises the following steps: 1) when a trusted program is started for the first time, initializing a service key RKEY and a revocation list in a trusted execution environment TEE memory; encrypting the RKEY and storing the encrypted RKEY in a storage program; loading the encrypted RKEY into the TEE memory and decrypting the RKEY when the RKEY is not started for the first time, and loading the revocation list into the TEE memory and decrypting the revocation list; 2) the trusted program generates an identity ID, an identity key IKEY and an authentication report TCERT for a to-be-registered user; encrypting the IKEY by using the RKEY, and storing the encrypted IKEY in a storage program; 3) the trusted program generates an ABE master key pair for the user, and binds the MSK with the ID of the user; 4) the trusted program generates a private key SK for the user and binds the private key SK with the ID of the user; and 5) the trusted program decrypts the ciphertext by using the SK after receiving the data decryption request of the user.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security sharing and privacy protection in a cloud environment, and particularly relates to a method and system for securely sharing data in an untrusted cloud environment. BACKGROUND

[0002] In the past decade, cloud computing and cloud storage related technologies and industries have developed rapidly. Personal and enterprise data is gradually migrating to public clouds, and the storage, sharing, and computing of data have basically been implemented on the cloud, providing great convenience and economy for individuals and enterprises. At the same time, the reliability of public cloud services has gradually become a problem, and more and more research has revealed the potential data and privacy risks of public cloud services, pointing out that public cloud services are not completely reliable. For example, cloud service administrators and operation and maintenance personnel have the right or can access, access, or even tamper with personal and enterprise data stored on the cloud through certain technical means. In some research and practice, end-to-end encryption of data through traditional encryption algorithms can alleviate this problem to some extent. However, traditional encryption methods have considerable limitations in data sharing scenarios, and data owners need to use some additional means (such as offline communication, data re-encryption, etc.) to implement the data authorization access process, which limits the convenience of cloud services to some extent. In the latest related technology research, attribute-based encryption (ABE) technology has shown strong adaptability to cloud services in terms of both security and convenience, and is considered to be the most promising technology solution. Simply put, the ABE algorithm first generates a pair of master key pairs (including a master public key and a master private key), and the master private key is used to generate a private key for each user according to their attributes, and the master public key is used by the data owner to encrypt the data. Unlike traditional encryption algorithms, the ABE algorithm allows the data owner to specify the access policy of the data when encrypting the data, and only when the user's attributes match the access policy can the user's own private key decrypt the data. ABE naturally combines data encryption and access control, enabling flexible and fine-grained data access control. However, the current ABE algorithm still has the following limitations in the promotion and application of cloud service scenarios:

[0003] Master key control: who controls the ABE master private key, who can generate any private key, and thus can decrypt any access policy encrypted data, so the trust root of ABE algorithm is the security of ABE master private key. The current ABE master private key control is still in the hands of cloud service providers (or key infrastructure service providers), who generate private keys for each user (see patents CN106059763A, CN117648706A, CN117675167A, CN113489732A, etc.), Once the service provider abuses its power to create private keys or is attacked to cause the ABE master private key to be leaked, it will pose a threat to user and enterprise data. Therefore, the current ABE has a fundamental trust problem.

[0004] Key revocation problem: the traditional ABE has a problem that the decryption key cannot be revoked once it is given to the user, so when the user's attribute needs to be revoked or changed, it has to use high-cost methods such as data re-encryption. A currently feasible method is to first decrypt the data by the server when decrypting the data, and then the client decrypts the server decryption result twice to get the final decryption result. In this way, a revocation list can be added to limit the decryption operation of revoked users during the first decryption, thereby realizing key revocation (see patents CN113194089A, CN117675167A, CN113489732A, etc.). However, similar to the first problem, the biggest limitation of this method is that the control of revocation is in the hands of the cloud service provider (or key infrastructure service provider), and if the cloud environment itself is not trusted, the credibility of key revocation will also decrease.

[0005] User privacy problem: for traditional ABE algorithms, users need to provide a set of personal attributes that match the permissions when applying for private keys, and these attribute information often contains personal privacy. How to ensure that these personal attributes are not obtained or misused by cloud service providers or key infrastructure service providers is one of the important problems faced by current ABE algorithms in cloud deployment and use. SUMMARY

[0006] In order to solve the problems in the background art, the present application provides a method for securely sharing data in an untrusted cloud environment, and a data security sharing system based on the method. In the method and system provided by the present application, the user only needs to trust the TEE and the programs running therein, without relying on the trust endorsement of trusted cloud service providers, trusted CAs and other third-party trust institutions. The method and system provided by the present application can also support providing key management services to multiple user groups at the same time (i.e. managing multiple ABE master keys at the same time), which can effectively adapt to the current complex and variable cloud environment business scenarios.

[0007] The TEE referred to in the method should comply with the trusted execution environment service technical framework system established in GB / T 42572-2023. The ABE key generation and management method based on the trusted execution environment (TEE) refers to designing and implementing a trusted program (including a storage system) that can provide ABE key management functions based on TEE (at this time, data sharing functions are not involved). The data security sharing system based on the method refers to a system design using the above method in a data sharing scenario, mainly including the above method and a set of untrusted programs for interacting with users.

[0008] A method for securely sharing data in an untrusted cloud environment includes the following two types of programs:

[0009] Trusted program: a program running in the trusted execution environment TEE.

[0010] Storage program: a data storage system running in any area.

[0011] A method for securely sharing data in an untrusted cloud environment includes the following processes:

[0012] Startup process: When the trusted program is started for the first time, it needs to initialize the service key (RKEY) in the memory of the trusted execution environment TEE, and encrypt the RKEY using the device key of the TEE or an encryption key generated from the device key, and then store it in the storage program for backup. The encrypted RKEY can only be decrypted by the trusted program in the TEE memory. The trusted program also needs to initialize an empty revocation list in the TEE when it is started for the first time. When the trusted program is started for the first time, it needs to load the encrypted RKEY into the TEE memory and decrypt it, and then load the revocation list into the TEE memory and decrypt it. The startup process of the storage program has no special requirements.

[0013] Registration process: The trusted program provides user registration functions to generate an identity (ID), an identity key (IKEY), and an authentication report (TCERT) for the user. The ID is a fixed-length string that is ensured to be globally unique by the trusted program; the IKEY is a symmetric key used for subsequent communication encryption and user signature; and the TCERT is a certificate generated by the trusted program calling the relevant interfaces of the TEE, containing the trusted program verification value, the ID and IKEY hash value, the TEE device key signature of the TCERT, etc. The authenticity and integrity of the certificate TCERT can be verified by the TEE device manufacturer. The trusted program returns the ID, IKEY, and TCERT to the user in a secure manner, and stores the IKEY encrypted with the RKEY in the storage program. The TCERT can provide the user with trusted program verification and ID, IKEY verification.

[0014] Main key generation process: the trusted program provides main key generation function, and generates ABE main key pair for registered users. The user needs to carry his own ID when initiating the main key generation request, and sign the request using the IKEY kept by himself. The trusted program receives the main key generation request and performs the following processes in turn:

[0015] 1) Load the IKEY of the user into the TEE memory and decrypt it, and then use it to authenticate the signature of the request. If the signature authentication fails, return the information that the user's request is incorrect;

[0016] 2) If the signature authentication is passed, generate a pair of ABE keys and their unique identifier (MKID). The ABE key pair includes the main public key (MPK) of ABE and the main key (MSK), wherein the MPK is used to encrypt data (this method does not involve the process of using MPK to encrypt data), and the MSK is used to generate the private key (SK) required for decryption;

[0017] 3) Bind the MSK with the user's ID, then encrypt the MSK using the RKEY, and store it in the storage program;

[0018] 4) Return the MPK and MKID to the user.

[0019] Private key generation process: the trusted program provides SK generation function, and generates SK for registered users. When applying for SK, the user needs to specify the MPK used for encrypting data, and obtain his own attribute (IATTR) through one of the following ways:

[0020] ①Initiate an application to the MPK generator, and assign IATTR to the SK applicant by the MPK generator, and then encrypt the IATTR using the IKEY of the MPK generator, and return the encrypted result to the SK applicant;

[0021] ②The SK applicant sends his own IATTR to the MPK generator, and the MPK generator confirms that it is correct, and then encrypts the IATTR using the IKEY of the MPK generator, and returns the encrypted result to the SK applicant.

[0022] The user carries the MPK identifier MKID, his own ID and the IATTR encrypted by the MPK producer when initiating the SK generation request, and signs the request using the IKEY kept by himself. The trusted program receives the request and performs the following processes in turn:

[0023] 1) Load the IKEY of the user into the TEE memory and decrypt it, and then use it to authenticate the signature of the request. If the signature authentication fails, return the information that the user's request is incorrect;

[0024] 2) If the signature authentication is passed, the IKEY of the MPK generator is loaded into the TEE memory and decrypted, and then it is used to decrypt and restore the IATTR and verify the integrity, if the verification fails, the user is returned the information that the request is wrong;

[0025] 3) If the IATTR verification is passed, the MSK corresponding to the MPK is loaded into the TEE memory and decrypted, and then it is used to generate the SK together with the IATTR, and a unique number (SKID) of the SK is generated;

[0026] 4) The SK is bound with the ID of the user, and then the SK is encrypted by using the RKEY and stored in the storage program;

[0027] 5) The SKID is returned to the applicant.

[0028] Data decryption process: the trusted program provides the data decryption function. The user carries the ID, SKID and ciphertext data (CT) of himself when initiating the data decryption request, and signs the request by using the IKEY kept by himself. After the trusted program receives the data decryption request, the following processes are sequentially performed:

[0029] 1) The IKEY of the user is loaded into the TEE memory and decrypted, and then it is used to authenticate the signature of the request, if the signature authentication fails, the user is returned the information that the request is wrong;

[0030] 2) If the signature authentication is passed, it is verified whether the SKID is in the revocation list, if yes, the user is returned the information that the SK has been revoked;

[0031] 3) If the SKID is not in the revocation list, the SK is loaded into the TEE memory and decrypted, and then it is used to try to decrypt the CT;

[0032] 4) If the decryption is successful, the decryption result is returned to the user in a secure manner, otherwise the user is returned the information that the decryption fails.

[0033] Private key revocation process: the trusted program provides the SK revocation function, and allows the MPK generator to revoke the SK generated by authorization. The user carries the ID, MKID and SKID of himself when initiating the SK revocation request, and signs the SK revocation request by using the IKEY kept by himself. After the trusted program receives the request, the following processes are sequentially performed:

[0034] 1) The IKEY of the user is loaded into the TEE memory and decrypted, and then it is used to authenticate the signature of the request, if the signature authentication fails, the user is returned the information that the request is wrong;

[0035] 2) If the first step of verification passes, the master key generator ID is loaded into the TEE memory according to the MKID, and the user ID is verified to be consistent with the master key generator ID (that is, to verify whether the user is the generator of the master key). If the verification fails, the user request is returned with a message that the user request is incorrect;

[0036] 3) If the second step verification is successful, the SK's MKID is loaded into the TEE memory according to the SKID, and the MKID of the SK is verified to be consistent with the one in the request. If the verification fails, the user request is returned with a message that the user's request is incorrect;

[0037] 4) If the third step verification is successful, the SKID is added to the revocation list, and then the updated revocation list is encrypted using the user's RKEY and stored in the storage program (or overwrites the original revocation list);

[0038] 5) Return the information that the user has successfully canceled the account.

[0039] A system for securely sharing data in an untrusted cloud environment, including the following participants:

[0040] Key service provider: A key service provider refers to an organization or institution that provides ABE key generation and management services based on the above-mentioned method proposed in the present invention, and is mainly responsible for the startup and maintenance of server-side programs (including trusted programs, stored programs, and untrusted programs). Among them, untrusted programs are mainly used to respond to users' web requests and interact with trusted programs. The key service provider should disclose the source of the trusted program and the core parameters required for verification (such as program verification code, electronic signature, etc.). The key service provider can also be concurrently served by the cloud service provider, which will not reduce the security and reliability of the system, that is, the system can effectively resist the conspiracy between the key service provider and the cloud service provider.

[0041] Users: Primarily comprise data providers and users. Users interact with the key service provider's server program via client programs running on terminals (including PCs, servers, and mobile devices) to complete relevant business operations. For user groups consisting of multiple users, users also include administrators responsible for generating ABE master key pairs and group member private keys.

[0042] Cloud service provider: A cloud service provider is an organization or institution that provides cloud storage, cloud computing infrastructure, services, and systems. In this method, no restrictions are placed on cloud service providers.

[0043] A system for securely sharing data in an untrusted cloud environment, comprising the following processes:

[0044] Start-up process: the key service provider starts the server program, including the trusted program start-up and the start-up of the untrusted program in the foregoing method.

[0045] Registration process: the user installs the terminal client program, and sends a registration request to the server program through the client program. After receiving the request, the server program performs the registration process of the trusted program in the foregoing method, generates a unique identification (ID) of the user, an identity key (IKEY), and a trusted program authentication credential (TCERT), and then returns them to the client program in a secure manner. After receiving the ID, IKEY, and TCERT, the client program identifies the TEE device manufacturer in the TCERT, and then sends the TCERT to the manufacturer for verification of the trusted program and its execution environment. The verification result indicates whether the core parameters of the trusted program are real and complete, and whether the program is indeed running in the trusted execution environment produced by the manufacturer. Then, the client program compares and verifies the verified program core parameters with the core parameters disclosed by the key service provider. After the verification is passed, the client program stores the ID and IKEY.

[0046] Application master key process: after the user completes the registration, the user sends an ABE master key pair generation request to the server program through the client program. After receiving the request, the server program performs the master key generation process of the trusted program in the foregoing method, generates an algorithm to generate a master public key MPK and a master key MSK, and then the server program returns the MPK and the number (MKID) of the master key to the client program. Generally, the applicant is usually the administrator of a user group or a data provider who wants to share personal data with others.

[0047] Data upload process: before uploading data, the user needs to first obtain the available MPK on the client program by applying for it by himself / herself or applying for it from the administrator after joining other user groups. Then, the user sets the access control policy of the data in the client program and selects to use the MPK to encrypt the data. During encryption, the client first generates a symmetric data encryption key (DK), and then encrypts the data using DK, and then encrypts DK according to the ABE encryption algorithm using MPK and the access control policy, and finally packs the encryption result of DK and the encryption result of the data together. Next, the user sets the data upload path (such as specifying the cloud service provider address, cloud storage account password, etc.), and uploads the above packed result to the cloud service provider through the client program according to the configured upload path. After the data is uploaded, the user publishes or sends the related information of the data resource (such as the download URL, the MPK used for encryption, etc.) to the specified user (group) through the client program.

[0048] Application private key process: If a user wants to use the data encrypted by the MPK, the user needs to have a private key (SK) generated by the generator of the MPK. When the user applies for the SK, the user first sends an application to the generator of the MPK through the client program, and the generator of the MPK agrees to set the attribute of the user through the client program. After the setting is completed, the client program encrypts the attribute of the user with the IKEY of the generator, and then sends the attribute and the encryption result to the SK applicant. The process is regarded as the authorization of the user to apply for the SK by the generator of the MPK. After the SK applicant is authorized, the SK applicant applies for generating the SK to the server program through the client program. After the server program receives the request, the server program generates the SK by executing the private key generation process of the trusted program in the foregoing method, and then returns the number (SKID) of the SK to the client program.

[0049] Data download and decryption process: After the user applies for the SK, the user obtains the data resource information from the client or sends the data resource information to the user, obtains the data resource from the cloud service provider according to the download URL through the client program, and parses the encryption result of the DK and the encryption result of the data from the data resource. Then, the user applies for using the SK to decrypt the DK to the server program through the client program, and sends a data decryption request to the trusted program. After the server program receives the data decryption request, the server program executes the data decryption process of the trusted program in the foregoing method, and returns the decrypted DK to the client program in a secure manner. The client program decrypts the data using the DK, and then returns the decryption result to the user.

[0050] Private key revocation: The generator of the MPK pulls the list of the SKs generated by the generator himself from the server program through the client program. Then, the generator selects the SKs to be revoked, and applies for revoking the SKs to the server program through the client program. After the server program receives the request, the server program executes the SK revocation process of the trusted program in the foregoing method, and then returns the revocation result to the client program and the user.

[0051] The application has the following advantages:

[0052] The application places the core process of the ABE key generation and management in the TEE, prevents the key service provider from accessing the ABE key, and thus ensures the credibility, integrity and confidentiality of the ABE key generation, use and revocation process. Meanwhile, the application uses the remote provable feature of the TEE to ensure the integrity of the program running in the TEE, and provides a complete and verifiable trust chain for the user. In addition, the application also fully protects the personal attribute of the user, and strengthens the privacy protection in the ABE key generation and use process. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 It is a system schematic diagram for securely sharing data in an untrusted cloud environment. DETAILED DESCRIPTION

[0054] To more clearly illustrate the proposed method, we will use an example to illustrate the specific implementation of the ABE key generation and management method based on a trusted execution environment (TEE). In this example, we use Intel Software Guard Extensions (SGX) technology as the specific implementation of TEE. The relevant concepts and terms mainly include:

[0055] Enclave: The trusted program running in the TEE environment provided by SGX is also called an enclave program.

[0056] HMAC: HMAC is a method based on the HASH algorithm that takes a message M and a key K as input to generate a fixed-length message digest, expressed as HMAC K (M). It can be used to verify the integrity of M and the authenticity of the message sender.

[0057] iKGF: Intel Key Generation Facility, a dedicated hardware security module provided by Intel, an offline generation tool used to generate the Root Provisioning Key and Root Sealing Key.

[0058] Root Sealing Key (RSK): A key generated by a dedicated hardware security module (Intel Key Generation Facility) provided by Intel, stored inside SGX and accessible only to SGX.

[0059] MRSIGNER: MRSIGNER is an identification information related to the Enclave program.

[0060] Sealing Key: Sealing Key is a key generated by SGX based on RSK and MRSIGNER, which can be used to encrypt data related to the current Encalve.

[0061] REPORT: A REPORT is generated by the enclave program and contains information about the enclave, such as its identity, code measurements, hardware characteristics, etc. In particular, the data field of the REPORT allows users to add custom content.

[0062] Quoting Enclave (QE): A special Enclave whose task is solely to handle remote attestation. It receives REPORTs from other Enclaves, verifies them and signs them with an attestation key, then returns the result to the application.

[0063] An implementation of a method for securely sharing data in an untrusted cloud environment, comprising the following procedures:

[0064] Startup procedure: The Enclave program randomly initializes a service key (RKEY) in the Enclave when it is first started, and encrypts the RKEY using the Sealing Key of the Enclave program, then stores it in the storage program for backup, while initializing an empty revocation list. When the Enclave program is not started for the first time, it needs to load the RKEY into the Enclave program and decrypt it using the Sealing Key of the Enclave, and then load the revocation list into the Enclave and decrypt it using the RKEY. The startup procedure of the storage program has no special requirements.

[0065] Registration procedure: The user generates a pair of temporary asymmetric keys (PVKEY and PUKEY) locally, and carries the public key PUKEY in the registration request. After receiving the user's registration request, the Enclave randomly generates a user ID and a user key IKEY, and encrypts IKEY using PUKEY, then passes the user ID and encrypted IKEY into the sgx_creat_report function as data parameters to generate a report, and then passes the report to QE. QE signs the report to generate the final TCERT and returns it to the user. The user can use the interface provided by Intel to remotely authenticate the signature of TCERT, ensuring the integrity and authenticity of the content of TCERT, and then confirming that the ID and IKEY are generated by the Enclave program running in the TEE environment, and that the Enclave program has not been tampered with. The user extracts the user ID and encrypted IKEY from the data attribute of TCERT, and decrypts IKEY using PVKEY.

[0066] Master key generation procedure: The user sends a master key generation request containing his own ID and HMAC IKEY (ID) to the Enclave. After receiving the request, the Enclave program performs the following procedures in order:

[0067] 1) Load the IKEY of the user into the Enclave program and decrypt it using RKEY, then use it to recalculate the HMAC value of the ID, and compare the calculation result with the HMAC IKEY(ID) for comparison verification (this process is the general method of signature verification of the Enclave program to the request initiator in this embodiment, and the subsequent process will not be described again), if they are different, return the information that the user's request is wrong;

[0068] 2) If the first step verification is passed, generate a pair of ABE's master public key (MPK) and master secret key (MSK) and the unique identifier (MKID) of this pair of keys;

[0069] 3) Use RKEY to encrypt MSK to get ENC(MSK), then use RKEY to calculate the HMAC value of {ID, MKID, ENC(MSK)} and store the HMAC value together with {ID, MKID, ENC(MSK)} in the storage program. The calculation of HMAC is for the integrity check when the encrypted data is reloaded into the Enclave program later;

[0070] 4) Return MPK and MKID to the applicant.

[0071] Private key generation process: the user sends a private key generation request containing his / her ID, MKID, encrypted IATTR, and the HMAC value calculated using his / her IKEY on the above information to the Enclave program. After receiving the request, the Enclave program performs the following processes in turn:

[0072] 1) Load the IKEY of this user into the Enclave program and decrypt it using RKEY, then use it to authenticate the signature of the request, if the signature authentication fails, return the information that the user's request is wrong;

[0073] 2) If the first step verification is passed, load the IKEY of the MPK generator into the Enclave program and decrypt it using RKEY, then use it to decrypt and restore IATTR and verify its integrity, if the verification fails, return the information that the user's request is wrong;

[0074] 3) If the IATTR verification is passed, load the MSK corresponding to the MPK into the Enclave program and decrypt it using RKEY, then use it and IATTR to generate SK, and generate the unique number (SKID) of this SK;

[0075] 4) Use RKEY to encrypt SK to get ENC(SK), then use RKEY to calculate the HMAC value of {ID, MKID, SKID, ENC(SK)} and store the HMAC value together with {ID, MKID, SKID, ENC(SK)} in the storage program;

[0076] 5) Return SKID to the applicant.

[0077] Data decryption process: the user sends a data decryption request to the Enclave program, which contains the user's ID, SKID, ciphertext data (CT), and HMAC value calculated using the user's IKEY. After receiving the request, the Enclave program performs the following processes in order:

[0078] 1) Load the user's IKEY into the Enclave program and decrypt it using the RKEY, then use it to authenticate the signature of the request. If the signature authentication fails, return information that the user's request is incorrect.

[0079] 2) If the first step is verified, verify whether the SKID is in the revocation list. If it is, return information that the user's SK has been revoked.

[0080] 3) If the SKID is not in the revocation list, load the SK into the Enclave program and decrypt it using the RKEY, then use it to try to decrypt the CT.

[0081] 4) If the decryption is successful, use the IKEY to encrypt the result again and return it to the user. Otherwise, return information that the user's decryption failed.

[0082] 5) If the fourth step decryption is successful, the user decrypts the plaintext data locally using the IKEY.

[0083] Private key revocation process: the user sends a data decryption request to the Enclave program, which contains the user's ID, SKID, MKID, and HMAC value calculated using the user's IKEY. After receiving the request, the Enclave program performs the following processes in order:

[0084] 1) Load the user's IKEY into the Enclave program and decrypt it using the RKEY, then use it to authenticate the signature of the request. If the signature authentication fails, return information that the user's request is incorrect.

[0085] 2) If the first step is verified, load the generator ID of the master key pair into the Enclave program according to the MKID, and verify whether the user ID and the master key generator ID are consistent. If the verification fails, return information that the user's request is incorrect.

[0086] 3) If the second step is verified, load the SK's MKID into the Enclave program according to the SKID, and verify whether the SK's MKID is consistent with the request. If the verification fails, return information that the user's request is incorrect.

[0087] 4) If the third step is verified, add the SKID to the revocation list, then encrypt the updated revocation list using RKEY, and store it in the storage program (or overwrite the original revocation list);

[0088] 5) Return the information of successful revocation to the user.

[0089] A specific implementation of a system for securely sharing data in an untrusted cloud environment mainly includes the specific implementation process of the ABE key generation and management method based on the trusted execution environment (TEE) described above.

[0090] The above examples are only used to illustrate the technical solutions of the present application and not to limit them. Those skilled in the art can modify or equivalently replace the technical solutions of the present application without departing from the spirit and scope of the present application. The protection scope of the present application shall be subject to the description in the claims.

Claims

1. A method for securely sharing data in an untrusted cloud environment, comprising the steps of: a startup procedure: when the trusted program is started for the first time, a service key RKEY and a revocation list are initialized in the memory of a trusted execution environment (TEE); the RKEY is encrypted using a device key of the TEE or an encryption key generated by the device key and stored in a storage program; when the trusted program is started for the second time, the encrypted RKEY is loaded into the memory of the TEE and decrypted, and then the revocation list is loaded into the memory of the TEE and decrypted; the trusted program is a program running in the TEE; the storage program is a data storage system running in any area; a registration procedure: the trusted program generates an identity ID, an identity key IKEY and an attestation report TCERT for a user to be registered and returns them to the user; the TCERT contains a verification value of the trusted program, hash values of the ID and the IKEY, and a signature of the TCERT signed by the TEE device key; then the IKEY is encrypted using the RKEY and stored in the storage program; a master key generation procedure: the trusted program generates an ABE master key pair including a master public key MPK and a master secret key MSK for the user; the MSK is bound to the ID of the user, and then the MSK is encrypted using the RKEY and stored in the storage program; a private key generation procedure: the trusted program generates a private key SK for the user, and binds the SK to the ID of the user, and then encrypts the SK using the RKEY and stores the SK in the storage program; a data decryption procedure: after receiving a data decryption request of the user, the trusted program performs steps 1) to 4); the data decryption request includes the ID, the SKID, the ciphertext data CT and a signature of the data decryption request signed using the IKEY; 1) the IKEY of the user is loaded into the memory of the TEE and decrypted, and the signature of the data decryption request is authenticated; if the signature authentication fails, an error message is returned; 2) if the signature authentication is passed, it is verified whether the SKID is in the revocation list; if yes, an information that the SK of the user is revoked is returned; 3) if the SKID is not in the revocation list, the SK is loaded into the memory of the TEE and decrypted for decrypting the CT; 4) if the decryption is successful, the decryption result is returned to the user; otherwise, an information that the decryption fails is returned.

2. The method of claim 1, wherein, after receiving a master key generation request of the user, the trusted program performs steps 21) to 24) to generate an ABE master key pair for the user; the master key generation request includes the ID of the user and a signature of the master key generation request signed using the IKEY; 21) the IKEY of the user is loaded into the memory of the TEE and decrypted for authenticating the signature of the master key generation request; if the signature authentication fails, an error message is returned; 22) if the signature authentication is passed, an ABE master key pair and a unique identification MKID thereof are generated; 23) the MSK is bound to the ID of the user, and then the MSK is encrypted using the RKEY and stored in the storage program; 24) the MPK and the MKID are returned to the user.

3. The method of claim 2, wherein, The trusted program receives a private key SK request of a user, and performs steps 31) to 35) to generate a private key SK for the user; the private key SK request comprises an MKID, an ID of the user, a user attribute IATTR encrypted by an IKEY of the user, and a signature of the private key SK request by the IKEY; 31) load the IKEY of the user into the memory of the TEE and decrypt it, to authenticate the signature of the private key SK request, and return an error message if the authentication fails; 32) if the authentication passes, load the IKEY of the MPK generator into the memory of the TEE and decrypt it, to decrypt and verify the integrity of the IATTR, and return an error message if the verification fails; 33) if the verification of the IATTR passes, load the MSK corresponding to the MPK into the memory of the TEE and decrypt it, to generate the SK and a unique SKID according to the decryption result of the MSK and the IATTR; 34) bind the SK with the ID of the user, and then encrypt the SK using the RKEY and store it in the storage program; 35) return the SKID to the user.

4. The method according to claim 1 or 2 or 3, characterized in that, The trusted program receives a private key SK request of a user, and performs steps 31) to 35) to generate a private key SK for the user; the private key SK request comprises an MKID, an ID of the user, a user attribute IATTR encrypted by an IKEY of the user, and a signature of the private key SK request by the IKEY; 41) load the IKEY of the user into the memory of the TEE and decrypt it, to authenticate the signature of the private key SK request, and return an error message if the authentication fails; 42) if the verification of step 41) passes, load the ID of the MPK generator into the memory of the TEE according to the MKID of the user, to verify whether the ID of the user is consistent with the ID of the MPK generator, and return an error message if the verification fails; 43) if the verification of step 42) passes, load the MKID of the SK into the memory of the TEE according to the SKID of the user, to verify whether the MKID of the SK is consistent with the MKID in the SK revocation request, and return an error message if the verification fails; 44) if the verification of step 43) passes, add the SKID of the user to the revocation list, and then encrypt the updated revocation list using the RKEY and store it in the storage program; 45) return a success message to the user.

5. A system for secure sharing of data in an untrusted cloud environment, characterized by, The key service provider, the cloud service provider, the user end, and the master key generator; the user end comprises a data provider and a data user; The key service provider is configured to provide ABE key generation and management services to the outside, and is responsible for starting and maintaining the service end program; The service end program comprises a trusted program, a storage program, and an untrusted program; The trusted program is a program running in a trusted execution environment TEE; The storage program is a data storage system running in any region; In the starting process: when the trusted program is started for the first time, the service key RKEY and a revocation list are initialized in the memory of the trusted execution environment TEE; The RKEY is stored in the storage program after being encrypted by a device key of the TEE or an encryption key generated by the device key; When the trusted program is started for the first time, the encrypted RKEY is loaded into the TEE memory and decrypted, and then the revocation list is loaded into the TEE memory and decrypted; In the registration process: the user end installs a terminal client program, and sends a registration request to the trusted program through the client program; the trusted program generates an identity ID, an identity key IKEY and an authentication report TCERT for the user to be registered after receiving the registration request, and returns them to the user; wherein the TCERT contains the check value of the trusted program, the ID and IKEY hash value, and the signature of the TEE device key on the TCERT; then the IKEY is encrypted by the RKEY and stored in the storage program; In the application master key process: the user end sends an ABE master key pair generation request to the trusted program through the client program, and the trusted program generates an ABE master key pair for the user, including a master public key MPK and a master secret key MSK; the MSK is bound to the ID of the user, and then the MSK is encrypted by the RKEY and stored in the storage program; In the application private key process: the user end sends a private key SK request to the trusted program through the client program, and the trusted program generates a private key SK for the user, and binds the SK to the ID of the user, and then encrypts the SK by the RKEY and stores it in the storage program; In the data upload process: before uploading data, the data provider sets the access control policy of the data through the client program and selects to use the applied MPK to encrypt the data; when encrypting, the data provider first generates a symmetric data encryption key DK, and then encrypts the data using DK, and then encrypts DK according to the ABE encryption algorithm using MPK and the access control policy, and finally uploads the encryption result of DK and the encryption result of the data to the cloud service provider according to the set data upload path; then the client program publishes or sends the data resource information to the specified user or user group; In the data download and decryption process: the data user obtains the data resource information published or sent to himself through the client program, and obtains the data resource from the cloud service provider according to the download address through the client program, and parses the encryption result of DK and the encryption result of the data from the data resource; then the client program applies to the trusted program to decrypt DK using SK and sends a data decryption request to the trusted program; the trusted program receives the data decryption request and executes steps 1) to 4); the data decryption request includes the ID, SKID, ciphertext data CT and the signature of the data decryption request using IKEY of the user; and returns the decrypted DK to the client program; the client program decrypts the data using DK and returns the decryption result to the data user; 1) load the IKEY of the data user into the TEE memory and decrypt it, and authenticate the signature of the data decryption request, if the signature authentication fails, return an information that the request is wrong; 2) if the signature authentication is passed, verify whether the SKID is in the revocation list, if yes, return the information that the user's SK is revoked; 3) if the SKID is not in the revocation list, load the SK into the TEE memory and decrypt it for decrypting the CT; 4) if the decryption is successful, return the decryption result to the data user, otherwise, return the information that the decryption fails.

6. The system of claim 5, wherein, The private key revocation process is also included: when the trusted program receives the SK revocation request initiated by the user, steps 41) to 45) are executed; the SK revocation request includes the ID, MKID and SKID of the user and the signature of the SK revocation request by the IKEY of the user; 41) load the IKEY of the user into the TEE memory and decrypt it for authenticating the signature of the SK revocation request, if the signature authentication fails, return the information that the request is incorrect; 42) if the step 41) is verified, load the ID of the corresponding MPK generator into the TEE memory according to the MKID of the user, verify whether the ID of the user is consistent with the ID of the MPK generator, if the verification fails, return the information that the request is incorrect; 43) if the step 42) is verified, load the MKID of the SK into the TEE memory according to the SKID of the user, verify whether the MKID of the SK is consistent with that in the SK revocation request, if the verification fails, return the information that the request is incorrect; 44) if the step 43) is verified, add the SKID of the user to the revocation list, then encrypt the updated revocation list using the RKEY and store it in the storage program; 45) return the information that the revocation is successful to the user.

7. The system of claim 5, wherein, After receiving the master key generation request initiated by the user, the trusted program executes steps 21) to 24) to generate the ABE master key pair for the user; the master key generation request includes the ID of the user and the signature of the master key generation request by the IKEY of the user; 21) load the IKEY of the user into the TEE memory and decrypt it for authenticating the signature of the master key generation request, if the signature authentication fails, return the information that the request is incorrect; 22) if the signature authentication is passed, generate an ABE master key pair and its unique identifier MKID; 23) bind the MSK with the ID of the user, then encrypt the MSK using the RKEY and store it in the storage program; 24) return the MPK and MKID to the user.

8. The system of claim 5, wherein, When the trusted program receives the private key SK request of the user, it executes steps 31) to 35) to generate the private key SK for the user; the private key SK request includes the MKID and ID of the user, the user attribute IATTR encrypted by the IKEY of the user and the signature of the private key SK request by the IKEY of the user; 31) load the IKEY of the user into the TEE memory and decrypt it for authenticating the signature of the private key SK request, if the signature authentication fails, return the information that the request is incorrect; 32) If the signature authentication is passed, the IKEY of the MPK generator is loaded into the TEE memory and decrypted, used to decrypt and restore IATTR and verify its integrity, if the verification is not passed, return the information that the request is wrong; 33) If the IATTR verification is passed, the MSK corresponding to the MPK is loaded into the TEE memory and decrypted, and the SK and its unique number SKID are generated according to the decryption result of the MSK and the IATTR; 34) The SK is bound with the ID of the user, and then the SK is encrypted by using the RKEY and stored in the storage program; 35) The SKID is returned to the user.

9. The system of claim 5, wherein, The cloud service provider includes an organization or institution providing cloud storage, cloud computing infrastructure, service, system; the key service provider includes an organization or institution providing ABE key generation and management service.

Images