Trusted Continuity Proof
For a more accurate understanding of this section, it is recommended that readers read network architecture and file workflow sections in advance.
Background
With the development of the digital age and the increasing data generation, storage, transmission and usage, the data availability has become a key technical challenge. In traditional data storage and transmission methods, data is often stored in a centralized server, which encounter issues including single point of failure and data security. As a decentralized storage and transmission method, CESS network provides a new technical solution to solve these problems.
Definition
In a decentralized storage network, how do we verify that storage nodes are indeed providing continuous data availability so that data owners can retrieve it at any time? CESS has designed a trusted continuity proof mechanism based on cryptography, which regularly verifies the availability of data through interactive audit responses without retrieving the stored data. It includes the following features:
Managed continuity proof. In this solution, the data owner is no longer bound to any computational overhead, such as data preprocessing. The data owner only needs to complete the data upload to obtain the managed periodic data integrity audit services.
Support integrity auditing for multiple data backups. Through TLS, the data owner passes the key to a trusted environment (e.g., Intel SGX) and encrypts it to defend against Outsourcing Attacks and Sybil Attacks.
Scalable lightweight solution. We have designed a lightweight solution by transferring most of the computing load of TEE Workers to storage nodes. This will greatly reduce the loads on TEE workers and improve the scalability of the entire system.
Aggregation proof and public verification. All TEE workers in our scheme share the same pair of signature keys, so the storage node can generate aggregated proofs for large amounts of data and support public verification.
Key revocation and update. Although a trusted environment can maximize the privacy of shared keys, it is still necessary to make contingency plans for key leakage. Based on a lightweight solution that enables direct signature updates to stored data, we can further enhancing the robustness of the system.
Data dynamism. Support data owners to update outsourced data.
Algorithm Description
The algorithm of the trusted continuous proof mechanism is described as follows.
Setup: System initialization, Enclave of TEE Worker generates public and private parameters.
TagGen: Enclave of TEE Worker is responsible for processing file F and generating a tag in a signed format for later proof generation and verification. TEE Worker sends the output parameters, together with file F, to the storage node for storing. The process of calling this algorithm is also known as "marking".
Chal: Each time a random challenge is initiated, the blockchain network (randomly selecting consensus nodes for execution in each cycle) generates challenge parameters for data segments on the entire network .
ProofGen: Based on the challenge information, the storage nodes calculate the proof.
Verify: TEE Worker verifies the proof result.
In addition to the above basic operations, the trusted continuous proof mechanism also supports aggregation proof and batch verification functions.
AggProofGen: Storage nodes calculate proof based on challenge information and all files being challenged.
BatchVerify: TEE Worker batch validates proof results.
Algorithm flow
Tee worker enters network
System initialization: Enclave, the trusted environment of TEE Worker, invokes the system initialization algorithm Setup to obtain the shared secret (private) key. According to the sequence of TEE Worker entering network, there are the following two types of network entering methods:
The first node enters the network: The consensus node connects to the blockchain network, and TEE Worker initializes
Setupto generates a shared secret key pair. Among them, the private key sk is saved, and the public key pk is uploaded to the chain.Subsequent node enters the network: The consensus node connects to the blockchain network, and the TEE Worker obtains the shared secret (private) key sk from other TEE Workers that have entered the network through a secure channel.
Trusted marking
The storage node first sends data to the TEE Worker for marking.
After receiving the data that needs to be marked, the TEE Worker passes the data into Enclave and invokes the TagGen algorithm to return the output parameters and file to the storage node.
After verification, the storage node stores the processed file locally and synchronously updates the on-chain status.
Continuous Challenge Verification
When the blockchain network initiates a challenge, the Chal algorithm is called to output the challenge information.
After the storage node reads the challenge information of this round, it calls the AggProofGen algorithm to generate the aggregation proof and send it to the TEE Worker.
After receiving this round of certification, TEE Worker calls BatchVerify algorithm to verify the results.
Extended Reading
Introducing Probable Data Possession
Introducing Proofs of Retrievability
