1 / 38

Toward Standardization of Self-Encrypting Storage

Toward Standardization of Self-Encrypting Storage. Security in Storage Workshop Baltimore, September 25, 2008 Laszlo Hars Laszlo.Hars@Seagate.com. Introduction. Need for secure storage Horror stories of lost data, security breaches Legislation: HIPAA, HR-516,-816,-1685…

fiona-foreman
Download Presentation

Toward Standardization of Self-Encrypting Storage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Toward Standardization ofSelf-Encrypting Storage Security in Storage Workshop Baltimore, September 25, 2008 Laszlo Hars Laszlo.Hars@Seagate.com

  2. Introduction • Need for secure storage • Horror stories of lost data, security breaches • Legislation: HIPAA, HR-516,-816,-1685… • Disk drives: 2nd 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  sealed storage) • Key management ($$) • Trust Boundary • How to encrypt? ⇒

  3. 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

  4. Scope of a Standard • Specific to self-encrypting storage ( P1619) • Block (sector) oriented storage devices • Random access (address) • 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…

  5. 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…)

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

  7. 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…

  8. 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 collisionlogon 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

  9. 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

  10. 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…

  11. 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 (>264) 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)

  12. 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

  13. 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

  14. 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 beforeauthentication • 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  secure HW design • focused ion beams, micro probes tamper proofing (+$$) • Ciphertext access only after disassembling thedrive • detected by users (tamper detectors, time away…)

  15. Alternatives ofSelf-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

  16. 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

  17. 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

  18. 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

  19. 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

  20. Advantages/Possible Features 1of Self-Encrypting Storage • Low cost. Basic features in commercial pricing models • High security • True random encryption keys: no weak user key degrades security • Keys not stored in drive: no physical attack gets data in lost drives • Keys do not leave the drive • No need for secure external key storage, key tracking, auditing • No accidental key mishandling (e.g. encrypting the key with itself) • Closed system: no malware infection • Crypto HW (single chip): no debugger, bus analyzer attacks • No SW side channel attacks by malicious processes • Protection from malicious host software • Encryption keys generated in drive, never leave the drive in the clear • User authentication • Done with protected code in drive • Passwords not stored, MAC/encrypted-hash w. HW key, iterated • After several failed authentication: lockup • In host: BIOS, clean ROM- or attested pre-boot code

  21. Advantages 2 • 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 • Authentication key encrypts data-keys in drive • Instant password change (no user data re-encryption), forregular password change, breached password, employee leaving… • Automatic protection of • virtual memory (swap file) • hibernation file • boot record, partition table • file cache, indices, recent files list… • User experience • easy to deploy: always there, always active • easy to setup: no SW or extra HW to install • cannot mis-configure: all data encrypted (index, swap, hibernate...) • automatically satisfy privacy laws, no need for data classification • easy to use: transparent, no OS/HW changes, no learning curve • always on, no several hours initialization at enabling SW encrypt

  22. Advantages 3 • High speed encryption (at interface speed) • 0 host processor load, delay • No frequent key swaps in μP for different bands (memory, speed) • Low power consumption: dedicated, optimized HW • Transparent: no need for HW or SW changes • Initial set up in the factory: operational, secure, • Internally generated secret keys • Default passwords, ID's provided on paper • Different keys for different partitions • Users, OS’es, applications are separated (sandboxes) • Un-mounted partitions safe from • Malware • User errors • Lunch-time attackers… • Support pre-boot environments • Cold boot MBR, Swap MBR after authentication, Warm boot

  23. Advantages 4 • Support for Multi-level Authentication • BIOS to open LBA band (~partition) • (Pre-boot) OS: complex authentication • Network access • Passwords, Biometrics • Tokens… • Support for third party security services • Virtual smart cards, dCards • Hidden, secure (stash) storagefor keeping secrets even on authenticated (open) drive • housekeeping info, integrity check for sensitive data, SW, drive ID • user passwords, accounts, sensitive personal info • data for digital rights management, electronic cash, game state… • Accesscontrol: ciphertext inaccessible • No data mods, traffic analysis, snapshots

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

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

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

  27. 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 • …

  28. 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 HovavShacham: 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 • 2nd worst: the open source Joomla! Content Management SystemIBM 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

  29. 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

  30. 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 (264)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

  31. 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

  32. 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,P2,P3…); C1 := AES(P1) ⊕M C1: initial count for Counter mode encryption of other blocks

  33. 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

  34. 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…

  35. 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)…

  36. 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 ($$)

  37. 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…

  38. 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

More Related