Work has been carried out in partnership with the CEA to integrate additional security guarantees into the Parsec software. This solution is based on blockchain [link to the first 2 articles: https://parsec.cloud/la_blockchain_au_service_du_stockage_cloud_securise/ / https:/ /parsec.cloud/la_blockchain_au_service_du_stockage_cloud_securise_2/].
Parsec guarantees the confidentiality, integrity and authenticity of data stored in the cloud. However, in its current security model, the metadata server is assumed to be "honest but curious". This means that the server is "honest", it does not deviate from the protocol, but it is also "curious" about the data it sees in transit. In this model, data encryption is sufficient to preserve confidentiality vis-à-vis the server. Our work focuses on the case where the server is said to be "malicious", attempting to compromise data integrity.
A look at how Parsec works
Parsec comprises three entities: the client workstation, the metadata server and the cloud (Figure 1).
Data to be stored in the cloud is sent by clients to the metadata server. The server acts as a coordination service between the clients and the cloud. The encrypted, block-cut data is then stored in the cloud.
Figure 1: Security model and Parsec software entities
New safety model
In Parsec, the client is trusted and the server is considered "honest but curious". Only the cloud is considered an active attacker.
However, the project now focuses on the case where the server has been attacked and is now malicious. It is considered to be attempting to compromise data integrity. The data may be invalid or out-of-date. This is possible if, for example, the server does not take into account modifications from clients.
Solution
- Ghost blockchain
The concept of ghost blockchain comes from the article Ghostor(https://eprint.iacr.org/2020/648.pdf). This article proposes a file-sharing system based on a client-server architecture in which the server is considered compromised. The system guarantees both client anonymity and data integrity through a verifiable history.
The history is stored in a blockchain and includes read and write operations performed by customers and checkpoints carried out at regular intervals.
Verification is carried out by customers who have access to the data written to the blockchain.
- Applying ghost blockchain to Parsec
To address the issue of data integrity, the ghost blockchain concept has been applied to Parsec.
The architecture of the new system is shown in Figure 2 below.
Figure 2: Parsec architecture including blockchain
The system includes a blockchain, which can be read and written by the server and clients.
Every read or write operation performed by a client is signed. It is recorded both locally by the client and by the server.
To check that the server has taken client operations into account, an epoch and history checking mechanism is set up.
Figure 3: History verification mechanism
At the end of each epoch (regular time interval), the hash of the last transaction stored by the server is placed in the blockchain. Clients can also request a history (between two epochs) from the server. This mechanism is illustrated in Figure 3. Three checks are possible on the basis of this history:
- each client can check that its local operations are present in the server's history version
- by joining forces, customers can also check that all their transactions have been taken into account
- clients can finally check that the hash in the blockchain corresponds to the last operation performed by the server.
Customers can therefore check the history of operations taken into account by the server.
This solution detects whether the server has been compromised and has not followed the protocol concerning operations received by clients. The solution does not prevent malicious behavior, but rather detects it a posteriori.
This solution also detects a corrupt PARSEC metadata server when several instances of the parsec server are deployed. Indeed, in order to guarantee higher availability and protect against denial-of-service attacks, several instances of the metadata server can be deployed. The ghost blockchain algorithms developed in partnership with the CEA can also be used to detect a compromised server and thus protect against Byzantine Fault attacks.
