A cloud storage data integrity checking method for lightweight devices

Abstract

The application discloses a cloud storage data integrity verification method for light equipment, first, ensuring that a data owner and a cloud server are registered and deposited on a block chain smart contract; meanwhile, the data owner generates a master key locally; the method comprises a data storage stage and a data verification stage; the data storage stage is that the data owner safely and privately sends data to the cloud server for storage; the data verification stage is that after the storage stage is completed, the data owner performs data integrity verification on the data stored in the cloud server; and the cloud storage integrity proof needs to be calculated in a trusted execution environment in the data storage or verification stage, and each time the session key for storage or verification is different. Under the premise of ensuring the privacy of data, the application realizes instant verification of the data stored in the cloud server, and ensures that the cloud server can only honestly save complete data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, and particularly relates to a cloud storage data integrity verification method for lightweight devices. BACKGROUND

[0002] In the end-to-cloud scenario, the end-side devices such as mobile phones, sensors and drones are usually resource-constrained, but need to continuously collect external data, which generates high computing power and storage requirements. However, the hardware configuration of these devices cannot meet the requirements, so the data needs to be transmitted to the centralized cloud server for storage or calculation to release the storage load. This hosting mode faces many security and privacy challenges. First, the data of the end-side device needs to be protected, and should not be transmitted to the cloud server in plaintext form. Second, the integrity of the data of the cloud server needs to be guaranteed to prevent the cloud server from discarding part or all of the data for cost-saving consideration. In addition, the lightweight end-side device usually deletes the local data after data hosting, but still needs to verify the stored data multiple times. Therefore, a mechanism is needed to enable the user to verify the data integrity at any time without retaining the original data.

[0003] The first challenge can be solved by encryption, and the user encrypts the data before sending it. The second challenge can be implemented by digital signature, which generates a hash value of the data through a hash function to verify the data integrity. However, the simple signature mechanism is not suitable for the third challenge because the end-side usually does not continue to store the original data after sending its own data, and the signature needs to compare whether the digest is consistent, which needs to come from the hash value of the original data. The cloud server only needs to save the hash value of the original data to pass the signature challenge, therefore, the simple signature mechanism does not have the ability to meet the multiple and arbitrary verification requirements of the end-side. In the existing cloud storage data integrity verification scheme, a third-party auditor (TPA) role is involved, and their scheme requires the third-party auditor to be trusted, which is difficult to achieve in actual situations. SUMMARY

[0004] The present application relates to the technical field of data security, and particularly relates to a cloud storage data integrity verification method for lightweight devices.

[0005] Technical scheme: a cloud storage data integrity verification method for lightweight devices, first, the data owner and the cloud server should be registered and deposited on the blockchain smart contract; at the same time, the data owner generates a master key locally; including data storage stage and data verification stage: the data storage stage is that the data owner sends the data to the cloud server for storage safely and privately; the data verification stage is that the data owner verifies the data integrity of the data stored in the cloud server after the storage stage is completed; and the calculation of the cloud data integrity proof in the data storage or verification stage is carried out in the trusted execution environment, and the session key is different each time.

[0006] Further, the data storage stage includes the following steps:

[0007] SA1, the data owner and the trusted execution environment perform remote authentication, and negotiate a session key; the session key cooperates with the master key to encrypt the data to be managed and generate a corresponding data identifier, and the data owner sends the encrypted data to be managed and the data identifier to the cloud server;

[0008] SA2, after the cloud server stores the encrypted managed data and the data identifier, loads the encrypted managed data and the data identifier into the trusted execution environment, decrypts the managed data in the isolated security zone provided by the trusted execution environment, and performs a hash operation on the managed data and the managed data identifier, and the obtained hash value is encrypted with the session key as the cloud storage integrity proof;

[0009] SA3, the trusted execution environment generates an authentication report and sends it to the IAS for verification, packs the verification report returned by the IAS, the certificate and the signature of the verification report as the calculation correctness proof of the encrypted cloud storage integrity proof; then submits the encrypted cloud storage integrity proof and the calculation correctness proof to the smart contract in the blockchain, if the calculation correctness proof is verified, the cloud storage integrity proof is stored in the blockchain;

[0010] SA4, the data owner obtains the cloud storage integrity proof from the blockchain and performs decryption processing to obtain the plaintext hash; then the plaintext hash is taken as input to perform the insertion storage operation of the cuckoo filter.

[0011] Further, in step SA1, the data owner calculates the data identifier by using a hash algorithm on the data to be managed.

[0012] Further, the data verification stage includes the following steps:

[0013] SB1, the data owner and the trusted execution environment perform remote authentication, and negotiate a session key; send the data identifier that needs to be verified to the cloud server;

[0014] SB2, the cloud server finds the encrypted to-be-managed data according to the data identifier, loads the encrypted to-be-managed data and the data identifier into the trusted execution environment, decrypts the to-be-managed data by using the isolated security area provided by the trusted execution environment, and performs a hash operation on the to-be-managed data and the to-be-managed data identifier to obtain a hash value, and the hash value is encrypted by using a session key as a cloud storage integrity proof;

[0015] SB3, the trusted execution environment generates an authentication report and sends the report to the IAS for verification, packs the verification report returned by the IAS, the certificate and the signature of the verification report as a calculation correctness proof of the encrypted cloud storage integrity proof, and then submits the cloud storage integrity proof and the calculation correctness proof to a smart contract in a block chain, and if the calculation correctness proof passes the verification, the cloud storage integrity proof is stored in the block chain;

[0016] SB4, the data owner obtains the cloud storage integrity proof from the block chain and performs decryption processing to obtain a plaintext hash, and then inputs the plaintext hash as a query to perform a query operation of a cuckoo filter: if the query is successful, the data passes the integrity verification of the cloud server; if the query fails, the data fails the integrity verification of the cloud server.

[0017] Compared with the prior art, the present application has the following remarkable effects:

[0018] 1. The present application designs a cloud data integrity verification scheme by using a trusted execution environment technology, ensures that the session key is different each time the data is stored or verified, so that the cloud server cannot pass the next verification by saving the integrity verification proof, realizes the instant verification of the data stored in the cloud server under the premise of ensuring the privacy of the data, and ensures that the cloud server can only honestly save the complete data;

[0019] 2. During storage, the decrypted cloud data integrity proof is saved locally on the terminal side and added to the cuckoo filter; during verification, the decrypted cloud data integrity proof is input into the cuckoo filter for searching, and if the searching result is that the data exists, the verification is successful; in addition to the high searching efficiency, compared with the traditional storage data structure, the cuckoo filter usually needs less memory space to store a similar size of data set, and also reduces the storage load of the terminal side device;

[0020] 3. The blockchain is used for integrity checking, auditing and storing, which ensures the traceability and fairness of the verification, thereby avoiding potential disputes and denial of service. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 The flowchart for the implementation process of the storage stage in the present application;

[0022] Figure 2 The implementation process flow chart of the verification stage in the application;

[0023] Figure 3 The structure flow chart of the first execution storage stage in the application;

[0024] Figure 4 The structure flow chart of the verification stage in the application. DETAILED DESCRIPTION

[0025] The application will be further described in detail below in combination with the accompanying drawings and specific embodiments.

[0026] The trusted execution environment (TEE) provides a method to solve the challenges mentioned in the prior art, by creating a trusted area in the cloud server that cannot be accessed by the cloud server, loading the ciphertext into it for verification calculation and generating the transportation bureau integrity proof, ensuring the confidentiality of the data and preventing the cloud server from cheating in the verification process. The application proposes a scheme for the demand of privacy protection and data integrity guarantee in cloud storage, which combines the trusted execution environment technology and the blockchain technology to provide a reliable mechanism that can satisfy the data privacy protection premise and perform instant and multiple checks on the data.

[0027] In this embodiment, the participating entities involved are as follows:

[0028] 1) Data owner (DO, i.e. end side)

[0029] It is a lightweight end-side device in the end-cloud scenario, with limited computing power and storage capacity, and has the business demand of hosting local data for storage.

[0030] 2) Cloud server (CS, i.e. cloud side)

[0031] It is a cloud-side server in the end-cloud scenario, with huge computing power and storage capacity, and has the ability and business demand to receive end-side data for storage. In addition, the cloud server is also equipped with a hardware device supporting the trusted execution environment.

[0032] 3) Trusted execution environment (TEE)

[0033] Although the TEE is not an independent individual, in order to highlight the isolation between the TEE and the cloud server, the TEE is logically separated from the cloud server. The TEE is the core code used to perform data integrity verification. Due to its confidentiality, even the cloud server (external host of the TEE) cannot access the code and data in the isolated space opened by the TEE, and can only get the execution result of the integrity verification. The present application uses Intel's SGX (Software Guard Extensions) as the TEE instance used.

[0034] 4) Blockchain (BC, Blockchain)

[0035] The blockchain, as a distributed database, provides a decentralized storage trust root for the data integrity verification result generated by the TEE. Based on the programmability of the smart contract supported by the blockchain, the result is automatically checked, audited and arbitrated,

[0036] Thus, potential transaction disputes between the two parties are avoided.

[0037] The present application uses a trusted execution environment to calculate cloud data integrity proof and different session keys are used for each storage or verification. Since the cloud data integrity proof is encrypted with a session key, the cloud server cannot verify it next time by saving the cloud data integrity proof. The cloud data integrity verification scheme based on the trusted execution environment realizes the instant verification of the data stored on the cloud server under the premise of ensuring the privacy of the data, and ensures that the cloud server can only honestly save the complete data.

[0038] Considering the computing power and storage capacity of lightweight end-side devices, since terminal devices like sensors need to generate data continuously, the search efficiency of signature verification of specified data is relatively low as the data volume grows. In order to provide a fast and efficient verification mechanism that adapts to lightweight devices, an end-side lightweight and efficient verification scheme based on a cuckoo filter is proposed. When storing, the end-side locally saves the hosting data and the hash value of the hosting data identifier and adds it to the cuckoo filter. When verifying, the decrypted hash value is input into the cuckoo filter for searching. If the result returns that it exists, it proves that the verification is successful. In addition to the high search efficiency, compared with traditional storage data structures, the cuckoo filter usually needs less memory space to store a similar size of data set, which also reduces the storage load of the end-side device.

[0039] The blockchain is used for integrity verification, auditing and evidence storage, which ensures the traceability and fairness of the verification, thereby avoiding potential disputes and denial of service.

[0040] The cloud storage data integrity verification method of the application mainly includes two stages: a storage stage and a verification stage. The storage stage is a process in which a data owner sends data to a cloud server for storage in a safe and private manner. The verification stage refers to a process in which the data owner verifies the data integrity of the data stored in the cloud server after the storage stage is completed. The specific implementation process is as follows:

[0041] (I) Preparation

[0042] Before the data owner and the cloud server interact, several preparations need to be made. First, the smart contract and the SGX application Enclave need to be deployed and started. The DO and the CS register and deposit on the smart contract. At the same time, the DO generates a master key msk locally.

[0043] (II) Storage stage

[0044] As shown in Figure 1 , the implementation process of the storage stage is as follows:

[0045] Step A1, the DO remotely authenticates with the SGX and negotiates a session key ssk.

[0046] The DO calculates the data identifier d id according to the data to be managed data.

[0047] d id = Hash(data)

[0048] Wherein, Hash() represents a hash algorithm, and SHA256 hash algorithm is adopted in the application.

[0049] The master key msk is used to encrypt the managed data data, and the encrypted managed data is obtained, denoted as ct data .

[0050] ct data = Enc msk (data)

[0051] Wherein, Enc msk () represents encryption with the master key msk, and symmetric encryption algorithm AES is adopted for encryption in the application. The session key ssk is used to encrypt msk, and the encrypted master key is obtained, denoted as ct msk .

[0052] ct msk = Enc ssk (msk)

[0053] Wherein, Enc ssk () represents encryption with the session key ssk, and symmetric encryption algorithm AES is adopted for encryption in the application.

[0054] If it is the first time to store data, the data owner DO needs to id ,ct data ,ct msk ) is sent to the cloud server CS; if the data has been stored before, it is necessary to (d id ,ct data ) is sent to the cloud server CS, such as Figure 3 shown.

[0055] Step A2: After receiving the data from the data owner, CS will id ,ct data ) is stored.

[0056] The implementation process is as follows:

[0057] Step A21: If it is the first time to perform storage, the cloud server will (d id ,ct data ,ct msk ) is loaded into SGX, SGX uses ssk to decrypt msk and obtain the master key msk:

[0058] msk=Dec ssk (ct msk )

[0059] Among them, Dec ssk () indicates decryption using the session key ssk.

[0060] And by utilizing SGX's Sealing mechanism, the master key msk used to encrypt data is sealed locally on the execution host, and only the SGX trusted zone can decrypt it, thus avoiding the need to transmit the master key again.

[0061] Next, use the decrypted msk to decrypt ct data , restore the data to be hosted:

[0062] data=Dec msk (ct data )

[0063] Among them, Dec msk () indicates decryption using the master key msk, and the present invention uses the symmetric encryption algorithm AES for encryption.

[0064] Step A22: If this is not the first time to perform storage, the cloud server will (d id ,ct data) is loaded into SGX, and the master key msk used to encrypt data is decapsulated from the execution host using SGX's Sealing mechanism. Next, the decapsulated msk is used to ct data Decrypt and restore the data to be hosted:

[0065] data=Dec msk (ct data )

[0066] Among them, Dec msk () indicates decryption using the master key msk, and the present invention uses the symmetric encryption algorithm AES for encryption.

[0067] Step A23, then judge d id Is it equal to Hash(data)?

[0068] If they are not equal, a storage error is returned;

[0069] If they are equal, continue hashing. data =Hash(data||d id ),ct hash =Enc ssk (hash data );

[0070] Among them, ct hash Indicates that the session key ssk encrypts data and d id The result after the hash value is used as the cloud data integrity proof. id The hash value of the session key ssk and the encrypted data are processed using the SHA256 hash algorithm and the AES symmetric encryption algorithm respectively.

[0071] Step A3: SGX performs calculations to generate an authentication report σ tee , certification report σ tee With ct hash Output together.

[0072] The certification report σ tee It can be sent to Intel's third-party service IAS (International Accreditation Service) for verification and return a verification report vr, certificate ca, and signature σ for the verification report IAS , will verify the report vr, certificate ca, signature σ IAS Packing, we get the proof of calculation correctness π:

[0073] π=(vr,ca,σ IAS )

[0074] Among them, vr contains the pair σ tee Validity verification results and SGX related information, σ IAS is the IAS to σ tee And the signature of the verification result, ca contains the public key of the signature.

[0075] Then π and ct hash Submit to the smart contract in the blockchain, where π is used as ct hash The computational correctness of π is proved. Since the signature σ contained in π IAS There is no need for trusted hardware, nor is there a need to contact IAS again to verify it, so the smart contract can parse the signature public key from the certificate CA and verify the σ IAS After the signature verification is successful, the smart contract parses the verification report vr and compares the information with the trusted configuration. After the comparison is completed, the smart contract will receive ct hash To keep evidence.

[0076] Step A4, DO can obtain ct from the blockchain hash , and decrypt it with the session key ssk to get the plaintext hash hash data =Dec ssk (ct hash ) and stored in its own local Cuckoo filter for subsequent verification.

[0077] (3) Verification stage

[0078] like Figure 2 As shown in the figure, the implementation process of the verification phase is as follows:

[0079] In step B1, DO and SGX perform remote authentication and negotiate a session key ssk′.

[0080] DO data identifier d of the managed data to be integrity verified id Send to cloud server CS, cloud server CS identifies the data according to d id , find the corresponding data (d id ,ct data ).

[0081] Step B2, CS will (d id ,ct data ) is loaded into SGX, and the master key msk used to encrypt data is decapsulated from the execution host locally using SGX's encapsulation mechanism.

[0082] Next, use the decapsulated master key msk to decrypt ct data , thus recovering data data = Dec msk (ctdata ).

[0083] Then judge whether data identifier d id and Hash(data) are equal:

[0084] If not equal, return verification error;

[0085] If equal, continue to execute hash data = Hash(data || d id ), ct′ hash = Enc ssk′ (hash data ) ;

[0086] Wherein, ct′ hash represents the result after the session key ssk′ encrypts data and the hash value of d id , and serves as the cloud data integrity proof.

[0087] Step B3, the SGX performs calculation to generate an authentication report σ′ tee , and the authentication report σ′ tee is output together with ct′ hash .

[0088] The authentication report is sent to the Intel third-party service IAS for verification and returns a verification report vr′, a certificate ca′, and a signature σ′ IAS of the verification report, and the verification report vr′, the certificate ca′, and the signature σ′ IAS are packaged to obtain a calculation correctness proof π′:

[0089] π′ = (vr′, ca′, σ′ IAS )

[0090] Then π′ and ct′ hash are submitted to the smart contract in the block chain, wherein π′ serves as the calculation correctness proof of ct′ hash . Since the signature σ′ IAS contained in π′ does not need a trusted hardware nor needs to contact the IAS again for verification, the smart contract can parse the signature public key from the certificate ca′ and perform signature verification on σ′ IAS . After the signature verification is successful, the smart contract parses the verification report vr′, compares the information therein with the trusted configuration, and after the comparison is completed, the smart contract receives ct′ hash for storage.

[0091] Step B4, the DO can obtain ct′ hash from the block chain and decrypt it with ssk′ to obtain the plaintext hash′data = Dec ssk′ (ct′ hash ). Then the hash data ′ is executed as the input of the query operation of the cuckoo filter, if the query is successful, the data is successfully verified in the cloud server. If the query fails, the data fails to be verified in the cloud server.

Claims

1. A cloud storage data integrity verification method for lightweight devices, first, the data owner and the cloud server should be registered and deposited on the blockchain smart contract; at the same time, the data owner generates a master key locally, characterized in that, It includes the data storage stage and the data verification stage: the data storage stage is when the data owner sends the data securely and privately to the cloud server for storage; The data verification phase refers to the data integrity verification performed by the data owner on the data stored in the cloud server after the storage phase is completed. The calculation of the cloud data integrity proof during the data storage or verification phase is performed in a trusted execution environment, and the session key is different for each storage or verification. The data storage stage includes the following steps: SA1: The data owner remotely authenticates with the trusted execution environment and negotiates a session key. The session key is combined with the master key to encrypt the data to be hosted and generate a corresponding data identifier. The data owner then sends the encrypted data to be hosted and the data identifier to the cloud server. SA2: After the cloud server stores the encrypted managed data and data identifier, it loads the encrypted managed data and data identifier into the trusted execution environment. It uses the isolated security zone provided by the trusted execution environment to decrypt the managed data and hash the managed data and managed data identifier. The resulting hash value is encrypted with the session key as the cloud storage integrity proof. SA3: The trusted execution environment generates an authentication report and sends it to the IAS for verification. The verification report, certificate, and signature returned by the IAS are packaged as proof of computational correctness for the encrypted cloud storage integrity proof. The encrypted cloud storage integrity proof and computational correctness proof are then submitted to the smart contract in the blockchain. If the computational correctness proof passes verification, the cloud storage integrity proof is stored on the blockchain. SA4: The data owner obtains the cloud storage integrity certificate from the blockchain and decrypts it to obtain the plaintext hash. Then the plaintext hash is used as input and the insert-store operation of the cuckoo filter is performed.

2. The method of claim 1, wherein the method further comprises: In step SA1, the data owner calculates the data identifier of the hosted data using a hash algorithm.

3. The method of claim 1, wherein the method further comprises: The data verification phase includes the following steps: SB1: The data owner performs remote authentication with the trusted execution environment and negotiates a session key; the data identifier that needs to be verified for integrity is sent to the cloud server; SB2: The cloud server finds the encrypted data to be hosted based on the data identifier, loads the encrypted data to be hosted and the data identifier into the trusted execution environment, decrypts the hosted data using the isolated security zone provided by the trusted execution environment, and performs a hash operation on the hosted data and the hosted data identifier. The resulting hash value is encrypted with the session key as proof of cloud storage integrity. SB3, the trusted execution environment generates an authentication report and sends it to the IAS for verification. The verification report, certificate, and signature of the verification report returned by the IAS are packaged as proof of computational correctness of the encrypted cloud storage integrity proof; The cloud storage integrity proof and computational correctness proof are then submitted to the smart contract in the blockchain. If the computational correctness proof passes verification, the cloud storage integrity proof is stored on the blockchain. SB4, the data owner obtains the cloud storage integrity proof from the blockchain and performs decryption processing to obtain the plaintext hash; then the plaintext hash is taken as the input of the query, and the query operation of the cuckoo filter is executed: if the query is successful, the integrity verification of the hosted data in the cloud server is successful; If the query fails, the integrity verification of the hosted data in the cloud server fails.

Images