SiRiUS : Securing Remote Untrusted Storage

1. SiRiUS: Securing Remote Untrusted Storage Eu-Jin Goh, HovavShacham, NagendraModadugu, Dan Boneh

2. Motivation • To make existing Network Files Systems more secure with no changes to the infrastructure. • Easy to use software to implement security for any legacy file systems.

3. Overview • Design Criteria • Design Overview • FS services • Implementation • Weaknesses • Extensions • Conclusion

4. System Design • No changes to file server • Adds security to the existing network file system • File sharing • Ability to share files with distinct read/write access • Confidentiality & Integrity • File data must be protected from unauthorized users • Untrusted server • Any requests coming to the server can be spoofed, hence, SiRiUS must have its own access control information

5. System Design (cont’d) • Access Control • Not limited by the underlying File system and provide its own access control • Key management • Easy key management and must be compatible with use in other applications simultaneously • Key distribution and access revocation • Freshness Guarantees • Timely revocation of access control • Latest version of the file

6. File System design Overview • User’s have one Master Encryption key (MEK) and one Master Signature Key (MSK) • On server : md-file and d-file • Each file data is encrypted using symmetric cipher (FEK) and signed (FSK) • Meta Data Freshness File (mdf-file) on server • periodically update time stamp the root mdf-file for freshness and sign using MSK

7. File Structure • md-file: • d-file: • mdf-file: A tree structure of hashed md-files File Data Encrypted (EFEK) Signature[Hash of data]FSK Hash(md-files) in the sub-directory Hash(md-files) in the directory Hash(md-files) in the root ||timestamp

8. Creating a File • Steps for creating a file Create hash and sign with DSA using user’s MSK Encrypt Keys with owner’s MEK Create Keys (FSK & FEK) Step 3 Step 1 Step 2 Create md-file Step 4 Encrypt file data using FEK and create d-file Update root mdf-file Step 5 Step 6

9. Creating a File : detailed • Step 1: DSA File signing key & AES File Encryption key • Step 2: Encrypt the keys using owner’s MEK and tag it with username • Step 3: Apply SHA-1 to {(Encrypted block|| FSK || timestamp || filename), MSK} - Signature

10. Creating a File : detailed • Step 4: md-file creation {Encrypted block || FSK || timestamp || filename || Signature} • Step 5: EFEK(data) EFEK(data) || {(hash(EFEK(data))), FSK} • Step 6: Update root mdf-file

11. Username Username Operations on FS • File sharing • Read/Write • Renaming Plaintext Plaintext Encrypted with MEK of user FEK FEK Encrypted with MEK of user FSK public key read read/write

12. File Links • Supports sym links if supported by underlying FS • Cannot support hard links • Key Management • Simple because it needs to track only MSK & MEK • Block removed from md-file and new FSK & FEK generated for encryption

13. Implementation • SiRiUS on Linux over NFS v3 • User level NFS loopback server • NFS client

14. NFS File Handle Cache • In NFS all file system objects are identified by unique NFS file handle • Cache the results of regular NFS calls for arguments and results • Changing Access Controls • User level permission tool • Random access and Low bandwidth • Implemented to deal with large files with size more than 8192 bytes. • Caching

15. Performance

16. Weaknesses • Deleting contents Attack : Attacker breaks into the server and deletes all files • Seizing File System Control Attack : Replace an existing file and update the root mdf-file and sign it • d-file Rollback Attack : Freshness guarantees checks the rollback on md-files but not on d-files

17. Extensions • Non-essential capabilities that improve performance/security of basic SiRiUS • Random Access & Low Bandwidth • Encrypted Pathnames • Large scale Group Sharing using NNL • Maintaining traditional file system semantics

18. Questions? Thank you