Secure File Storage Nathanael Paul CRyptography Applications Bistro March 25, 2004.

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...