BitLocker ========= reminder: final project proposals due this week (and start hacking!) what's the problem this paper is trying to solve? preventing data from being stolen as a result of laptop theft disk encryption what general problems might you worry about with disk encryption? data secrecy data integrity deniability, of various sorts don't want someone to know if you have specific data stored on disk don't want someone to know if you've given them your real password e.g. border patrol compels you to decrypt your disk where does the key come from? simple designs user enters a password (hashed to key) for BIOS at boot user plugs in a USB drive containing a key, which BIOS uses bitlocker in TPM mode key sealed for PCRs corresponding to Windows advantage: no need for user interacting with the BIOS what's the point of the TPM-only mode? attacker cannot run a different OS, forced to run windows relies on whatever protection windows provides maybe sensitive data not directly accessible to user (file ACLs?) maybe user has a windows login password; can rate-limit login attempts (because of TPM, no need for user to enter pw twice, once for BIOS) what gets measured at boot in bitlocker? two partitions: one containing bitlocker bootstrap, one encrypted first partition measured at boot second partition decrypted, but not measured why not measure? expectation: attacker won't be able to meaningfully change it what happens on upgrade? need to re-seal key bitlocker bootstrap partition changes infrequently key stored encrypted with a recovery password ("escrow" scheme) supposing we have the key, how do we protect the on-disk data? encrypt disk blocks one-at-a-time why one-at-a-time? atomicity, performance are we done? well, data is secret, but attacker may try to modify data potential problem: attacker changes system to be vulnerable can we just check signatures on binaries, ala secure boot? probably not: config files, other data hard to account for so, need to protect integrity how do we ensure integrity? we don't, at least not strictly strong integrity would require storing a MAC somewhere on disk because of sector independence, need a MAC per sector store MAC next to sector: space-doubling store MAC elsewhere: two seeks store MACs for a bunch of sectors nearby: breaks atomicity so what's the plan? assume attacker can't construct a useful ciphertext stream ciphers ARC4: source of pseudo-random bits XOR the stream cipher with the data to get ciphertext XOR the stream cipher with ciphertext to get the data why not use a stream cipher for bitlocker? block ciphers block-at-a-time transformation; hopefully no direct bit dependences typically small block sizes (AES: 128-bit block) how do you encrypt something larger than the block size? block cipher "mode of operation" ECB: apply block cipher to each block-sized chunk in turn advantage: simple disadvantage: attacker can permute blocks, find equal blocks, .. CBC: XOR each block's plaintext with previous block's ciphertext can reverse in a straightforward manner advantages: attacker cannot permute blocks, diff ciphertexts for same plaintext at diff offsets disadvantages: encryption is not parallel (decryption is, though) what if plaintext changed by 1 bit? all subsequent C's affected what if ciphertext changed by 1 bit? only two plaintexts affected what's the initial XOR value? called initialization vector (IV) what do we need from the IV? decryption needs access to IV to decrypt what if IV is revealed after encryption? usually OK what if IV is predictable or reused? bad idea leaks data about first block watermarking attacks for FS with FS encryption, IVs often reused, so must be secret PCBC: try to XOR both plaintext and ciphertext from previous block bad idea: attacker can freely exchange adjacent blocks CTR: encrypt a counter (perhaps with a nonce, like an IV) similar to a stream cipher: no bit diffusion reusing IV is disastrous: 802.11's WEP was broken this way various other modes are available notably: OCB/CCM provides efficient authenticated encryption why do we need a new block cipher mode? block ciphers don't offer authenticated encryption without extra space "poor-man's authentication": rely on decryption being random after tampering hopefully attacker won't be able to make useful plaintext appear motivation: nice example in the paper a byte controls whether some feature is enabled attacker can try different ciphertexts, wait for plaintext to match "0" rely on bit-diffusion to make this difficult for attacker: 512-byte sect weakness: no freshness, but OK for the stolen-laptop problem when would poor-man's authentication not work so well? predictable on-disk locations (often the case with stock installs) applications that ignore errors in important data and change behavior e.g. if security config file doesn't parse, ignore it only a few bits of important data in a sector: attacker can try randomly hopefully this isn't how the windows registry is laid out bitlocker's AES-CBC + Elephant mode figure 1 start with basic AES-CBC: closest to what we want why is the IV derived from the sector number? make encryption functions of each sector different, prevent switching why is the sector number encrypted in the IV? make sure the IV is not predictable, avoid watermarking attacks what are the diffusers doing? XORing bits of the block ensures that one bit change on either side will flip many other bits why do we have another sector-dependent transform upfront (sector key)? so that diffusers don't operate on predictable data on either side? sector key: why is it different from the AES key? guarantees that sector-key operations cannot weaken AES even if the entire secret key is leaked, AES still fine potential attacks on bitlocker? not intended to be a perfect security solution (design decision) DMA, cold boot attacks security vulnerabilities in windows (buffer overflows, root access) what are the advantages of bitlocker (disk-level encryption) vs. fs encryption? fs can solve atomicity/consistency problems fs can find space for extra MACs, random IVs to prevent IV reuse, etc fs might require much more code to be "measured" into the TPM fs comes up much later in the boot process requires TPM re-sealing for FS upgrades, driver upgrades, etc fs might not interpose on swapping/paging fs makes it more difficult to deploy bitlocker on existing disk how might you design deniable encrypted storage? can't guarantee space allocation or reservation (otherwise can notice diff) somewhat different storage API: blocks can be "missing" or "unused" flash drives actually moving in this direction too, so not too unusual all blocks must be not only encrypted, but also relocated (no fixed offsets)