Verifying Claims of Full-Disk Encryption in Hard Drive Firmware

Verifying Claims of Full-Disk Encryption in Hard Drive Firmware

Jan 26, 2012 | Anonymous

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 with2. Firmware

1. The firmware may be buggy allowing code execution on the Hard Disk Drive2. 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 inactive2. 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 RAM2. 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 crackable2. 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 crackable2. 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 recovery2. 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 promised2. 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 value2. 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 password2. Not enabling hard disk security

Side Channel Attacks

Considered for Evaluation

1. Buggy firmware

1. with regards to firmware signature verification2. 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 area2. poor password hashing practices of passwords

3. Encryption

1. lack of encryption of user data2. Improper cipher mode

3. Patterned initial fill of disk

4. Lack of ciphertext integrity

4. System Area

1. ability to read system area2. 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.

 

 

http://cryptome.org/0005/fulldisk-crypto.htm

Namecoin – A DNS alternative based on Bitcoin

Jan 26, 2012 | Anonymous

Namecoin is a domain name system based on Bitcoin. It extends Bitcoin to add transactions for registering, updating and transferring names. The idea behind this is to provide an alternative to the existing DNS system where names can be taken from their owners by groups that control the DNS servers.

The project was originally announced in the bitcoin forums and has seen some uptake. The namecoin author, vinced, states in the post:

  • This is a new blockchain, separate from the main Bitcoin chain
  • Name/value pairs are stored in the blockchain attached to coins
  • Names are acquired through new transaction types – new, first-update and update
  • Names expire after 12000 blocks unless renewed with an update
  • No two unexpired names can be identical
  • Block validation is extended to reject transactions that do not follow the above rules
  • The code is here: https://github.com/vinced/namecoin

A number of projects have been created around this to provide a mapping from namecoin names to standard DNS. This allows resolving namecoin names to a ‘.bit’ suffixed domain. I’ll go through building the namecoin software, registering and updating names, then the software to use these names.

Building Namecoin

Namecoin needs to be built from source. The following steps on a Linux based system will build without UPNP support:

$ git clone git://github.com/vinced/namecoin.git $ cd namecoin namecoin $ make -f makefile.unix USE_UPNP=

Once built you’ll need to create a ~/.namecoin/bitcoin.conf file that contains entries for a username and password used for the JSON-RPC server that namecoind runs. Notice the name of the .conf file is bitcoin.conf even though this is namecoind. It won’t clash with an existing bitcoin installation as it is in a ~/.namecoin directory. To prevent conflict with an existing bitcoin install I suggest running namecoind on a different port. An example ~/.namecoin/bitcoin.conf is:

rpcuser=me rpcpassword=password rpcport=9332

Running namecoind will start the daemon and you can then use namecoind to execute commands:

$ ./namecoind bitcoin server starting $ ./namecoind getblockcount 2167

Yes, it prints out ‘bitcoin server starting’. There are still bitcoin references in the code that need to be changed apparently.

Getting Namecoins

To register a name you need to have some namecoins. These can be obtained via mining, just like bitcoins. Or you can buy them. To mine namecoins you can run any of the standard bitcoin miners and point them to the server and port that is running namecoind. The difficulty level for namecoin mining is currently very low (about 290 at the time of writing) so even CPU miners have a chance. Generating a block gets you 50 namecoins.

You can also buy namecoins as described here. The going rate seems to be about 1BTC for 50 namecoins.

Registering a name

The name_new command will register a name. An example invocation is:

$ ./namecoind name_new d/myname [ "1234567890123456789012345678901234567890", "0987654321" ]

This will start the registration process for the name myname. Note the two hash values returned. Once this is done you need to wait for 12 blocks to be generated by the namecoin network. You then need to run a name_firstupdate command:

$ ./namecoind name_firstupdate d/myname 0987654321 '{"map":{"":"1.2.3.4"}}'

We pass to name_firstupdate the domain name we are updating, the shorter hash that we got from name_new and a JSON value that defines how that name is mapped to an IP address.

In this case the name is mapped to the IP address 1.2.3.4. Using the existing systems for mapping names this would make myname.bit resolve to 1.2.3.4. You can also do subdomains (See the update example later).

The cost to do a name_new, followed by a name_firstupdate, varies depending on how many blocks there are in the namecoin block chain. It started at 50 namecoins and slowly reduces. The formula is defined in the namecoin design document as:

  • Network fees start out at 50 NC per operation at the genesis block
  • Every block, the network fees decreases based on this algorithm, in 1e-8 NC: 
     res = 500000000 >> floor(nBlock / 8192) res = res - (res >> 14)*(nBlock % 8192)
  • nBlock is zero at the genesis block
  • This is a decrease of 50% every 8192 blocks (about two months)
  • As 50 NC are generated per block, the maximum number of registrations in the first 8192 blocks is therefore 2/3 of 8192, which is 5461
  • Difficulty starts at 512

Updating a name

To update the domain mapping you use name_update:

$ ./namecoind name_update d/myname '{"map":{"":"1.2.3.4","www":"5.6.7.8"}}'

This example updates the value of myname so it includes a www subdomain. The name www.myname.bit will now map to 5.6.7.8.

There are other possibilities for the JSON mapping. See the namecoin README for details. Note that the JSON code must be valid JSON (ie. use double quotes, unlike the examples currently shown in the README unfortunately).

Transferring a name

To transfer a name to another person you need to get their namecoin address and do an update passing that address:

$ ./namecoind name_update d/myname '{"map":{"":"1.2.3.4"}}' NGZs7UndoWgpfTstoxryYEW8b1GtDLPwMa

Addresses can be generated with:

$ ./namecoind getnewaddress N9jzzaptnQ28uiLgWm19WZAqrGqRVVGkFX

Transferring namecoins

You can transfer namecoins to other people by sending coins to their address just like bitcoin:

$ ./namecoind sendtoaddress N9jzzaptnQ28uiLgWm19WZAqrGqRVVGkFX 50

This will send 50 namecoins to N9jzzaptnQ28uiLgWm19WZAqrGqRVVGkFX.

Listing registered names

You can list all registered namecoin names using name_scan:

$ ./namecoind name_scan { "name" : "d/bluishcoder", "value" : "{\"map\":{\"\":\"69.164.206.88\"}}", "txid" : "....", "expires_in" : 10874 },

You can also list only the names you’ve registered using name_list:

$ ./namecoind name_list { "name" : "d/bluishcoder", "value" : "{\"map\":{\"\":\"69.164.206.88\"}}", "expires_in" : 10874 }

Using namecoin names

Software needs to be modified to use namecoind to lookup the name, or you can run DNS software that connects to namecoin to do lookups. To be able to try out namecoin I modified an HTTP proxy and later tried using DNS software.

HTTP Proxy

I modified the Polipo web proxy to use namecoin for lookups. The modified source is available at https://github.com/doublec/namecoin-polipo. This can be built and run with:

$ git clone https://github.com/doublec/namecoin-polipo $ cd namecoin-polipo $ make $ ./polipo namecoindServer="127.0.0.1:9332" namecoindUsername=rpcuser namecoindPassword=rpcpassword

Changing your browser to point to the proxy on localhost, port 8123, will allow .bit domains to be used. See my forum post about it for more details.

dnsmasq

Another approach I tried was to write a program that generates a ‘host file’ from namecoind and uses dnsmasq to run a local DNS server that serves domains from this host file, falling back to the standard DNS server. The ‘quick and dirty’ code to generate the hosts file is in namecoin-hosts.c and uses libcurl and libjansson to build:

$ gcc -o namecoin-hosts namecoin-hosts.c -lcurl -ljansson

I added the following to my dnsmasq.conf:

local=/.bit/ local-ttl=300 addn-hosts=/tmp/hosts.txt

And created a shell script to update /tmp/hosts.txt with the namecoin related data:

while true; do ./namecoin-hosts 127.0.0.1:9332 rpcuser rpcpassword >/tmp/hosts.txt kill -HUP `cat /var/run/dnsmasq/dnsmasq.pid` echo `date` sleep 300 done

Pointing my OS DNS resolver to the dnsmasq IP address and port allowed .bit names to resolve.

Public .bit DNS servers

Details of a public .bit DNS server that doesn’t require you to run namecoin are available at namecoin.bitcoin-contact.org. That site also provides details on using namecoin.

More Information

Namecoin seems to be very much an experiment in having an alternative DNS like system. The developer has taken the approach of ‘release early’ and iterate towards a solution. As such it may fizzle out and go nowhere. Or it may prove a useful test-bed for ideas that make it into a successful DNS alternative.

More details about Namecoin can be obtained from:

Are there any other alternatives to DNS around with similar ideas?


http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html