Verifying Claims of Full-Disk Encryption in Hard Drive Firmware

Donate for the Cryptome archive of 65.000 files from June 1996 to the present

9 November 2011

Verifying Claims of Full-Disk Encryption in Hard Drive Firmware

Date: Wed, 9 Nov 2011 10:16:11 +0100
From: Eugen Leitl <eugen[at]leitl.org>
To: cypherpunks[at]al-qaeda.net
Subject: Re: [p2p-hackers] Verifying Claims of Full-Disk Encryption in
Hard Drive Firmware

----- Forwarded message from Tom Ritter <tom[at]ritter.vg> -----

From: Tom Ritter <tom[at]ritter.vg>
Date: Tue, 08 Nov 2011 19:51:53 -0500
To: p2p-hackers[at]lists.zooko.com
Subject: Re: [p2p-hackers] Verifying Claims of Full-Disk Encryption in Hard
Drive Firmware
Reply-To: theory and practice of decentralized computer networks <p2p-hackers[at]lists.zooko.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After reviewing the FIPs approval document for the drive[1], I've tried to put together a complete threat model outlining the major classes of attack on the hard drive in the interest of being rigorous. I'd like your input to see if I missed any you can think of. I've explicitly excluded DriveTrust (the proprietary stuff) from the threat model, and am only focusing on the ATA Standard.

[1] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1388.pdf

====================

In approximate physical/logical order, this is every attack I can conceive of:

1. The BIOS may have been replaced to record passwords

2. The keyboard or keyboard connection may be tapped/keylogged

3. The physical computer may have been tampered with physically installing hardware in any of its components

4. The Operating System may have been tampered with

5. The application used to interact with the hard drive (hdparm) may have been subverted

6. The SATA connection to the HDD may have been tapped

7. On the Drive

1. The hardware of the drive may been tampered with
2. Firmware
1. The firmware may be buggy allowing code execution on the Hard Disk Drive
2. The firmware may have been replaced. Supposedly, the firmware replace requires the firmware be signed with a private RSA key AND that the drive have the Load Firmware capability active. The public key is stored on the system storage area of the media
1. The firmware may be able to be loaded despite the load firmware capability inactive
2. The firmware load process may have a bug invalidating the signature
3. The malicious firmware may be appropriately signed
4. The public key in the system storage area may have been replaced, allowing untrustworthy firmware be loaded

3. The RAM of the device may be able to be read, allowing unknown compromising vectors.
1. The encryption key may be stored in RAM
2. The Seed Key and Seed used in the Random Number Generator may be read, allowing any new key that is generated to be guessed.
3. Internal states to the encryption process, or other operation of the firmware may be exposed
4. System Storage Area - An area of the drive that is supposed to only be able to be read by the firmware, and not the computer.
1. Secure ID aka Drive Owner (SHA Digest)
1. If the system area is able to be read, an unsalted simple SHA may be crackable
2. If the system area is able to be written, this may be replaced with a hash of a known password.
3. If the Drive Owner PIN has not been changed upon initialization, the PIN is printed on the drive

2. User & Master Passwords (SHA Digest)
1. If the System Area is able to be read, an unsalted simple SHA digest may be crackable
2. If the system area is able to be written, this may be replaced with a hash of a known password.

3. User/Master Encryption Keys (Plaintext?)
1. The the System Area is able to be read, plaintext storage of the keys allows full data recovery
2. If the Random Number Generator is not cryptographically secure, the encryption key may follow a guessable pattern

4. Firmware Public RSA Key
1. The the System Area is able to be written to, the firmware key may be replaced and new firmware loaded

5. User Storage Area - where your data is stored.
1. The data may not be encrypted with AES as promised
2. The cipher mode may not be suitable for filesystem encryption
3. The drive may be initialized in a non-random pattern, allowing usage analysis
4. The ciphertext may be stored in a way allowing block swapping, ciphertext injection, or otherwise damaging the integrity of the ciphertext

6. The Drive may be vulnerable to side channel attacks
1. Crypto operations may not be constant-time leaking data about the key structure or value
2. Drive may not draw power equally during crypto operations leaking data about the key structure or value
3. The drive may not be acoustically silent, leaking information about where on the platters the data is being written by listening to drive head movements.
4. The drive may not be protected against induced faults such as power manipulation, temperature extremes, electrical shocks, or physical shocks.

8. AT Password Security Protocol

1. Passwords may be attempted at a rapid sequence if a mechanism to reset the module is created.

====================

This groups those attacks together, and notes whether I consider them within the realm of testing for the drive. I'm not sure what will be doable easily or cheaply, but if I can verify the firmware, I'll try.

Not Considered for evaluation

User Coercion or Cooperation / "Evil Maid" Attacks

1. Hardware tampering or tapping of the Keyboard, Keyboard connection, Computer, SATA connection or HDD Pwnage
1. Subversion of the Operating System, BIOS, or hdparm

Misconfiguration

1. Not changing the Master or Drive Owner password
2. Not enabling hard disk security

Side Channel Attacks

Considered for Evaluation

1. Buggy firmware

1. with regards to firmware signature verification
2. with regards to firmware replacement despite load firmware capability disabled
3. with regards to randomly selecting an encryption key
4. with regards to proper encryption
5. with regards to backdoors
6. with regards to memory trespass or other "standard" vulnerabilities

2. Key Management

1. plaintext storage of encryption keys in system area
2. poor password hashing practices of passwords

3. Encryption

1. lack of encryption of user data
2. Improper cipher mode
3. Patterned initial fill of disk
4. Lack of ciphertext integrity

4. System Area

1. ability to read system area
2. ability to write system area

====================

Again, all comments welcome, but particularly interesting in talking to

- Anyone familiar with these Seagate drives or DriveTrust.

- Anyone familiar with BIOS support for the AT Security Spec, who can help me locate a new netbook to work with.

- Anyone familiar with Data Recovery Services who could provide information on disk unlocking, AT password bypass, or moving platters between disks.

- Anyone who has done this before.

- -tom
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAk65zqYACgkQJZJIJEzU09sNfwCfX3APmmrtFBke2CI3Ia1Rot+4
cDQAn00ezd8VPehRXAYCIM80bh464I6A
=AwIs
-----END PGP SIGNATURE-----
_______________________________________________
p2p-hackers mailing list
p2p-hackers[at]lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers

----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

From: Peter Gutmann <pgut001[at]cs.auckland.ac.nz>
To: cypherpunks[at]al-qaeda.net, eugen[at]leitl.org
Subject: Re: [p2p-hackers] Verifying Claims of Full-Disk Encryption in
Hard Drive Firmware

Eugen Leitl <eugen[at]leitl.org> quotes Tom Ritter <tom[at]ritter.vg>:

>After reviewing the FIPs approval document for the drive[1], I've tried to
>put together a complete threat model outlining the major classes of attack on
>the hard drive in the interest of being rigorous.

Without wanting to sound too facetious, and mostly out of curiosity, what does FIPS 140 have to do with the threat modelling you've done? It doesn't address the vast majority of the stuff you've listed, so the threat-modelling is kind of a non-sequitur to "starting with FIPS 140". If you wanted to deal with this through a certification process you'd have to go with something like the CC (and an appropriate PP), assuming the sheer suckage of working with the CC doesn't tear a hole in the fabric of space-time in the process.

Peter.