ChainFS: Blockchain-Secured Cloud Storage

Qiwu Zou, Yuzhe Tang, Ju Chen, Kai Li, Charles A. Kamhoua, Kevin Kwiat, Laurent Njilla

​

​

​

​

​

​

Syracuse University Air Force Research Lab Army Research Lab

​

Outline

1. Introduction
2. Systems approach
• Overall architecture
• Abstraction and uses of Blockchain
• Implementation and integration
3. Evaluation
4. Conclusion

​

2

Introduction: Securing cloud using Blockchain

• Outsourced cloud storage and file system (FS) is popular computing scheme
• Dropbox, Github, IoT cloud are built on cloud FS service�
• Yet, cloud is not trustworthy
• Data breaches: Cambridge analytica, Equifax, Target, etc.�

​

3

Introduction: Securing cloud using Blockchain

• Outsourced cloud storage and file system (FS) is popular computing scheme
• Dropbox, Github, IoT cloud are built on cloud FS service�
• Yet, cloud is not trustworthy
• Data breaches: Cambridge analytica, Equifax, Target, etc.�
• We propose to secure multi-user cloud file-system by Blockchain

​

4

System & Threat Model

• Three parties:
• Clients / users
• Server hosted in the cloud
• Blockchain
• Clients and Blockchain are trusted for data integrity
• Malicious cloud server launches forking attacks, consistency-violation attacks

System & Threat Model

• Focus on two workflows in a multi-user file system:
• Key distribution for multi-user file system
• A public-key directory storing the key-identity binding and helping clients establish authenticated connections for file sharing�
• Consistency server by logging file-system operations
• Following the SUNDR protocol [1] of two server components: a block store that stores the file content and a consistency server which is an auditable log of RPC operation

System & Threat Model

• A core abstraction: logging key-value stores.
• Key-value store API: �Put(key,value), value=Get(key)
• Consistency violation: Read does not return fresh write.�put(key)=X, put(key)=Y, Bob.get(key)=X
• Forking attack: Server forking clients’ views [1].�Alice.get(key)=X, Bob.get(key)=Y

Two Trusted Functionalities/Cases

1. Logging with prevention of forking attacks
1. Done by Blockchain�
2. Logging to detect storage-consistency violation.
• Done by clients

Case 1: Blockchain for Preventing Forking Attacks

• Applying Catena [2] in the context of SUNDR [1] consistency server
• Preliminary:
• SUNDR[1] consistency server is a log of FS operations on the cloud, making forking attack detectable (fork consistency)
• Catena[2] is a Blockchain-based log attestation scheme preventing forking attacks.
• ChainFS attaches each FS operation to a dedicated Catena transaction on the Blockchain.

Case 1: Blockchain for Preventing Forking Attacks

• Step 1: Attestation: Server attests to a total-ordered log of operations by sending one Catena[2] transaction per operation
• A Catena[2] transaction fully spends the UTXO (unspent transaction output) of its previous transaction.
• Step 2: Client verification: Each client downloads transaction history and verify some conditions:
• If its local operation is included
• If a transaction i spends full UTXO of transaction i-1
• If a transaction i is signed off by server account.

Case 2: Client-based Consistency Checking

After forking prevention, ChainFS client checks the strong-consistency condition on the verified log

• Preliminary: In strong consistency, all writes are total-ordered by their real-time order and a read must reflect the latest write on this total order.
• Each client need to maintain the entire global log for worst-case consistency checking.

Application Scenarios

• In workflow 1, Blockchain for logging file-system operation history.
• Challenge: file-system operation occurs frequently
• In workflow 2, Blockchain for public-key directory in multi-client data sharing
• Consistency guarantee makes sure no revoked key is still in use.
• Challenge: verify that correct keys are included in PK directory.

System Implementation

• Implementation by integration to S3FS
• Preliminary: S3FS is a FUSE-based file-system client for connections to Amazon S3.
• ChainFS implemented in two planes:
1. Blockchain logging: the off-chain data is a log
2. Blockchain digest: the off-chain data is snapshot of all related FS data (including file content and metadata such as inode).

System Implementation

Connection from FUSE client to Blockchain is implemented through an intermediary (web service) that translate CURL requests to Ethereum requests.

Web server

FUSE

Blockchain

CURL request (operations)

Geth request

Evaluation: File Write Latency

• LFS [3] small file benchmark (with Linux dd utility) to generate 1000 small files with sizes varying from 1 KB to 100 KB (small file) and from 1 MB to 1000 MB (large file).
• Report the average time and standard deviation.

​

​

Figure 3. File write latency with large files

Figure 2. File write latency with small files

Evaluation: File Read Latency

• Client creates 100 files of variable sizes (from 1 KB to 100 KB) and then runs Linux CAT commands to read the files. �
• Report the time of running CAT�
• ChainFS adds about 30% �overhead of regular reads

�Figure 4. File read latency

Conclusion

• ChainFS is a distributed file system on untrusted cloud with security to support multi-user file sharing.�
• The security stems from repurposing the security of Blockchain.

References

• [1] J. Li, M. N. Krohn, D. Mazieres, and D. E. Shasha, “Secure Untrusted Data Repository (SUNDR),” in OSDI, 2004, vol. 4, pp. 9–9.�
• [2] A. Tomescu and S. Devadas, “Catena: Efficient Non-equivocation via Bitcoin,” in 2017 IEEE Symposium on Security and Privacy (SP), 2017, pp.393–409.�
• [3] M. Rosenblum and J. K. Ousterhout, “The Design and Implementation of a Log-structured File System,” ACM Trans. Comput. Syst., vol. 10, no. 1, pp. 26–52, Feb. 1992.

18

Questions?

Contact: Yuzhe Tang

Syracuse University

ytang100@syr.edu

Thank you!

19