Secure File Storage

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)
CFS
Mount points

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
md-files
MEK
Encrypted Key Block (Owner)
Encrypted Key Block (User 1)

MSK used
17
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 users 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 subtrees
  hash doesnt match up?

21
File swapping attack

• Bob wants access to Alices /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
• Owners 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 users 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, its 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...