Tuomas Aura T-110.4206 Information security technology

Encrypting stored data

Aalto University, autumn 2013

Outline

1. Scenarios

2. File encryption

3. Encrypting file system

4. Full disk encryption

5. Data recovery

[Acknowledgement: These slides are partly based on Microsoft material.]

2

Simple application of cryptography — but a good example of how difficult it is to build secure system

Simple application of cryptography — but a good example of how difficult it is to build secure system

Scenarios for data encryption

Lost and stolen laptops

– Contain confidential data and access credentials

Physically compromised servers

– Contain business secrets, customer data and PII

– Unauthorized insiders have physical access

Decommissioned hard disks

– Secure decommissioning is expensive

– Hardware recycling is typically done in the cheapest and fastest way: no time for secure disk wipe

– Old PCs from the US are shipped to China for recycling

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 recovery is needed

– System design mistakes or programming errors could compromise data

4

FILE ENCRYPTION

Simple file encryption 1. User enters

passphrase 2. Passphrase hashed

with a cryptographic hash function to produce a key

3. File encrypted with the key – E.g. AES in CBC mode – Decryption with

the same key – Examples:

crypt(1), GPG

6

1 *****

**

2

SHA-1

d70f3619a209b

d70f3619a209b

Our plan is.…

Our plan is.… 3

% gpg --output ciphertext.gpg --symmetric plaintext.doc Enter passphrase:

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

Cloud storage keep all old data

Wiping files Deleting a file simply marks the space free but does not

erase the contents: raw data is still on the disk Overwriting a file does not always erase the old contents:

– File system may organize data in unexpected ways: backups, revision control, copy on write, journal, etc.

– Solid state disks (SSD) write in complex patterns

Wiping all empty disk space by overwriting – Deletes most data but no guarantee – Disk drive behavior is not always controllable by the file system

driver: bad block replacement, optimizations

Magnetic data remanence: magnetic medium may retain traces of previous contents even after overwritten

Physical destruction: grinding disks, heating magnetic medium above Curie temperature – Flash memory (SSD) fragments may retain data

8

ENCRYPTING FILE SYSTEM

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

10

EFS key management

1. User logs in, enters password

2. Hashed to produce key

3. Used to decrypt User’s Master Key

4. Used to decrypt User’s Private EFS Key

5. Used to decrypt File Encryption Key (FEK)

6. Used to encrypt on write and decrypt on read

1

2

PBKDF2

d70f3619a209b15

d70f3619a209b15

Our plan is.…

Our plan is.…

6

User

name:

Windows

Password:

Log on to:

Username

*********

Domain

OK Cancel Shut Down... Options <<

3

4

key

User’s DPAPI* Master Key

User’s Private EFS Key

5 FEK

User profile

User profile

$EFS alternate

data stream

Encrypted File

11

Plaintext file

RSA

AES or 3DES

*) DPAPI = Data Protection application programming interface

EFS limitations Encrypts contents of specific files only User login credentials (password) needed for decryption

– System has no access to encrypted files unless user logs in – System cannot index files without the user 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 should create files 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 file may contain decryption keys

12

EFS and password cracking EFS security depends on the secrecy of user password

Password hashes are stored in a database on the disk

Password are vulnerable to brute-force attacks – NT hash and historical LM hash use no salt and are

therefore especially vulnerable

– Rainbow tables (Hellman90, Oechslin03)

Attacker can boot to another OS, extract the password hashes from the hard disk and crack the user password

Notes: resetting user or admin password does not enable access to encrypted files

EFS supports smart cards as alternative login method

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 problems do not apply to lost or stolen laptops

EFS summary Encrypts single files and folders; leaves a lot of

information unencrypted Requires care from user

– User must understand what is encrypted and what else happens to the data

– User of a non-domain computer must backup keys or risk data loss

– Security depends on a strong password

System cannot access encrypted files for admin tasks like backup and indexing

Hibernation breaks the security Apart from the hibernation issue, EFS would be pretty

secure way of encrypting all files on a data disk (D:) 15

FULL DISK ENCRYPTION

16

Full disk encryption Entire disk is 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? – Requires user/admin to be present at boot time

In software-based products: – Password must be strong enough to resist brute-force guessing – Hibernation is a problem

Hardware solution would be better

17

Trusted platform module

Trusted hardware enables some things that otherwise would be impossible

Trusted platform module (TPM) is a smart-card-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

Windows BitLocker

19

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

BitLocker partitions

Encrypted Windows partition

Boot partition

Windows partition contains:

Volume metadata with MAC

Encrypted OS

Encrypted page file

Encrypted temp files

Encrypted data

Encrypted hibernation file

Boot partition contains: MBR OS loader Boot utilities

1.5 GB

BitLocker keys

Storage Root Key (SRK) inside TPM 1

4

2 Volume Master Key (VMK)

3 Full Volume Encryption Key (FVEK)

Plaintext data

and bring

milk …

and bring

milk …

Separate VMK/FVEK adds flexibility — how?

Encrypted keys in

volume metadata

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 – Adding a MAC would increase the data size

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)

Software authentication with TPM Measuring platform configuration:

– Module n computes hash of module n+1 and extends the hash into a platform configuration register (PCR) in TPM

– Module n transfers control to module n+1

At any point, PCRs contain a cumulative fingerprint (hashes) of all software loaded up to that point

Sealing and unsealing data: – TPM binds selected PCR values to the sealed secrets – TPM unseals secrets only if these PCR values have not changed – If attacker tampers with the OS or the boot process, the OS

cannot unseal the data

Originally designed as a DRM feature: – Decrypt music only for untampered OS and media player – Slightly different from tranditional secure boot: does not prevent

booting to any OS or system configuration

23

Secure boot with TPM

CRTM CRTM

Boot manager Boot manager

NTFS boot block NTFS boot block

NTFS boot sector NTFS boot sector

MBR MBR

BIOS BIOS

measure and load

Static OS Dynamic OS Pre-OS

PCRs on TPM

decrypt, verify signature and load

load volume metadata,

unseal VMK, verify MAC1

on metadata, decrypt FVEK

1MAC keyed with VMK. 2Different loaders for boot, resume etc.

Windows Windows

OS loader2 OS loader2

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 before OS upgrade

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 the disk – Attacker may also sniff communication between chips on a live system

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

Network unlock – Server can reboot if on the same network with AD

26

Secure path issues The PIN input is not secure if the attacker can

hack the hardware – Attacker can modify the BIOS or by replace the

computer without the user’s knowledge – Key logger on external keyboard can capture the PIN

Similarly, a hacked computer can capture the keys on the USB stick

This requires the attacker to have access to the computer twice: first to install the Trojan, then to use the captured PIN – Inside attacker, e.g. IT support – Not a problem for lost and stolen computers

27

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

28

DATA REVOCERY

Need for data recovery If the decryption key is lost, encrypted files will be lost

If Admin resets user password, EFS files cannot be read – Password reset and hacking tools have the same effect

– User can change the password back to the old one – if remembered

Backup files become unreadable if the user’s old (archived) private key’s is lost – Can happen when rebuilding or cleaning user profile

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 decryption keys

Data recovery in EFS Windows domain has a data recovery agent (DRA)

– FEK is encrypted also with DRA public key – Domain Admin is the default DRA – Other DRAs can be defined in a Group Policy

Standalone machine has no default DRA – Latest password reset disk also recovers EFS private key – User may also export the user’s EFS certificate (including

the private key) to a backup disk – Local Admin can configure a DRA on the local machine (see

cipher.exe)

Questions: – Win 2000 had Local Admin as default DRA fro non-domain

machines; why was this not a good idea? – Local Admin cannot read the users’ encrypted files without

the user passwords; can the Admin get around this? 31

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

d70f3619a209b15

d70f3619a209b15

File attribute

Our plan is.…

Our plan is.…

User’s Private EFS Key

FEK

32

Encrypted File

Our plan is.…

Our plan is.…

FEK

Recovery Agent’s Private EFS Key

Plaintext file

Plaintext file

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 in case a part of the volume is corrupted

Organizational recovery policy: – Windows Domain Admin can require the recovery password 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

Exercises What secure methods are there for erasing magnetic hard drives and

tapes, USB stick or solid-state drives (SSD), and paper documents? How to delete a specific file from a computer securely without erasing the

whole disk? What security properties does GPG file encryption or EFS provide that full-

disk encryption does not? How vulnerable is EFS to password guessing? 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)? Explain what effect do powering down the laptop computer, hibernation

and sleep mode have on the cold boot attack? Transparent operation (happens without the user or application even

knowing) improves usability of data encryption, but are there risks associated with the transparency?

How would you design the encryption of files in cloud strorage?

34

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

35