Encrypting stored data
Tuomas Aura
CSE-C3400 Information security
Aalto University, autumn 2014
Outline
1.
2.
3.
4.
5.
Scenarios
File encryption
Encrypting file system
Full disk encryption
Data recovery
Simple application of
cryptography
— and a good example
of how difficult it is to
build secure system
This lecture is uses
Windows as an
example. The same
principles and
questions apply to
competing file and
disk encryption
products
Acknowledgement:
These slides are partly based on Microsoft material.
2
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.
2.
3.
User enters
passphrase
Passphrase hashed
with a cryptographic
hash function
to produce a key
File encrypted
with the key
–
–
–
E.g. AES in CBC mode
Decryption with
the same key
Examples:
crypt(1), GPG
1
*****
**
SHA-1
2
d70f3
619a
209b
3
Our
plan
is.…
% gpg --output ciphertext.gpg --symmetric plaintext.doc
Enter passphrase:
6
Limitations of file encryption
 User action needed, and users are lazy
 Automated use (scripting) hard to implement because
where do you store the secret passphrase?
 Brute-forcing the passphase possible
– Can be mitigate with a slow hash (e.g. PBKDF2)
 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.
2.
3.
4.
5.
6.
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
1
*) DPAPI = Data Protection
application programming
interface
Windows
User
name:
Password:
Username
*********
Log on to:
Domain
OK
Cancel
Shut Down...
Options <<
PBKDF2
2 key
User’s DPAPI*
3 Master Key
User profile
User’s Private
4 EFS Key
User profile
RSA
$EFS
alternate
data stream
5 FEK
6
Encrypted
File
d70f3
619a2
09b15
AES or 3DES
Plaintext
file
Our
plan
is.…
11
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
– Note: resetting user or admin password does not enable
access to encrypted files
 EFS supports smart cards as an 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 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-cardlike module on the computer motherboard or,
preferably, embedded in the CPU
– 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
 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
19
BitLocker partitions
Windows partition contains:
Volume metadata with MAC
Encrypted OS
Encrypted page file
Encrypted temp files
Encrypted data
Encrypted hibernation file
Encrypted
Windows
partition
1.5 GB
Boot partition
Boot partition contains:
MBR
OS loader
Boot utilities
BitLocker keys
1
Storage Root Key (SRK) inside TPM
2 Volume Master Key (VMK)
Encrypted
keys in
volume
metadata
Encrypted
data
d70f3
619a2
09b15
Separate VMK/FVEK adds flexibility — how?
Full Volume
3 Encryption Key (FVEK)
4
and
bring
milk …
Plaintext
data
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 (because
there is no space for storing a random IV in the disk block)
 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 it was 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 traditional secure boot: does not prevent booting
to any OS or system configuration
– Another feature based on the TPM and platform measurements is
attestation i.e. proving host integrity to another host server across the
Internet
23
Secure boot with TPM
Pre-OS
Static OS
measure
and load
CRTM
Dynamic OS
load volume
metadata,
unseal VMK,
verify MAC1
on metadata,
decrypt FVEK
BIOS
MBR
NTFS boot sector
NTFS boot block
Boot manager
decrypt,
verify signature
and load
OS loader2
PCRs
on TPM
Windows
1MAC
keyed with VMK. 2Different loaders for boot, resume etc.
Which PCR values are used for sealing?
*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
eDrive
Obtain the Authentication Key
1 e.g. by unsealing it
2
Encrypted
key on the
drive
Encrypted
data
Authentication Key:
sent to the drive, decrypts the
Data Encryption Key
3
Data Encryption Key (DEK)
never leaves the drive
4
d70f3
619a2
09b15
and
bring
milk …
Separate VMK/FVEK adds flexibility — how?
Plaintext
data
Offloading the
data encryption
and decryption
(AES) to
hardware on
the drive
(in Windows 8 and
Server 2012)
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
 Malware can also fake the reboot process and ask for
the PIN
 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
28
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 remain 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
from gaining access to memory and files
29
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 in the domain
 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:
– Local Admin cannot read the users’ encrypted files without
the user passwords; can the Admin get around this?
– Win 2000 had local Admin as default DRA for non-domain
machines; why was this not a good idea?
32
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
Recovery Agent’s
Private EFS Key
FEK
Plaintext
file
Our
plan
is.…
User’s Private
EFS Key
FEK
File
attribute
Encrypted
File
d70f3
619a2
09b15
Plaintext
file
Our
plan
is.…
33
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
– User can save the recovery key to Microsoft account (online)
 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 fulldisk 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?
35
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
36