1 / 28

Secure File Storage

Secure File Storage. Nathanael Paul CRyptography Applications Bistro March 25, 2004. Choosing an Encrypted File System (EFS). Require kernel patch? root needed How much control is root given? Swap space Key management Backups and recovery options

olin
Download Presentation

Secure File Storage

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 Storage Nathanael Paul CRyptography Applications Bistro March 25, 2004

  2. Choosing an Encrypted File System (EFS) • Require kernel patch? • root needed • How much control is root given? • Swap space • Key management • Backups and recovery options • Very few files need encryption or entire file system? • Sharing options?

  3. Multitude of solutions • Linux Crypto API • Windows EFS • CFS • Early UNIX implementation • SiRiUS • Steganographic file systems • not ready for use • ppdd • Encrypts root partition, and swap space?

  4. CFS • Early implementation by Matt Blaze • First free UNIX EFS • Client NFS server listening on localhost interface • Key for each directory • Uses passphrases • Implemented in user-level

  5. Accessing files main() { … read(); … } NFS Network VFS LocalFileSys

  6. CFS (a.k.a. /crypt) Mount points CFS … VFS LocalFileSys

  7. CFS call VFS again, but go to file on storage media VFS call (e.g., read()) Encrypt/Decrypt NFS

  8. Accessing files main() { … read(); … } CFS VFS EncryptedLocalFileSys …

  9. CFS Advantages/Drawbacks • Key for each directory • Usability? • Implemented in user-level (slow) • Makes it simpler • RPC calls • But most EFSs are slow • Not possible to have different files under different groups in same directory • IV is stored in group id field in inode

  10. Stackable v-nodes: CryptFS

  11. Linux CryptoAPI • File system mounted on loopback device which is mounted on directory mount point • Loopback device intercepts kernel commands

  12. So why SiRiUS? • Assumes file server untrusted • No change to file server • Distinguishes read/write access • Sharing • Only a few keys needed • Like CFS, users run user-level daemon • Good for sharing among small groups • Timely revocation • Rollback attacks

  13. main() { … read(); … } SiRiUS Network VFS LocalFileSys

  14. SiRiUS Overview • Intercepts NFS requests • Process requests and send to NFS server • Could mimic CFS • Process requests and send to VFS of local file system • SiRiUS faster with NFS (compared to CFS), since requests go straight to NFS server and not through VFS to regular NFS client on machine

  15. Files in SiRiUS • Files stored in 2 parts • md-file: file metadata • Access control • d-file: file itself • Encrypted with unique symmetric File Encryption Key (FEK) • Signed with a unique File Signature Key (FSK) • To read, user needs FEK • To write, user needs FSK

  16. Encrypted Key Block (User n) Metdata last modified timestamp Owner’s hash of metadata filename FSK md-files MEK Encrypted Key Block (Owner) Encrypted Key Block (User 1) … MSK used

  17. Username (or keyID) Username (or keyID) Encrypted Key Blocks Plaintext Plaintext Encrypted with MEK of user FEK FEK Encrypted with MEK of user FSK public key read read/write

  18. Freshness Guarantees • Prevent rollback attacks • Alice replaces new md-file with an older saved md-file • mdf-file: metadata freshness file • One in each directory of user’s file system • Stamped with unique Master Signing Key (MSK) of user • Contains root of hash tree of all md-files in current directory and mdf-files in immediate subdirectories

  19. Creating mdf-files • Apply SHA-1 hash on each md-file in current directory (verifying md-file signatures as you go) • Concatenate resulting hashes together with mdf-files of immediate subdirectories and apply SHA-1 hash to concatenation • Place final hash and directory name in mdf-file Note: Timestamp used before final hash of concatenated hashes on root mdf-file

  20. Verifying a file • Files are guaranteed up to timestamp on root mdf-file • Verifying a file in root directory • Compute mdf-file hash and check timestamps • Verifying a file not in the root directory • Apply first 2 steps of creation of mdf-file recursively up to root directory comparing each mdf-file in its subdirectories • Requires checking many hashes • What happens if a file in a non-related subtree’s hash doesn’t match up?

  21. File swapping attack • Bob wants access to Alice’s /home/alice/secret.txt, but Bob only has read access to /home/alice/readme.txt • Bob switches filenames with secret.txt and readme.txt • Would work if filename not included in md-file • Directory included in mdf-file to prevent directory swapping

  22. Creating a file • Generate random DSA signature FSK • Generate random AES FEK • Generate encrypted key block • Owner’s hash of metadata • Create md-file • Encrypt file data • Use FEK • Apply SHA-1 to encrypted data and sign with private key of FSK. Append hash to data. • Update root mdf-file

  23. File Sharing, Reading, Writing • Use IBE (or other PKI) • Will need public key of those that will have shared access to create their encrypted key blocks • Will need public key of owner to verify signature and freshness of md-file

  24. User keys • MSK, MEK • Can be used without SiRiUS • Revocation • Read: change FEK, remove user’s key block, update other key blocks with new FEK, reencrypt and sign d-file, update md-file signature, update root mdf-file • Write: same as read except create new FSK, and sign with new key (write implies read access)

  25. Performance (ms)

  26. Performance • Caching and optimizations pay off on larger files • If working on smaller files, it’s much slower • Read/Write • Encrypt data (decrypt for read), verify 3 signatures (2 for file integrity, one for freshness), generate a signature (not for a read)

  27. Conclusions • Encrypted file systems throw normal performance out the window • Read/write capabilities of SiRiUS are nice • Single user with just a few critical files • Program to manually perform encryption is probably sufficient

  28. How to really protect your data… • Burn it at 3,000 degrees...

More Related