Encrypting stored data

1. Encrypting stored data Aalto University, autumn 2011

2. Outline • Scenarios • File encryption • Encrypting file system • Full disk encryption • Data recovery • Simple applications of cryptography • Good examples of how difficult it is a build secure systems [These slides are partly based on Microsoft material.]

3. Data encryption • Scenarios: • lost and stolen laptop computers • stolen servers • decommissioning hard disks  Risk of disclosure of confidential data • The obvious solution: encrypt data on disk • But computer security is never quite so simple: • Security often conflicts with usability • Security often conflicts with reliability; plan for data recoveryis needed • System design mistakes or programming errors could compromise data

4. file encryption

5. ******* Simple file encryption • User enterspassphrase • Passphrase hashed with a cryptographic hash functionto produce a key • File encrypted with the key • E.g. EAS in CBC mode • Decryptionwiththe samekey • Examples: crypt(1), GPG 1 SHA-1 2 d70f3619a209b15 Our plan is.… 3 % gpg --output ciphertext.gpg --symmetric plaintext.docEnter passphrase:

6. Limitations of file encryption • Encrypting a file normally creates an encrypted copy; what happens to the old plaintext file? • No guarantee that the plaintext is not left on the disk • Word processors and other software create temporary files and backup copies • Unencrypted versions and fragments of the file may be left in locations that the user does not even know about • There are tools for deleting temporary files and for wiping free disk space, but none is completely reliable

7. Wiping files • Deleting a file simply marks the space free but does not erase the contents • Raw data is still on the disk and can be read • Overwriting a file may erase the old contents but there is no guarantee • File system may organize data in unexpected ways: backups, revision control, copy on write, journal, etc. • Wiping all empty disk space by overwriting • Deletes a lot of data but also no guarantee • Disk drive behavior is not always controllable by the file system driver: bad blocks, optimizations • Solid state disks (SSD) write in complex patterns • Magnetic data remanence: magnetic medium may retain traces of previous contents even after overwritten

8. Encrypting file system

9. Windows encrypting file system (EFS) • Encryption is a file attribute • Possible to enable encryption for all files in a folder  new files encrypted • Files are readable only when the user is logged in • Encryption and decryption are transparent to applications • Similar products exist for Unix butnone in wideuse 

10. EFS key management *) DPAPI = Data Protectionapplicationprogramminginterface 1 • User logs in, enters password • Hashed to produce key • Used to decrypt User’s Master Key • Used to decrypt User’s Private EFS Key • Used to decrypt File Encryption Key (FEK) • Used to encrypt on write and decrypt on read key 2 PBKDF2 User’s DPAPI*Master Key 3 Profile User’s PrivateEFS Key 4 Profile RSA FEK $EFS alternate data stream 5 Plaintextfile 6 d70f3619a209b15 Our plan is.… EncryptedFile AES or 3DES

11. EFS limitations • Encrypts contents of specific files • User password or smartcard needed for decryption • System has no access to encrypted files unless user logs in • Cannot index files offline without the password • Backups contain encrypted files, not the plaintext • When encrypting plaintext files, the original file is not wiped, just deleted; the data remains on the disk • User must remember to create the file in an encrypted folder • Transparent decryption • e.g. data decrypted transparently when copying to a file share over network or to an un-encrypted FAT partition • Some data is not encrypted: • folder and file names • temp files, earlier unencrypted versions, printer spool • registry, system files and logs • page file can now be encrypted but requires policy configuration • Hibernation filemay contain decryption keys

12. Trojans, root kits etc. • EFS data is vulnerable to Trojans, viruses and key loggers • Attacker with access to hardware can compromise OS and install a root kit or key logger • Note that these are different problems than laptop theft and loss • Stolen laptops are usually not returned to owner after they are compromised

13. Full disk encryption

14. Full disk encryption • Entire disk encrypted: • Protects all information on disk • Easier to use correctly than EFS • Products are available from various hardware and software vendors including hard disk manufacturers • Password, key or physical token required to boot or to mount disk;thereafter transparent • Usability and reliability issues? • No unsupervised reboot or wakeup • In software-based products: • Password must be strong enough to resist brute-force guessing • Hibernation is problem  need a hardware solution

15. Trusted platform module • Trusted hardware enables some things that otherwise would be impossible • Trusted platform module (TPM) is a smart-like module on the computer motherboard • Holds crypto keys and platform measurements in platform configuration registers (PCR) • Useful TPM operations: • TMP_Seal: encrypt data — in any platform configuration • TPM_Unseal: decrypt the data, but only if the platform configuration is the same as when sealing

16. Windows BitLocker • Full-volume encryption in Windows • Uses TPM for key management • Optional PIN input and/or USB dongle at boot time • System volume must be NTFS, data disks can also be FAT • Sealing the entire system partition: • Encrypt data with a symmetric key • Seal the key; store sealed key on disk; unseal when booting • TPM will check the OS integrity before unsealing the key • Can boot to another OS but then cannot unseal the Windows partition  cannot bypass OS access controls • For a stolen laptop, forces the thief to hardware attack against TPM

17. BitLocker partitions Windows partition contains: Volume metadata with MAC Encrypted OS Encrypted page file Encrypted temp files Encrypted data Encrypted hibernation file 1.5 GB EncryptedWindows partition Boot partition Boot partition contains: MBROS loaderBoot utilities

18. Bitlocker keys Storage Root Key (SRK) inside TPM 1 Volume Master Key (VMK) 2 Encrypted keys in volume metadata Full Volume Encryption Key (FVEK) 3 Plaintext data 4 and bring milk … Separate VMK/FVEK adds flexibility — how?

19. Algorithms and key sizes • Storage root key (SRK) is a 2048-bit RSA key • Volume master key (VMK) is a 256-bit symmetric key • Full volume encrypt key (FVEK) is a 128- or 256-bit symmetric key • The disk in encrypted with AES-CBC • Initialization vector (IV) derived from sector number • No integrity check • MAC would cause data length to expand • Disk sectors are pre-processed with a proprietary diffuser algorithm • Makes attacks against integrity more difficult; the whole sector is encrypted as if one cipher block (512..8192 bytes)

20. Secure boot with TPM Pre-OS Static OS Dynamic OS CRTM measure and load load volume metadata,unseal VMK, verify MAC1 on metadata, decrypt FVEK BIOS MBR NTFS boot sector decrypt,verify signatureand load NTFS boot block Boot manager OS loader2 PCRson TPM Windows 1MAC keyed with VMK. 2Different loaders for boot, resume etc.

21. Which PCR values are used? *PCR 00: CRTM, BIOS and Platform Extensions (PCR 01: Platform and Motherboard Configuration and Data) *PCR 02: Option ROM Code (PCR 03: Option ROM Configuration and Data) *PCR 04: Master Boot Record (MBR) Code (PCR 05: Master Boot Record (MBR) Partition Table) (PCR 06: State Transitions and Wake Events) (PCR 07: Computer-Manufacturer Specific) *PCR 08: NTFS Boot Sector *PCR 09: NTFS Boot Block *PCR 10: Boot Manager *PCR 11: BitLocker Critical Components • If any of the*-values has changed, the decryption key will not be unlocked and a recovery password is needed • BitLocker keys will be unlocked during OS upgrade

22. BitLocker modes • TPM only: • Unsupervised boot (VMK unsealed if the PCR values correct) • Attacker can boot stolen laptop but not log in  security depends on OS access controls • Very attractive mode of operation enabled by TPM — but see the following slides! • TPM and PIN: • TPM requires a PIN during the secure boot • TMP will be locked after a small number of incorrect PINs • Attacker must break the TPM hardware to decrypt disk • TPM (and PIN) and USB stick: • Secure boot and strong keys on a physical token  high security • USB stick without TPM • Traditional software-based full-disk encryption; no secure boot

23. Cold boot attack • Laptop memory is designed for low power consumption  slow refresh rate  data stays in memory for seconds after power loss • Data remanence in DRAM: • Pull out memory from a running computer and plug it into a reader • Some bits will be random but some will retain their values  might be possible to recover most bits of a cryptographic key in the memory • Use cold spray or liquid nitrogen to reduce data loss • Cold boot attack: • Reboot into minimal hacker OS from USB stick or CD • Memory power lost only for a fraction of a second during reboot  memory contents almost unchanged • Lessons: • Breaks full-disk encryption if attacker has access to the running computer • Sleeping laptop = running laptop  most laptops vulnerable • Breaks BitLocker in TPM-only mode even if it is powered down • OS access controls, e.g. screen lock, do not stop a physical attacker

24. Data Revocery

25. Data recovery • If the decryption key is lost, encrypted files will be lost • EFS risks: password reset tools may change password without re-encrypting the user private key; profile cleaning tools could delete the private keys • BitLocker risks: installing Linux boot loader, replacing the motherboard, TPM boot PIN forgotten or mistyped many times, moving disk to another computer  good idea to backup keys

26. Data recovery in EFS • Administrator or Group Policy can define a data recovery agent (DRA) • FEK encrypted also with DRA public key • In a Windows domain, Domain Admin is the default DRA • Standalone machine has no default DRA • Backup user private key by exporting the user’s EFS certificate (including the private key) • Local Admin can configure a DRA on the local machine (see cipher.exe) • Questions: • In Win 2000, local Admin was the default DRA; why was this not a good idea? • Local Admin cannot read other users’ encrypted files because the user password is needed to decrypt them; how can the Admin get around this?

27. Data recovery in EFS • File encryption key (FEK) is encrypted with one or more recovery agents’ public keys • The same mechanism is used for sharing encrypted files between users User’s PrivateEFS Key Recovery Agent’s Private EFS Key FEK Fileattribute FEK Plaintextfile d70f3619a209b15 Plaintextfile Our plan is.… EncryptedFile Our plan is.… 38

28. Data recovery in BitLocker • Recovery password: • User can print a 48-digit recovery password or store it on a USB stick, CD or remote disk; it is actually a 128-bit key • BitLocker encrypts the VMK with the recovery password and stores it with the volume metadata (in the same way as the TMP-sealed VMK) • Multiple backups of volume metadata are stored in the volume • Organizational recovery policy: • Windows Domain Admin can require the recovery password or keys to be uploaded to the Active Directory • Installing another OS for dual boot will trigger recovery • User can accept the new boot configuration after entering the recovery password

29. Exercises • What secure methods are there for erasing • magnetic hard drives and tapes • USB stick or solid-state drives • paper documents • How to delete a specific file from a computer without erasing the whole disk? • What security properties does GPG file encryption EFS provide that full-disk encryption does not? • Why do EFS and BitLocker have so many levels of keys? Are some unnecessary? • Compare the security of software-based full-disk encryption and the TPM approach against brute-force password guessing • How to mitigate the risk of cold-boot attacks (both against BitLocker and more generally)? • Transparent operation improves usability of data encryption, but are there risks associated with the transparency?

30. Related reading • Online: • Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys.http://citp.princeton.edu/memory/ • Stallings and Brown: Computer security, principles and practice, 2008, chapter 10.5