Toward Standardization of

Self-Encrypting Storage

Security in Storage Workshop Baltimore, September 25, 2008

Laszlo Hars

[email protected]

Introduction

• • • • Need for secure storage ∞ Horror stories of lost data, security breaches – Legislation: HIPAA, HR-516,-816,-1685… – Disk drives: 2 nd largest market, annual volumes 1.5…2 billion What can we do?

– Physical security vs. Cryptography • Costs, feasibility, availability, complexity… – Encryption: secure, cheap… – Authentication, access control: possible Where to encrypt?

– Separation of Data and Keys (tape  • Key management ($$) – Trust Boundary How to encrypt? ⇒ sealed storage)

Outline

• • • • • • • • • • • • • Scope, Audience and Need for a standard Threat Model, Attack Scenarios Goals, desired Features Alternatives of Self-Encrypting Storage Advantages, possible Features Trust: open source vs. certification, Bugs Interfaces Encryption Data integrity, authentication Key Management User Authentication Access Control FW Update, Diagnostics, Testability

Scope of a Standard

• Specific to self-encrypting storage – ( Block (sector) oriented storage devices  – Random access (address) P1619) • ⇔ Low level functionality covered – Encryption – Authentication (user/data) – – Access control Key generation, store High level in TCG; Key management standards...

– Interfaces, command format/payload – Services (SP’s, stash storage…) – – Authorization/rights management… Timer, logging, administration of other services…

Concerned Parties

• • • Sealed storage manufacturers – Disk drive – Solid state storage Computer manufacturers – They order, design around, build-in – Need equivalent second source – Interact with end users Users Their data to be protected – Datacenteroperators,Healthcareproviders,Banks,Insurance – Privacy groups – Government agencies… – Not for special needs (military, intelligence agencies…)

Need for standards

1. Allow avoiding custom-design security architecture - Provide secure architecture which already met public scrutiny 2. Simpler security analysis for conforming devices 3. Reduce development costs, time to market 4. More trust - nonprofit orgs are trusted more than manufacturers 5. Second source of drives for OEMs - with similar security attributes, functionality 6. Marketing advantages: perceived “good security”

Threat Model, Attack Scenarios 1

• • ✔ Lost laptop / stolen (off-line) drive – Extract information from the drive (spin stand) • 1-2 previous block contents (magnetic saturation level, edge overlap…) – Key search at known plaintext: MBR, Partition table, OS...

– Sending host interface messages • Authentication attempts, password trials • Unauthorized data read/write, control commands Interrupted, tampered protocols (active, on-line) – Learn keys, reusable info (authenticate other partitions..) User attacking secrets in his own drive (on-line) • Data owner could be different: DRM, online games, electronic cash… + Side channel attacks, fault injection…

Threat Model, Attack Scenarios 2

• • • After changing owner – Attacker restores old keys, passwords to access new data – New owner inspects media for remnant data, keys Data center: unsupervised powered up locked drives – The attacker sends host interface messages, like • authentication attempts, password trials (dictionary attacks) – e.g. at a password-hash collision logon in behalf of user

→

new user data written with attacker key • unauthorized data read/write • control commands (password change/reset, diagnostics…) Data center: unsupervised unlocked drives – Read/write user data ( ⇔ Secure communication) – Change/Reset/Access Passwords, PINs and Keys

Threat Model, Attack Scenarios 3

• •

Password conflict: authenticated, no decrypt

– Inject new key to steal newly written data

Spying hardware (on-line)

• Key logger, cable snooper, logic analyzer… • Laptop (in sight) vs. Data center (remote drive) – Inside the host – On the cable: host -¦- controller -¦- drive • Stealing data • Attacking secure authentication protocols – Inside the drive • On wires between components

Threat Model, Attack Scenarios 4

• • • • Malicious software in Host (OS) – – Stealing small amount of data Spying keys (key loggers, clipboard/control snoopers) Side channel leakage in Host – Resource usage monitoring (SW, HW) Side channel leakage in unauthenticated Drive – Radiation, heat, power fluctuation… External influences, fault injection in Drive – Changing magnetic field, EM radiation, supply voltage / internal resistance modulation, extreme temperature…

Threat Model, Attack Scenarios 5

✔

Raw data (media) access

– At most one time – Some blocks: 1-2 previous (latent) contents – Hidden system data – Ciphertext • Traffic analysis • Change the data – bit flip: (almost) randomize plaintext ⇒ » 1 bit info many (>2 64 ) all different plaintext versions at an LBA – arbitrary overwrite (data destruction, key search…) – copy other blocks over – copy back previous content (of the same or other block)

Goals 1

• • • • • • Data confidentiality by encryption Access control to prevent – Ciphertext inspection – Tampering with ciphertext Key/password management – Different authorities to different users – No secret keys/passwords in the OS (BIOS, Pre-boot) Fast secure disk erase (reuse) Can change passwords without re-encrypting stored data Breaking one disk drive (discovering its keys) should not give information on the keys in other drives – Globally unique Root Key in electronics • Physical process variations / one time programmable key

Goals 2

• • No backdoors, manufacturer keys – True random user keys generated in the drive • at users’ request • as often as needed (with internal re-encryption) – Secure key export when authorized • functionality, correctness, entropy… to be verified • for data recovery when electronics fail – Key import when authorized – Recovery of plaintext from (failed) drive must be hard • except with escrowed key – Industry standard crypto algorithms: AES,RSA,ECC,DH – Public, verifiable security architecture Transparent data layout alterations, hidden space

• • •

Goals 3

Can use metadata  – P1619 LBA, Age of data, Drive ID, Track geometry, ErrCC...

Security at known ciphertext w. layout on media – Not enough information on media to decrypt user data (except brute-force key search, breaking cipher) Commercial grade security – Physical attacks must fail before authentication • side channels, etched away chip covers: microscope, probes… – Physical attacks might succeed after authentication • stealing powered up drive: data lost  secure networking • • side-channel attacks on drive in use  focused ion beams, micro probes  secure HW design tamper proofing (+$$) – Ciphertext access only after disassembling the drive • detected by users (tamper detectors, time away…)

Alternatives of Self-Encrypting Storage 1

•

Encryption in the HOST-1 (w. dumb drive)

?

– – – Some protection of data in transit (insufficient) LBA in the clear Ciphertext freely available (see below) Open physical environment • Key loggers • Logic/bus analyzer • Frozen RAM • DMA: FireWire (IEEE 1394), Peripheral buses • PCI(e/x...) bus monitor card • Side channels

Alternatives 2

•

Encryption in the HOST-2

– Open SW environment • Malware • Net vulnerabilities • Debuggers, unprotected memory • DMA (FireWire, Disk commands, Video cards) • SW side channel leakage (resource use, latency...) • Virtual-memory/swap-to-disk, hibernation file • User errors

Alternatives 3

•

Encryption in the application (SW)

– Knows the protection needs, but – Runs in unknown environment • Capabilities, Vulnerabilities of the OS, the HW • Memory cached, swapped to disk, to hibernation file • Deleted sectors erased or marked free • • Indexing services Recent files lists… + Host vulnerabilities

Alternatives 4

•

HW Encryption outside of storage

• Ciphertext available • • LBA in the clear (see below) Need: Long lived keys for storage  – – session keys for transit Storage encryption for transit: Security risk (fixed keys) Network security for storage » Need key management for ephemeral keys: Cost, Complexity » Security risk: Data and key are separated (needs tracking) – In the Host • Crypto coprocessor • Crypto μP extensions (Intel AES, VIA…) • TPM (secure key storage…) – External encryption module (P1619.0) – Encrypting disk controller

Alternatives 5

• Problems when LBA in the clear + Ciphertext available: – High speed, mass encryption device (export / import control) – Traffic analysis (which sectors are accessed?) • Internet cache, File system, Virtual memory, Hibernation file… • Response to seat reservation, database update/query… – Hide data (from virus scanners) by temporarily moving it – CRC integrity manipulation with enough changes in one block – DRM data manipulation (e.g. number of times a video viewed) – Data destruction at bit flip (selective, undetected) – Data modification (malleability) with little collateral damage • Instruction-, address patching: 2 -8 , 2 -16 chance to jump to desired place • Function corruption: critical security functions disabled (if no crash) – Key erase, Input validation, Protocol step/abort… • Changing behavior of malicious programs which test data blocks • Activation versions of documents, with embedded data for selection

Advantages/Possible Features 1 of Self-Encrypting Storage

1. Low cost. Basic features in commercial pricing models 2. High security a) True random encryption keys: no weak user key degrades security b) Keys not stored in drive: no physical attack gets data in lost drives c) Keys do not leave the drive i.

ii.

No need for secure external key storage, key tracking, auditing No accidental key mishandling (e.g. encrypting the key with itself) d) Closed system: no malware infection e) Crypto HW (single chip): no debugger, bus analyzer attacks f) No SW side channel attacks by malicious processes 3. Protection from malicious host software a) Encryption keys generated in drive, never leave the drive in the clear b) User authentication i.

ii.

Done with protected code in drive Passwords not stored, MAC/encrypted-hash w. HW key, iterated iii. After several failed authentication: lockup iv. In host: BIOS, clean ROM- or attested pre-boot code

Advantages 2

4. Fast and secure disk sanitation by erasing keys – With proof of erasure; even on (partially) failed drives!!

– No legible earlier data (from before encryption enabled), always on 5. Authentication key encrypts data-keys in drive – Instant password change (no user data re-encryption), for regular password change, breached password, employee leaving… 6. Automatic protection of a) virtual memory (swap file) b) hibernation file c) boot record, partition table d) file cache, indices, recent files list… 7. User experience a) easy to deploy: always there, always active b) easy to setup: no SW or extra HW to install c) cannot mis-configure: all data encrypted (index, swap, hibernate...) d) automatically satisfy privacy laws, no need for data classification e) easy to use: transparent, no OS/HW changes, no learning curve f) always on, no several hours initialization at enabling SW encrypt

Advantages 3

8. High speed encryption (at interface speed) – 0 host processor load, delay – No frequent key swaps in μP for different bands (memory, speed) 9. Low power consumption: dedicated, optimized HW 10. Transparent: no need for HW or SW changes 11. Initial set up in the factory: operational, secure, a) Internally generated secret keys b) Default passwords, ID's provided on paper 12. Different keys for different partitions a) Users, OS’es, applications are separated (sandboxes) b) Un-mounted partitions safe from – i.

Malware ii. User errors iii. Lunch-time attackers… 13. Support pre-boot environments Cold boot MBR, Swap MBR after authentication, Warm boot

Advantages 4

14. Support for Multi-level Authentication a) BIOS to open LBA band (~partition) b) (Pre-boot) OS: complex authentication i.

Network access ii. Passwords, Biometrics iii. Tokens… 15. Support for third party security services a) Virtual smart cards, dCards b) Hidden, secure (stash) storage for keeping secrets even on authenticated (open) drive i.

housekeeping info, integrity check for sensitive data, SW, drive ID ii. user passwords, accounts, sensitive personal info iii. data for digital rights management, electronic cash, game state… 16. Access control : ciphertext inaccessible – No data mods, traffic analysis, snapshots

Advantages 5

17. Strong authentication: number of failed logins restricted (also iterated MAC: slow password dictionary attacks) 18. Authentication-key management, key hierarchy E.g.: enterprise key, master key, backup key… 19. Host communication can be (additionally) encrypted: protecting information flow in the “cable” (network: IPSec, TLS…) 20. On-line re-encryption : time shifted secure communication a) data is buffered b) encryption keys are negotiated at data access 21. Re-encryption at key change w/o data transfer to host overhead 22. DRM w/o high processor load or “dirty” tricks (rootkits) a) Clean design, Better system stability b) Secure computation in the drive (scripting) c) Secure, hidden storage

Advantages 6

22. Security services a) secure, fast random number generator b) public key encryption, signature for network applications c) key agreement protocols d) symmetric key encryption of bulk data (when allowed) e) secure authentication for third parties f) certificates with secure storage… 23. Storage – tied to specific devices (mating) TV recorder HW, motherboard, controller, music-video players 24. Forensic logging, usage history, error logs 25. Support for automatically closing a partition a) after a certain time b) after certain idle time

Advantages 7

26. Support for disk arrays a) b) c) Unchanged SCSI Protection Info (routing ID) Valid error checking info (checksum, CRC) Internal XOR engine for RAID (on plaintext or ciphertext) 27. Support – for background data services (on plaintext) By the Host or by the drive on opened partitions a) b) c) d) e) De-duplication Compression Indexing RAID rebuild Virus scanning, media fingerprints… 28. Open interface , easy support for all OS’es

Possibilities with External Support

• • • • • Complex authentication – Multi-factor (with network access, biometric data, tokens...) – Pre-boot environments (duplicate OS functions) Communication (Interface/Network) security – Negotiate communication keys (key exchange) – Different exchange keys for multiple hosts talking to same drive – Encrypt command, LBA with session keys, nonces… Different authentication/encryption for different files – Drives don't have file system information  OSD Re-authentication after spin down/up (BIOS, OS) – While the computer powered up …

TRUST: Open-source / Certification

• • • • Open source SW could be verified, but it is not. Recent news: – 33 years old Unix bug (yacc) – – 25 years old BSD flaw (*dir() library) Debian Open SSL bug (wrong signatures) Crypto’08 Rump Hovav Shacham: insecure.iacr.org

– TLS bug: Crypto’08 Rump Hal Finney: Looking over virtual shoulders – Defeating Encrypted and Deniable File Systems: A.Czeskis & al: TrueCrypt v5.1a and the Case of the Tattling OS and Applications – 2 nd worst: the open source Joomla! Content Management System IBM Internet Security Systems: X-Force 2008 Mid-Year Trend Statistics report – Fortify's Open Source Security Study: “most widely-used open source SW exposes users to significant unnecessary risks”.

• 22,826 cross-site scripting and 15,612 SQL injection issues in 11 packs • in two-thirds of the cases no contact or no response HW is very hard to be verified (technology evolution lag) Protecting manufacturer’s IP Alternative: independent, trusted certifications

TRUST: User verification

• • • • Some assurance that data is stored properly encrypted Security risks – Ciphertext available (  – could be controlled) Encryption key leaves the drive • Key tracking hard • Key erasure unverifiable Undetectable security problems remain – Backdoors – Predictable keys – Rare faults Verification, certification is better – By trusted entities – In controlled environments – With full access to source code, HW design

TRUST: HW Bugs, Political Issues

• • • • ⇒ Bugs: hard to find (~Intel FDIV) – Data dependent faults (wrong algorithm, carry delay, load violation, clock/timing conflicts, meta-stability…) Intentionally planted faults – Enough if 1 out of (2 64 ) 2 or more inputs rigged Single wrong output ⇒ broken encryption – Crypto’08 E.Biham, Y.Carmeli, A.Shamir: Bug Attacks User must trust manufacturer / independent verifier Trust issues: – Large companies / newcomers – – – Democratic / oppressive countries Government agencies / nonprofit orgs / businesses User groups / privacy advocates ⇐ political agendas

Interfaces

• • • •

Only 2/4 extra commands to disk standards Payload carries arbitrarily many security commands Defined in TCG specs (host-drive) Could use key management standards

Encryption

• • • • • • ✔ ECB leaks equality of blocks at (1-time) ciphertext access Large change granularity – Small plaintext change → large ciphertext change If ciphertext freely accessible: authenticate by data redundancy – Long block encryption: EME2, XCB, BitLocker… CBC with encrypted LBA as IV (to prevent watermarking) – Link blocks in 1-direction – Ciphertext is one time accessible: No malleability weaknesses, but – – If previous block content known/recovered: leaks some changed bits For speed: Interleaved sub-chains processed in parallel Counter mode, initialized with LBA – If previous block content known/recovered: leaks changed bits Counter mode, started with: block-version counter || LBA MAC-Counter mode: granular (≈ LH 02/2006 in P1619): (  ) M := MAC(LBA,P 2 ,P 3 …); C 1 := AES(P 1 ) ⊕ M C 1 : initial count for Counter mode encryption of other blocks

Data integrity, authentication

• • • • Ciphertext modification (CphTxt access ∈ – Threat model) Attack: Old data restored with its authentication tag

!

Tradeoffs – Speed: number of expected Read/Write ops – Speed of Seek vs. Read/Write – Security: number of blocks MAC-ed together Updateable MAC, one for each block-group – MAC: Sum of XTS ciphertext, GMAC… – Several blocks (group ≥ full track) MAC-ed together – 1 MAC update at write, full group verify at read Merkle tree of n MAC values (≈ full disk) – Several blocks (group ≤ full track) MAC-ed together – Group + its MAC accessed at first read in a track (fast) – Log n MAC updates at write (in system sectors, flash memory) – Small portion of storage capacity used

• • • •

Key Management

Encryption key generated in the drive – Key never leaves the drive in the clear – Secure erase by destroying the key Key export/import in secure blobs – for data-recovery at HW fault, certification, tests  Security risks, export control issues… User authentication key/pwd decrypts encryption key – “One Time Pad”, but with side information – After key erase: no info left on random encryption key – Lock up at multiple wrong authentications • Needing power cycle, Master key… Key hierarchy for – Changing settings, reset locked drive… – Enterprise policy management, backup…

User Authentication

• • • •

Password (Exchange) Key agreement protocol

– DH with PK certificates (slow, needs μP) – Random key / re-hashed key for next logon (  )

Mutual authentication with nonces Can support

– Multifactor authentication • Biometric scanners • Secure tokens – Network support (up-to-date user credentials)…

Access Control

• • • Drive hides (partition) data until authenticated Disassembling the drive shows ciphertext • Expensive, Slow, Difficult (track geometry) • Could reveal 1-2 previous block contents – Spin stand – Replacement controller – Redirecting head signal… Ensuring one time access – Drive is destroyed, damaged when opened – User notices if drive is offline (time away) – Broken seals, tamper evidence – Electronic tamper detectors, secure enclosures ($$)

FW Updates, Diagnostics, Testability

• FW update – Digitally signed code – Verified by unchangeable ROM code • Need to diagnose faults, verify functionality – JTAG, Debug ports…  Security risks • Permanently disable ports after manufacturing – Cannot diagnose failed drives • Authenticated diagnoses – Use tokens, passwords, special connectors in service center – or – Only with special, signed FW downloaded  User data is revealed  Enabler switch checked at power up (  ) – Mask keys, clear sensitive memory – Can test drive in any environment, the standard FW, bootup…

Summary

•

Self-encrypting storage

– is worth standardizing, because it is • Secure • Simple to use • Inexpensive • • Transparent Integrated • Fast • Low power… – Industry needs / benefits from standards