Secure storage

1. Secure storage • Papers • AES-CBC + Elephant diffuser • A Disk Encryption Algorithm for Windows Vista • Niels Ferguson, Microsoft, niels@microsoft.com • August 2006 • How to Manage Persistent State in DRM Systems • William Shapiro and Radek Vingralek • August 2001 • Presentation by Petri Yllö 30.3.2007

2. Overview, example system model security perimeter RAM volatile memory • Confidentiality imple-mented with encryption • Integrity options • Implicit: meaningful decryption output • Explicit: Message Authentication Code (MAC) stored with data records • Reply attack detected by comparing counters TPM (persistent) one way counter encryption key ROM boot start code encryption application read and write Hard disk encrypted data MAC copy of counter attack

3. BitLocker • Enterprise and Ultimate editions of Windows Vista • Target: protect data on lost laptop’s HD. • Protects logical OS volume. • Requires another 1,5 GB “system volume”. • Cryptographic keys stored on TPM, USB or PIN • TPM is primary option. Easiest for user, but enables hardware-based attacks. • OS decryption available, once OS kernel is loaded.

4. Attack model • The attacker has many known (but not chosen) plaintext/ciphertext pairs for different sectors. • The attacker has the ciphertexts for a large number of chosen plaintexts for different sectors. The plaintexts are chosen before the attacker gets access to the laptop. • The attacker has access to a slow decryption function for some of the sectors. • The attacker gets several ciphertexts of plaintexts for the same sector with a known (but not chosen) difference. • The attacker succeeds if he can modify a ciphertext such that the corresponding plaintext change has some non-random property.

5. Secure boot • TPM v1.2 PCR’s are used to keep track of the code that runs. • Encryption key is sealed against a particular set of PCR values. • At power-up the processor starts running the BIOS from ROM (secure code). • Extends the BIOS PCR with the entire BIOS code and proceeds with the rest of the BIOS startup. • MBR of the hard disk, extends the boot sector PCR with the sector's data, and then executes the code in the boot sector. • All newly-loaded code before the switch point is first measured using an extend function before it is executed. • At the switch point the TPM unseals the BitLocker volume encryption key. • After the switch, all further data is read from the encrypted volume. • Any change to the code, requires that the keys be re-sealed to the new PCR values. • Switch to using BitLocker encryption at the first opportunity.

6. Authentication of the data on the disk • No practical solution to add MAC to each encrypted block. • Encryption per sector basis • No extra room for additional data • Poor-man’s authentication • Changes in the ciphertext will crash the machine rather than helping the attacker • Second line of defense ignored: digital signatures on executables

7. The Cipher: AES-CBC + Elephant diffuser • Advanced Encryption Standard (AES) was adopted in 2001 as a successor to DES • In Cipher Block Chaining (CBC) mode, the plaintext is XORed with an Initial Vector (IV) and then encrypted. • By default sector and AES keys 128 bit, 256 bit version also available • Diffuser added to make manipulation attacks harder. • At least as secure as AES-CBC • 30 clock cycles/byte on Pentium 4, faster than peak data rate from disk • An option with only AES-CBC is available for those few customers that have formal requirements to only use government-approved encryption algorithms.

8. The cipher IVs:= E(KAES, e(s)) Ks:= E(Ksec, e(s)) || E(Ksec, e’(s)) Diffuser Decrypt A: for i = 0,1,2,,,,n * Acycles -1 : di← di+ (di-2 XOR(di-5 <<< R(a)i mod 4)) Encrypt A: for i = n * Acycles –1,,,,2,1,0 : di← di - (di-2 XOR(di-5 <<< R(a)i mod 4)) Decrypt B: for i = 0,1,2,,,,n * Bcycles -1 : di← di+ (di+2 XOR(di+5 <<< R(b)i mod 4)) Encrypt B: for i = n * Bcycles -1,,,,,2,1,0 : di← di - (di+2 XOR(di+5 <<< R(b)i mod 4))

9. DRM Systems • Secure binding of digital content to a contract • The contract conditionally grants the user the right to access the content and it enforces consequences • Typically distributed systems, with content delivered from servers. • Persistent data includes • The content itself. • Certificates used for authentication and authorization in the DRM system. • Account balances or usage counters. • Start dates used by subscription contracts. • Auxiliary data used to support efficient or disconnected operation of clients (such as content decryption keys).

10. DRM Requirements • Fault tolerance • Atomicity, isolation, durability • Security • Secrecy, tamper-detection, prevent reply attack • Performance • Resource consumption • Scalability

11. Mechanisms 1 • Server based data repositories (locker services) • Physically secured • Accidental corruption reduced • Performance penalty • No offline content consumption

12. Mechanisms 2: Secure memories Merkle tree – on line tamper detector • Tree structure for better performance with limited secure memory

13. Mechanisms 3: Secure audit logs • Log user transactions in a local secured log • Encryption to provide data secrecy • Linear chain of hash links to every element in the log provide tamper detection. • The hash of the end of the log is periodically sent to a remote server • Sequence numbers in the log are used to prevent the replay attack. • Truncation entries after last sent to a remote server could go undetected.

14. Mechanisms 4: Secure file systems • Secrecy: encrypted file systems • Tamper detection • SFS-RO many users access read-only files • Uses a tree of hashes to verify the content • The root inode, is signed with the private key of the file system • Protected File System (PFS) • cryptographic hashes over all data and meta-data blocks to detect any tampering • no protection against replay attacks. • SUNDR no protection against replay attack

15. Mechanisms 5: Secure database TDB • Log-structured Merkle tree implementation • Secrecy by encryption of chunks with a secret key from ROM • Tamper-detection by signing the commit chunks with a secret key from ROM • Replay attack is prevented by adding the one-way counter to the commit chunk • Fine grained recovery based on transactions • Transactions committed by adding a commit chunk to the log • Location map is updated to stable memory only at a checkpoint

16. Mechanisms 6: GnatDb • For small databases simplified store at the cost of performance • Location map is an array

17. DRM Conclusion • Avoid persistent state requirement in clients • Access to named records and transactional semantics for updates • Ideally wanted a database system that provided both secrecy and tamper detection • Best choice: TDB or GnatDB for small devices • Log structured storage benefits • tamper-detection • atomic updates • copy-on-write snapshots for fast backups • concentrating all writes in a few blocks • traffic analysis harder