Overview of Cryptographic File System for Unix (CFS)

1. Overview of Cryptographic File System for Unix (CFS) Vishal Kher Friday, October 11, 2002 Department of Computer Science University of Minnesota

2. Introduction • Title of the paper • “A Cryptographic File System for Unix” • Author • Matt Blaze (Bell Labs) • Abstract • Add encryption services to the file system • Users associate a key with the directories they wish to encrypt • Files and their pathnames in this directory are encrypted using the user specified key • Clear text is never stored on the disk • Encrypted files are not special

3. Outline • Security issues • Cryptographic building blocks • Why file system level security? • CFS design goals • CFS functionality • CFS file encryption scheme • CFS architecture

4. Security Issues • Authentication • Specific to the security objective, which one is trying to achieve • Identification • Data origin authentication or message authentication • Access control • Data Integrity • Data Secrecy • Keep data encrypted • Keep metadata encrypted • Secure data transfer and backups • Should we trust the super user?

5. Cryptographic Building Blocks • Block Cipher • Breaks plaintext into block of fixed length • Encrypts one block at a time • Data Encryption Standard (DES) • Symmetric key block cipher • 56-bit key, 64-bit plaintext and ciphertext • Four modes • Not very secure • Advance Encryption Standard (AES) • New standard • Better security and faster than DES • Variable key length

6. Electronic Codebook Mode (ECB) • Plaintext is handled 64-bits at a time • Each block is encrypted/decrypted independently • Identical plaintext (under the same key) result in identical ciphertext • Bit errors in a single ciphertext affects decryption of that block particular block P2 P1 DES encrypt DES decrypt DES encrypt DES decrypt K K C1 C2 P1 P2

7. Cipher Block Chaining Mode (CBC) • Ci = EK[Ci-1Pi], C0 = IV • Pi = Ci-1DK[Ci], C0 = IV • A single bit error in Ciaffects decryption of Ci,Ci+1 • Self-synchronizing: error Ci (not Ci+1, Ci+2) is correctly decrypted to Pi+2 C1 C2 P1 P2 IV   K DES decrypt K DES decrypt DES encrypt DES encrypt K K  IV  C1 P1 P2 C2

8. Cipher Feedback Mode (CFB) • Re-ordering Ci blocks affects decryption • Bit errors in any single r-bit Cjaffects decryption of next n/r blocks • Self-synchronizing, needs n/r blocks to recover Shift register Shift register r r E K K E Oj Oj r r Cj Pj Pj Cj r r r r Encrypt Decrypt

9. Output Feedback Mode (OFB) • Keystream is plaintext-independent • Bit errors affects the decipherment of only that character Shift register Shift register K K E E Oj Oj r r Cj Pj Pj Cj r r r r Decrypt Encrypt

10. Why File System Level Security? • User-Level Cryptography • User tools or programs (Unix crypt program) • User could fail to encrypt the file • Need to supply keys several times • File is in clear form till the user encrypts it • If the disk is on remote server data needs to be sent in clear over the network • Encryption in application software (text editors) • Each program needs to support to functionality • Need to supply key to each application • Encryption is spread among multiple applications, need to trust each application • Same file could be opened in different applications • Applications could be remote • Cumbersome

11. Why File System Level Security? • Hardware-Level Cryptography • Specialized hardware to encrypt and decrypt files • Specialized hardware to perform end-end encryption • Problems • Each client and server need the specialized hardware • How to share files? • Files cannot be decrypted if the hardware is not available • Each file access requires two cryptographic operations by the server, once for the network and once for the disk • Solution is file system level security

12. CFS Design Goals • Protection of file contents and meta-data • Protection of network connections • Keys should not have to be supplied more than once • Encrypted files should not behave differently from other non-encrypted files • Low performance penalty due to encryption scheme • Good key management techniques • Concurrent access to encrypted files • Provide secure file services in a seamless manner

13. CFS Functionality • Provides a virtual file system on the “client’s machine” • Typically mounted in /crypt, users access encrypted files through this directory • “User’s give an attach command” to create an entry in /crypt • Each entry in the /crypt associates a cryptographic key with a directory located elsewhere (in encrypted format) • The underlying encrypted directories can reside on any file system including remote file systems

14. CFS Functionality • Keys are supplied by the user in the form of ASCII passphrases (at least 16 characters long) • Contents in /crypt appear in clear text to the owner of the file • To create an encrypted directory /usr/mab/hide $cmkdir /usr/mab/hide $ Key:(enter passphrase, which does not echo) $ Again:(same phrase entered again)

15. CFS Functionality • To “use” an encrypted directory, attach the encrypted directory to a local virtual directory • For example, to attach the directory created above to the name /crypt/matt perform the following, $ cattach /usr/mab/hide matt $ Key:(same key used in the cmkdir command) • If the key is supplied correctly, the user “sees” /crypt/matt as a normal directory; all standard operations work as expected • The actual files are stored encrypted under /usr/mab/hide, which are not used directly

16. CFS Functionality • To create a single encrypted file $ ls -l /crypt total 1 drwx------ 2 mab 512 Apr 1 15:56 matt $ echo "murder" > /crypt/matt/crimes $ ls -l /crypt/matt total 1 -rw-rw-r-- 1 mab 7 Apr 1 15:57 crimes $ cat /crypt/matt/crimes murder

17. CFS Functionality • List contents of /usr/mab/hide $ ls -l /usr/mab/hide total 1 -rw-rw-r-- 1 mab 15 Apr 1 15:57 8b06e85b87091124 $ cat -v /usr/mab/hide/8b06e85b87091124 M-Z,kˆ]ˆBˆVM-VM-6A˜uM-LM-_M-DM-ˆ[ • Once done remove entry under /crypt using cdetach matt • Only the user who issued the cattach command can see the clear text file • After cattach the user does not need to provide the key, access is based on the uid

18. CFS Functionality • Problem • If the user’s account is compromised, the attacker can see all the encrypted files • Solution • Mark the file as obscure, files marked obscure do not appear in a listing of /crypt • The ccat program • Decrypts files if CFS is unavailable • User should provide the keys

19. CFS File Encryption Scheme • CFS uses DES in ECB+OFB mode • Why ECB+OFB? • Only ECB mode • A given block of plaintext encrypts to the same ciphertext • Chaining modes • A write to a middle of a file could require reading and re-encrypting the preceding cleartext • And then rewriting the following data • Difficult for random read or write • DES with 56-bit key encryption is vulnerable to exhaustive search of the key space

20. CFS File Encryption Scheme • Lets solve the problems in the ECB mode • Identical plaintext blocks in a file will encrypt to the same cipher text • Use file block numbers to identify each block uniquely • But, there is one more problem, identical blocks in different files present at the same place if encrypted with the same keys, will give the same ciphertext • Use inode and the block number together to identify a unique file and a unique block in the file • OFB is used to generate a pseudo-random bit mask and provides an additional round of encryption

21. CFS File Encryption Scheme • Encryption Scheme • The passphrase entered by the user is used to create two 56-bit keys, K1 and K2 • Pre-compute a 0.5MB long pseudo-random bit mask using K1 and DES with OFB mode Shift register r K1 E Oj r O1 O2 On ……

22. CFS File Encryption Scheme • Ep = DES(K2,DpOp%m) • Where, • p is the byte offset • m is the length of the pre-computed bit mask • Ep is the ciphertext block of a file at offset p • % is modulo • Oi is the ith OFB output block • To eliminate identical blocks at the same offset but from different files to encrypt to the same ciphertext • Ep = DES(K2,DpOp%m i) • Where, • i is IV generated from the inode number at creation time

23. CFS File Encryption Scheme • Problems • While calculating p%m more than one p can map the the same value • For example, p1 = 10, p2 = 30, m = 20 • P1%m = p2%m = 10 • The i node number can change after backup or restore operations • Need to store IV along with the file

24. CFS File Encryption Scheme • IV could be stored • At the beginning of the file, this will shift the contents from block boundaries • As a block in the file, this will waste space • In the inode itself, but CFS sits above NFS and cannot add new file attributes • Use existing fields in the inode • CFS offers two modes • Without IV, less secure • With IV • IV is stored in the gid field of inode • CFS reports the group ownership of the root directory as the group of files in this directory • Small risk, group could be changed outside CFS • Data cannot be recovered

25. Vnode File System Architecture User-Level Application Any Program System Calls Sys Call interface Unix Kernel (local) FS Client FS interface (local or remote) Sys Call interface File System (local or remote) Disk

26. CFS Architecture Encrypt- Decrypt Sys. Call interface Disk Sys. Call interface Program C E FS Server cfsd FS Client FS Client localhost

27. CFS Architecture • CFS prototype is implemented at user level • Communication with the Unix kernel via NFS interface • Each client machine runs a NFS server (cfsd) that interprets CFS requests • NFS client initiates the requests • NFS client – cfsd communication using RPC • CFS uses Unix system calls for read and write (after decrypting or encrypting them) • For each file accessed through attach point a file handle is generated

28. CFS Architecture • cfsd maintains a table of handles and their corresponding encrypted names • To avoid repeated open and close, cfsd maintains a cache • cfsd accepts RPCs that originate from a privileged port to avoid spoofing • Provides E2E encryption • Problems • No message authentication • No data integrity • Does not support file sharing

29. Questions? Wake up, this is the last slide! Thank You