I'm Building a Secure USB Drive That Hides Itself - Rootkit Labs Blog
This article was written by a human, for humans. Link to support this project.
Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter.
This is why I made Phantomdrive.
Phantomdrive is a completely open source USB drive that appears as an 8 GB drive when first plugged in. There’s no way for the OS to detect the remainder of the disk. If the user edits a plaintext file on the disk with the contents password:PUTYOURPASSWORDHERE, it unmounts itself and remounts the second hidden section and AES-256 encrypts/decrypts in place.
With Phantomdrive, hopefully you’ll slip past authoritarian government representatives, corrupt police, and anyone else that doesn’t respect basic encryption rights.
The Design
Everything is completely open source: the firmware, hardware and mechanical engineering. The tools I used to design the device are also open source. Lets get into the design!
For this project I used an interesting little chip called the CH569 . It’s from the same company who make the USB to Serial chip (CH340 ) found on virtually every knockoff Arduino.
For this project I’m making use of the USB3, SD/eMMC and the AES block. The SM4 encryption block you can see above is apparently standardised for commercial cryptography in China - Wikipedia.
Due to AI demand the cost of eMMC memory is unusually high, so I chose to go with an SD card for memory. Someone will find your SD card if they tear it apart, but of course everything is encrypted. I used epoxy to glue the case together, meaning an attacker must destroy the device if they wish to get inside. If this doesn’t fit your requirements, I suggest you look elsewhere 😊
Once eMMC prices come down, there will be a version that uses it.
The device is simple, just the CH569, USB port, two buck supplies, a button for firmware update, SD card and some support components. There’s also UART test points, which help with firmware development.
The Cryptography
I wasn’t getting notifications when “people” opened several AI-generated GitHub issues on my repo. They outlined a mixture of: already patched problems, AI hallucinations, and small issues being blown out of proportion. Reddit dogpiled on this pretty quickly, while I was asleep.
This was a big fail on my part, I should have at least noticed people were opening issues. Most of them were non-issues, with the exception of AES-XTS which I’ll talk about below.
As for the security of the device, I’ve verified things with functional tests like this, where you can be sure the encryption is working and verified against OpenSSL’s implementation of AES.
The Key Derivation Function (KDF)
A KDF or “The Key Derivation Function” is a function used to generate a key for use in cryptography. Let’s start with the shittiest way to derive an AES key.
$$<br>K = Pw || 0x000<br>$$
We take our password, appending zeros to it until it’s 32 bytes (for AES-256) and that’s our key. With a shitty password, like “password1234”, we can brute force this in a matter of minutes. With a good password this turns into hours, and with a really good password maybe years to decades.
But what if the attacker uses a precomputed table of keys? This means they don’t even have to compute anything. To combat this issue we add a salt.
$$<br>K = Pw || salt || 0x000<br>$$
If every device has a unique salt, the attacker needs to compute keys on a per-device basis, so the lookup table problem goes away. Since the salts are different you can’t take your SD card out of one device and put it into another. Here’s how you get your salt…
udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT<br>ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7
So 34FC1FA7145467F7 is this device’s salt, which you need for data recovery if your device ever breaks. FYI: You can change “Phantomdrive” and the USB PID/VID to whatever you want by changing the firmware to increase stealth.
Let’s now assume our attacker has a really powerful machine, has gotten your salt and now will compute their own “table”. To make this a little harder we add 100,000 rounds of SHA-256 to the KDF.
$$<br>K = sha256(sha256(sha256(Pw || salt || 0x000))) … 100k<br>$$
I chose 100k rounds because the device takes ~3 seconds to unlock, any more and it takes longer. I can’t use algorithms like Argon2, because those are memory-hard. If you have a better way to do this, without making the unlock procedure more than 5 seconds I would love to hear it, but we’re at the compute limit for this device right now.
If you need more security you can increase the number of KDF SHA256 rounds, look for...