toward standardization of self encrypting storage n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Toward Standardization of Self-Encrypting Storage PowerPoint Presentation
Download Presentation
Toward Standardization of Self-Encrypting Storage

Loading in 2 Seconds...

play fullscreen
1 / 37

Toward Standardization of Self-Encrypting Storage - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

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…

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Toward Standardization of Self-Encrypting Storage' - kalil


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
toward standardization of self encrypting storage

Toward Standardization ofSelf-Encrypting Storage

Security in Storage Workshop

Baltimore, September 25, 2008

Laszlo Hars

Laszlo.Hars@Seagate.com

introduction
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? ⇒
outline
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
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…
concerned parties
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
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”
threat model attack scenarios 1
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
Threat Model, Attack Scenarios 2
  • 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 3
Threat Model, Attack Scenarios 3
  • 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 4
Threat Model, Attack Scenarios 4
  • 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)
goals 1
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)
  • Breaking one disk drive (discovering its keys) should not help in breaking others
    • Globally unique Root Key in electronics
      • Physical process variations / one time programmable key
goals 2
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
Goals 3
  • Can use metadata P1619
    • LBA, Age of data, Drive ID, Track geometry, ErrCC...
  • Security at known (meta) data 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…)
alternatives of self encrypting storage 1
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
alternatives 2
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
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
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
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
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 (their iterated MAC w. unique HW key, could be)
      • Authentication from host BIOS, clean ROM- or attested pre-boot code
advantages 2
Advantages 2
  • Fast and secure disk sanitation by erasing keys
    • With proof of erasure; even on (partially) failed drives!!
  • 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
advantages 3
Advantages 3
  • High speed encryption (at interface speed)
    • 0 host processor load, delay
  • 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
advantages 4
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
advantages 5
Advantages 5
  • Strong authentication: number of failed logins restricted (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
  • DRM w/o high processor load or “dirty” tricks (rootkits)
    • Clean design, Better system stability
    • Secure computation in the drive (scripting)
    • Secure, hidden storage
advantages 6
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
advantages 7
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
possibilities with external support
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
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
trust user verification
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
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
interfaces
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
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
    • For speed: Interleaved sub-chains processed in parallel
  • Counter mode, initialized with LBA
    • When previous block contents 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

data integrity authentication
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 on block groups
    • 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 read (fast)
    • Log n MAC updates at write (in system sectors)
    • Constant portion of storage capacity used
key management
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
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
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 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
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