1. Toward Standardization of
Self-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
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”

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
• 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

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

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

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

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

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

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

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

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

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

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

19. 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. No need for secure external key storage, key tracking, auditing
ii. 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. Done with protected code in drive
ii. Passwords not stored (their iterated MAC w. unique HW key, could be)
iii. Authentication from host BIOS, clean ROM- or attested pre-boot code

20. Advantages 2
4. Fast and secure disk sanitation by erasing keys
– With proof of erasure; even on (partially) failed drives!!
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

21. Advantages 3
8. High speed encryption (at interface speed)
– 0 host processor load, delay
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

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

23. Advantages 5
17. Strong authentication: number of failed logins restricted
(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. 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

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

25. Advantages 7
26. Support for disk arrays
a) Unchanged SCSI Protection Info (routing ID)
b) Valid error checking info (checksum, CRC)
c) 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) De-duplication
b) Compression
c) Indexing
d) RAID rebuild
e) Virus scanning, media fingerprints…
28. Open interface, easy support for all OS’es

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

27. 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
– 2nd 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

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

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

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

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

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

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

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

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

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

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