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 files
main() {
…
NFS
read();
…
VFS
}
Local
FileSys
Network
CFS (a.k.a. /crypt)
CFS
Mount
points
VFS
Local
FileSys
…
CFS
VFS call
(e.g., read())
NFS
Encrypt/
Decrypt
call VFS again,
but go to file on
storage media
Accessing files
main() {
…
CFS
read();
…
}
VFS
Encrypted
Local
FileSys
…
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() {
…
SiRiUS
read();
…
VFS
}
Local
FileSys
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
MEK
md-files
Encrypted Encrypted
Key Block Key Block …
(Owner)
(User 1)
Metdata last
modified
timestamp
Encrypted
Key Block
(User n)
FSK
Owner’s hash
filename of metadata
MSK
used
Encrypted Key Blocks
Username
(or keyID)
FEK
read
Username
Plaintext
Encrypted
with MEK of
user
(or keyID)
Plaintext
FEK
FSK
public
key
read/write
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-files
1.
2.
3.
Apply SHA-1 hash on each md-file in current
directory (verifying md-file signatures as you go)
Concatenate resulting hashes together with mdffiles 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
Verifying a file
• Files are guaranteed up to timestamp on root mdffile
• 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...