1 / 29

Secure File Sharing

Secure File Sharing. Presented by Vishal Kher February 13, 2004. References. E.-J. Goh, et al. SiRiUS: Securing Remote Untrusted Storage . In Proceedings of NDSS 2003. M. Kallahalla, et al. Plutus scalable secure file sharing on untrusted storage . FAST 2003. Outline. SiRiUS Plutus

verity
Télécharger la présentation

Secure File Sharing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure File Sharing Presented byVishal Kher February 13, 2004

  2. References • E.-J. Goh, et al. SiRiUS: Securing Remote Untrusted Storage. In Proceedings of NDSS 2003. • 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-file Data File md-file Meta-data file md-file Meta-data integrity file FEK File encryption key (symmetric key per file) FSK File Signing Key (asymmetric) MEK, MSK File owner’s encryption and signing key (asymmetric) PU, SU Public and private key of user

  7. EPU EPU File Structure EFEK(D) SIGFSK(H(D)) d-file Username Username Prevent swapping attacks FEK FEK FSK EncryptedKey Block(users) EncryptedKey Block[…] Public Keyfor FSK MetadataLast modified TS Filename SIGMSKon md-file md-file

  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 • lscommand will require all FEKs + decryption! • Large scale group scaling using NNL DB1 DBn …. H(DB)n …. H(DB)n SIGMSK ….

  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 • fileblockkey • 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 Inode 1 header Inode 1block 1 Inode 2block 2 Inode 3block 3 H(block 1)Kfile-block1 Root hash + sign H(block 1)Kfile-block1 H(block 1)Kfile-block1 File foo Using file-sign key for filegroupB

  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

  29. Comments Thank You

More Related