[HOWTO] Anti-forensics Mass Storage Device as a key device for FDE

[BlueMatt]

This is all inspired by Travis Godspeed's 29c3 talk. If you haven't seen it its excellent and you should go watch it (because it suggests some other cool uses for USB dev boards like the rubber ducky).

The goal is to create a anti-forensics drive which is used as a full drive encryption keyfile/keydevice.  This means that in the process of forensic imaging of the keydevice, the key material itself will be deleted before it can be read.  Essentially, the goal is to create a full drive encryption setup for the reasonably paranoid cyber-criminal.

The specific goals of this project:

• A forensic investigator who attempts to make a forensic image of the key storage device should, as a result of the imaging, clear all useful information from the drive before said useful information is imaged. This means a court can't later compel you to decrypt your drives.
• A keen investigator shall not be able to derive the keying material directly from the SD card, given the assumption that the Rubber ducky was actually a simple SD card reader. Note that a court will probably compel you to reveal the relevant info, so you better hope it gets cleared before the SD card is imaged.
• Given knowledge of the Rubber Ducky and the firmware source, there should be no way to decrypt the contents of the SD card without reading from the ducky itself and probabilistically clearing it before reaching the keying material.
• Short of knowing the key sector and passphrase, there should be no reliable way to steal keying material given physical access (ie we shall be coldboot-attack resistant).

How it works
To accomplish this, we use a tweaked version of TRESOR (sorry Windows folks, I wrote this for myself and I'm on linux) and a custom Rubber Ducky firmware. If you don't care about being coldboot resistant, you could probably use any keyfile-using drive encryption software with a bit of work (to find the sector constants you will need). The firmware works by acting as a standard mass storage device, with some tricks. First it encrypts the data on the SD card (AES-CBC with a key hardcoded in the firmware). Second, it has a range of data which it considers "private" and a range around that private data which is considered a trigger. If you read from anywhere in the trigger range, it will clear the AES key, resulting in all data being lost. Note that a forensic image of a drive will almost always read it sequentially, resulting in the private section being cleared before it is read. Also note that a clever forensic imaging software which reads random blocks all over the place to avoid anti-forensics detection will probabilistically also trigger clearing of private data before the one important sector is read.

How-To(ish)

You can find the Rubber Ducky firmware source at https://github.com/TheBlueMatt/Mass_Storage/. In order to flash, you need to install Atmel Studio and open the project. Then go to src/asf/common/components/memory/sd_mmc/sd_mmc_mem.c and take a look at the settings at the top of the file:

• READ_ONLY: sets the usb device to appear read-only to the host and reject all write requests.
• USE_ARRAY: uses the array defined at array.h (you need to provide your own array.c) which contains the first N bytes of the storage contents. This gets compiled into the ROM and is just a slight optimization. (it only works if you are running READ_ONLY).
• USE_ENCRYPTION: encrypt the contents of the SD Card, provide your own aes key in AES_KEY and your own IV seed in AES_IV_XOR. If you only want to encrypt after a certain block (eg I have a partition on my SD card which is not encrypted and a second one which is) then set CRYPT_START to the first block which you want encrypted.
• CLEAR_ON_READ: Enables the clearing of the AES keys if a read occurs between BAD_START_SECTOR and OK_START_SECTOR or between OK_END_SECTOR and BAD_END_SECTOR (include in the BAD_* sectors, not including the OK_* sectors).

Flash your .hex, making sure to SET THE SECURE FLAG on the device after flashing. Then, overwrite the SD card with random data and pick a random sector in your private range to be your keydevice for TRESOR. You can find my version of TRESOR (which has been modified to work with keydevices) at https://github.com/TheBlueMatt/linux. Note that its also a WIP, though most bugs are worked out and I am transitioning to it for daily use.

On backing up your key

Note that when the trigger happens, only the AES keys on the device are removed, the data isn't actually lost. If you still have the original .hex, you can flash the ducky and read the data as it was. That said, keeping the .hex around unencrypted or encrypted with a password which you can be compelled to give up is useless, so I recommend keeping a copy of the key sector encrypted somewhere out on the net that no one knows about (eg encoded base64 and thrown in the description of edits on wikipedia or similar).

Thanks

• Travis Godspeed for the original idea
• The original TRESOR team at Uni-Erlangen
• Hak5 for the USB Development Board in a very covert casing
• Atmel for the solid datasheets and clean APIs/example MSC controller on which this firmware is based

Edits

• Feb 20: Fixed a few incorrect hex constants
• Feb 23: Whole new firmware from the ground-up, including AES for the SD card, resulting in perfect probabilistic privacy. Because I doubt many others are actually interested (Im just gonna use this thread as a place to link when sharing info on this project), Im not gonna bother distributing .hex's, if anyone wants one, ask.
• Feb 24: Redo how clearing is done to make it actually secure.

Edited February 24, 2013 by BlueMatt

[no42]

Slight deviation from anti-forensics....

Also Philip Polstra has demoed an interesting forensic capability with FTDI chips http://itm.iit.edu/netsecure11/PhilipPolstra_USBForensics.pdf

its interesting as he goes into some details on the USB protocol. He is probably working on some interesting USB developments this year. He's another to keep an eye on.

He chose FTDI, as he initially thought AVRs weren't up to the job, my firmware releases have proved otherwise.

[BlueMatt]

I take back my comment about requiring an L-Series processor to lock the ROM, it turns out there is a setsecure flag for our B-series...(I need to dig in a bit deeper and make sure there really is no way to dump the ROM short of some serious processor disassembly...) But this means its possible to get probabilistically perfect security if I implement a real encryption algorithm...now to go look up RC4 implementation details.....

[BlueMatt]

Implemented with AES-CBC, turns out its actually not as slow as one might think when reading (about half the 400 i get just reading the sd card, though thats still pretty terrible for anything more than one or two blocks at a time), though its pretty slow writing. Still, we don't even have a processor with Atmel's AES instructions, and its not too shabby for that...

[Dnucna]

What about using the composite firmware and adding a final command to erase the script with random data ?

[BlueMatt]

Erase what script?

[no42]

Erase what script?

the inject.bin, not realising your firmware is different.