
Encrypting stored data Tuomas Aura CS-C3130 Information security Aalto University, autumn 2019 Outline 1. Scenarios for data encryption Simple application of cryptography — and a good example of how 2. File encryption difficult it is to build a secure 3. Encrypting file system EFS system 4. Full disk encryption: BitLocker 5. Data recovery Acknowledgement: These slides are partly based on Microsoft material This lecture uses Windows as a case study. 2 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 However: Security often conflicts with usability, reliability and deployability. System design and implementation may have weaknesses 3 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 (were?) shipped to Asia and Africa for recycling 4 FILE ENCRYPTION Simple file encryption 1. User enters 1 passphrase ***** ** 2. Passphrase hashed to produce a key SHA-256 or PBKDF2 2 3. File encrypted with the key – E.g. AES in CBC mode – Integrity check with HMAC or AES-GCM d70f3 Our 619a plan 209b 3 is.… ▪ Examples: crypt(1), gpg, openssl % gpg --output ciphertext.gpg --symmetric plaintext.doc Enter passphrase: 6 Limitations of file encryption ▪ User action needed, and users are lazy ▪ Passphrase can be brute-forced ▪ After encryption, what happens to the old plaintext file? ▪ Software creates temporary files and backup copies – Unencrypted file versions and data fragments may be left on disk ▪ Automation (scripting) is difficult. How to store passphrase? ▪ Incompatibility with advanced services: – Search and indexing – Cloud storage and synchronization Wiping files ▪ Deleting a file marks the space free but does not erase data ▪ Overwriting a file does not always erase the old contents – Unpredictable file system behavior: backups, version history, RAID, copy on write, journal, bad blocks etc. – Solid-state disks (SSD) avoid rewriting the same blocks 8 Wiping files ▪ Overwriting all / free disk space – Must write pseudorandom data, not just zeros or ones – Should read and verify after write Windows: – Erases most data, but no 100% guarantee cipher.exe /W D:\ – Magnetic data remanence still possible ▪ Physical destruction – Heating magnetic medium above its Curie temperature – Grinding disks to powder (SSD fragments may retain data) 9 ENCRYPTING FILE SYSTEM Windows encrypting file system (EFS) ▪ Encryption is a file attribute in NTFS ▪ Enable encryption for a folder → new files encrypted from start ▪ Files can be read when the user is logged in ▪ Encryption and decryption are transparent to applications 11 *) DPAPI = Data Protection API Windows User Username name: EFS key hierarchy 1 Password: ********* Log on to: Domain OK Cancel Shut Down... Options << 1. User logs in with password PBKDF2 2. Hashed to produce key key 2 3. Used to decrypt User’s Master Key 3 User’s DPAPI* Master Key User profile 4. Used to decrypt User’s Private EFS Key 4 User’s Private EFS Key User profile 5. Used to decrypt RSA File Encryption Key $EFS alternate 5 FEK (FEK) data stream Plaintext 6. Used to encrypt 6 file d70f3 Encrypted Our on write and 619a2 File plan 09b15 decrypt on read is.… AES or 3DES 12 EFS ANALYSIS EFS limitations: partial protection ▪ Encrypts contents of specific files and folders ▪ Some data is not encrypted: – Folder and file names – Temp folder, earlier unencrypted file versions, printer spool – Registry, system files and logs – Page file can be encrypted but requires policy configuration ▪ When encrypting plaintext files, the original file is not wiped: always create files in an encrypted folder ▪ Hibernation file may store decryption keys: disable hibernation 14 EFS limitations: attacks ▪ Password cracking is a danger ▪ Key logger or hidden camera can capture user password ▪ Malware can steal EFS data when the user is logged in ▪ Attacker with access to hardware can compromise the OS and install a root kit or key logger, or configure a malicious data recovery agent (DRA) Note that these problems do not apply to lost or stolen laptops EFS limitations: usability ▪ Requires care from user – User must understand what data is encrypted and when – User of a non-domain computer must backup keys or risk data loss – Security depends on a strong password ▪ User login credentials (password) needed for decryption – System cannot index files when user logs out – Backups contain encrypted files (do keep your old EFS recovery keys!) ▪ Transparent decryption can cause surprises – Data decrypted when moved or copied to FAT or transferred over network 16 EFS and password cracking ▪ EFS security depends on the secrecy of the user password ▪ Password hashes are stored in a database on the disk ▪ Password are vulnerable to brute-force attacks – NT hash and older LM hash use no salt and are especially vulnerable (Rainbow tables ,Hellman1980, Oechslin03) ▪ Attacker can boot to another OS, extract the password hashes from the hard disk and crack the user password – User or admin password reset does not give access to encrypted files (why?) ▪ EFS supports smart cards as a login method ▪ Q: Do EFS and Windows Hello work together? FULL DISK ENCRYPTION: BITLOCKER 18 Full disk encryption ▪ Entire disk is encrypted: protects all information on disk – Easier to use correctly than EFS ▪ 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 cracking 19 Trusted platform module ▪ Trusted platform module (TPM) is a smart-card-like tamperproof module on the motherboard or integrated in the CPU ▪ Stores cryptographic keys – Protects keys against both software and hardware attacks – Key cannot be stolen, but can it be misused? ▪ Accumulates platform measurements in platform configuration registers (PCR) – Used to check software integrity during the boot process Sealing data with TPM ▪ TPM operations: – TMP_Seal: encrypt data in any platform configuration – TPM_Unseal: decrypt the data, but only if the platform configuration has not changed ▪ When unsealing, the TPM compares current PCR values to ones saved when sealing – TPM refuses to reveal the decryption key if the PCR values are different 21 Software authentication with TPM ▪ Measuring platform configuration: – Each software module computes hash of the next module and extends the hash into a platform configuration register (PCR) in TPM – Then transfers control to the next module ▪ PCRs contain a cumulative fingerprint (hashes) of all software loaded during the boot process ▪ Originally designed as a DRM feature: – Decrypt music only for untampered OS and media player – Another use for TPM and platform measurements is attestation i.e. proving host integrity to another host across the Internet 22 Windows BitLocker ▪ Full-volume encryption in Windows ▪ Principle: Seal the symmetric encryption key with TPM; store the sealed key on the disk; unseal the key when booting ▪ TPM detects tampering of system software – TPM checks the PCR values before unsealing – Trusted boot: can boot to Linux, but Linux cannot unseal the Windows partition ▪ Design goal: laptop thief has to attack the TPM hardware 23 BitLocker partitions Windows partition contains: Volume metadata with MAC Encrypted OS Encrypted page file Encrypted temp files Encrypted data Encrypted hibernation file Encrypted 1.5 GB Windows Boot partition partition Boot partition contains: MBR OS loader Boot utilities BitLocker key hierarchy 1 Storage Root Key (SRK) inside TPM 2 Volume Master Key (VMK) Encrypted keys in volume metadata 3 Full Volume Encryption Key (FVEK) d70f3 Encrypted data 4 and 619a2 bring Plaintext data 09b15 milk … Individual disk blocks are encrypted on write and Separate VMK/FVEK adds flexibility — how? decrypted on read. Extra Algorithms and key sizes material ▪ 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 ▪ Disk sectors encrypted with AES in CBC or XTS mode – Initialization vector (IV) derived from sector number (no space for storing a random IV in each disk block) ▪ No integrity check on data – Adding a MAC would increase the data size Measured boot with TPM PCRs on TPM OS loader OS S-CRTF UEFI e.g. Windows Boot (Windows) Manager Master Boot Volume Boot CRTM BIOS Record (MRB) Record e.g. NTFS OS loader OS Boot Sector ▪ Each component in the boot process measures i.e. computes hash of the next component Extra Which PCR values are used for sealing? material *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
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages51 Page
-
File Size-