Post on 30-Dec-2015
description
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
• Very few files need encryption or entire file system?
• Sharing options?
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?
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
Accessing filesmain() {
…
read();
…
}VFS
NFS
LocalFileSys
Network
CFS (a.k.a. /crypt)
VFS
CFS
LocalFileSys
…Mount points
CFS
NFS Encrypt/Decrypt
VFS call (e.g., read())
call VFS again, but go to file on storage media
Accessing filesmain() {
…
read();
…
}VFS
CFS
EncryptedLocalFileSys
…
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
Stackable v-nodes: CryptFS
Linux CryptoAPI
• File system mounted on loopback device which is mounted on directory mount point
• Loopback device intercepts kernel commands
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
main() {
…
read();
…
}VFS
SiRiUS
LocalFileSys
Network
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
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
md-files
Encrypted Key Block (Owner)
Encrypted Key Block (User 1)
Encrypted Key Block (User n)
… FSK
Metdata last modified timestamp
filenameOwner’s hash of metadata
MSK used
MEK
Encrypted Key Blocks
Username
(or keyID)
FEK
FSK public key
Plaintext
Encrypted with MEK of user
read/write
read
Username
(or keyID)
FEK
Plaintext
Encrypted with MEK of user
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
Creating mdf-files1. Apply SHA-1 hash on each md-file in current
directory (verifying md-file signatures as you go)
2. Concatenate resulting hashes together with mdf-files of immediate subdirectories and apply SHA-1 hash to concatenation
3. Place final hash and directory name in mdf-file
Note: Timestamp used before final hash of concatenated hashes on root mdf-file
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?
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
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
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
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)
Performance (ms)Test File Size Kernel NFS DumbFS SiRiUS
File Creation
0 0.4 3.4 14.5
File Deletion
0 0.3 0.4 1.1
Sequential Read
8 kb 0.9 1.4 18.0
Sequential Write
8 kb 1.1 2.0 21.9
Sequential Read
1 Mb 96.7 97.8 223.8
Sequential Write
1 Mb 100.0 102.7 632.9
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)
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
How to really protect your data…• Burn it at 3,000 degrees...