Secure File Sharing Presented by Vishal Kher February 13, 2004

2 References  E.-J. Goh, et al. SiRiUS: Securing Remote Untrusted Storage. In Proceedings of NDSS  M. Kallahalla, et al. Plutus scalable secure file sharing on untrusted storage. FAST 2003.

3 Outline  SiRiUS  Plutus  Comparison

4 Goals  System should be easy to install and use  No changes to file server  Secure file sharing –Confidentiality and integrity Data as well as meta-data –Key management –Read and read-write distinction –Freshness Meta-data

5 Assumptions  Untrusted File Server  File sharing for small groups  Trusted client machine  Presence of PKI or similar infrastructure

6 System Components d-fileData File md-fileMeta-data file FEKFile encryption key (symmetric key per file) FSKFile Signing Key (asymmetric) MEK, MSKFile owner’s encryption and signing key (asymmetric) md  -file Meta-data integrity file P U, S U Public and private key of user

7 File Structure E FEK (D)SIG FSK (H(D)) d-file Encrypted Key Block (users) Encrypted Key Block […] Public Key for FSK Metadata Last modified TS File name SIG MSK on md-file md-file Username FEK FSK Username FEK E PU Prevent swapping attacks

8 Freshness of md-file  File residing in user’s home dir belong to user  Creation –Hash all md-files and store the final hash in md  -file –Concat hash of md-files in a dir to md  -file of subdir –Sign the final hash (root level) along with timestamp and place in root md  -file  Update –The owner’s client updates after some time interval  Verification –Walk up the tree

9 Write  Assume owner updated the access control info  Write –Obtain md-file, verify signature on md-file –Obtain FEK and FSK –Obtain d-file and verify signature using pub key of FSK –Decrypt data –Encrypt modified data with FEK, hash sign using FSK –Rewrite the d-file  Dumb – sequential –Extension talks about random read and write

10 Read and Rename  Assume owner updated the access control info  Read –Obvious from previous description  Rename –Require updating the hash tree and md  -file

11 Key Management and Revocation  Key Management –Owner manages keys –User needs MEK and MSK  Revocation –Nothing special –User updates FEK and meta-data –Re-encrypts file

12 Performance

13 Discussion (1)  Roll-back –No data freshness –Replace current d-file with a valid old version  No suitable for large scale file sharing  Owner performs all the key management –Good for P2P  Huge performance overhead –Can further reduce some number of signatures  Storage overhead

14 Discussion (2)  Change of user’s public keys – Contact the owners of every file Keep/ search a list of these files –Do file owners have to figure this out?  Where should the keys be stored? –Smartcard –Encrypted using pass phrase Hassle to user How can they be accessed seamlessly?

15 Extensions  Random Access –Each block encrypted with AES, CBC with different random iv  Encrypt pathname using FEK –ls command will require all FEKs + decryption!  Large scale group scaling using NNL DB1SIG MSK DBnH(DB)n ….

16 Outline  SiRiUS  Plutus  Comparison

17 Goals  Low cryptographic overhead in file server  File server unaware of user’s identity  Secure file sharing –Decentralized Key management Completely pushed to users –Confidentiality and integrity Data and meta-data –Authorization Read and read-write distinction

18 Assumptions  Untrusted storage  Trusted client machine  User’s authenticate each other before obtaining keys over a secure channel –Key management is handled by users  Communications are secure

19 File Groups and Lock Box  Filegroup is a group of files with same privileges –Owned by same {owner, group}, have same permissions –Reduce the number of keys  Lock Box –Box with a lock that holds a bunch of keys –Need key to the box to access the stored keys

20 System Overview (1)  Each file block is encrypted with a different key –fileblock key  Every filegroup has a lockbox –Lockbox stores all file-block keys of files belonging to that filegroup –Associated with lockbox is a lockbox-key (symmetric) Encrypts file-block keys Owner distributes lockbox-keys to readers and writers  Reader writer distinction –Asymmetric keys: file-sign key, file-verify key

21 System Overview (2)  Integrity of data file –Writer hashes all data blocks of the file and signs the root using file-sign key  Confidentiality of meta-data –Encrypt names of files in dir using file-name key –Encrypt filegroup names using file-group key

22 File Structure E foo-key (foo) E bar-key (bar) E tmp-key (tmp) header E B-key (filegroupB) header E A-key (filegroupA) Inode 1 block 1 Inode 2 block 2 Inode 3 block 3 H(block 1) K file-block1 Root hash + sign Inode 1 header Using file-sign key for filegroupB File foo

23 Read  Reader wants to access foo  Browse to obtain name of the owner of foo  Contact owner for: –file-verify key, file-lockbox key –Verify the signature on root using file-verify key –Decrypt lockbox using file-lockbox key and fetch file-block keys –Decrypt file foo

24 Write  Reader wants to access foo  Contact owner for: –file-sign and verify key, file-lockbox key –Generates file-block keys –Encrypt blocks –Store lockbox and file blocks –Calculate hash tree, sign root, write the tree with sign  But… How to authenticate writers –Token per file group –Hash(Token, F) is stored in inode –Server verifies tokens before allowing writes

25 Revocation  Lazy revocation –Changes keys –Owner immediately updates meta-data –Mark file for re-encryption –Re-encrypt only on updated  File-groups –Same key multiple files  On write following revocation –key for re-encrypted file different!

26 Key Rotation  Every key has version numbers  Readers and writers should check the version before using the keys

27 Discussion  Total trust on insiders. –No notion of identity on the server –any authorized user can change and sign the data – Will the readers be able to track who changed it?  The owner will have to be online to distribute keys  Burden on owners –Good for P2P –How about enterprise?

28 Comparison Role of server Verify writesStore data (unmodified) PlutusSiRiUS File sharingDynamicStatic: A user cannot create file User’s identityHiddenIncluded in meta-data Key distributionDone by owner to userOwner puts the appropriate keys in the meta-data Hash treeUpdate by writer Includes data blocks Periodic update by owner Only includes meta-data RevocationLazy + key rotationNothing special Number of KeysLess: File groupsOne per user ScalabilityMore scalableLess scalable

29 Comments Thank You