My USB Drive Has a Hidden Encrypted Vault

Note: This article was authored by a human, specifically for other humans.

---

The Problem: Privacy vs. Coercion

In many jurisdictions, privacy laws are ignored. There are scenarios where you might be coerced into decrypting your data or, even worse, be treated as guilty simply because your media is encrypted.

While a VeraCrypt hidden volume helps in some cases, it doesn't solve everything. This is why I am building Phantomdrive.

What is Phantomdrive?

Phantomdrive is a fully open-source USB device designed for stealth. When first connected, the OS only sees a standard 8 GB drive. The rest of the storage is completely invisible to the operating system.

The "Magic" Trigger: To reveal the hidden partition, the user simply edits a plaintext file on the visible drive with the following content: password:PUTYOURPASSWORDHERE

Once this is done, the device:

1. Unmounts the decoy partition.
2. Remounts the hidden section.
3. Performs AES-256 encryption/decryption in place.

The goal is to bypass the scrutiny of corrupt officials, authoritarian regimes, or anyone disregarding encryption rights.

---

🛠️ The Design

The project is entirely open-source across all domains: firmware, hardware, and mechanical engineering.

Hardware Specifications

I utilized the CH569 chip, produced by the same company responsible for the CH340 (the ubiquitous USB-to-Serial chip found in budget Arduinos).

Key chip features used:

• USB3 support
• SD/eMMC interface
• AES hardware block

Note: The chip also includes an SM4 encryption block, which is the commercial cryptography standard in China.

Component Breakdown

• CH569 Microcontroller
• USB Port
• Dual Buck Supplies
• Firmware Update Button
• SD Card (Storage)
• Support Components
• UART Test Points (for development)

Storage Choice: Due to the AI boom, eMMC prices have skyrocketed. Consequently, I used an SD card. While a determined attacker could physically extract the card, the data remains encrypted. To prevent easy access, I used epoxy to seal the case; getting inside requires destroying the device.

I'll use eMMC now $\rightarrow$ I will release an eMMC version once prices stabilize.

---

🔐 The Cryptography

Community Feedback

I recently missed several AI-generated GitHub issues. Most were hallucinations or already patched, though some raised valid points about AES-XTS. I've since verified the encryption functionality against OpenSSL's AES implementation.

The Key Derivation Function (KDF)

A KDF transforms a password into a cryptographic key.

Level 1: Basic (Insecure) $K = Pw \parallel 0x000$ Password is padded with zeros to 32 bytes. A weak password (e.g., password1234) can be cracked in minutes.

Level 2: Salted (Better) $K = Pw \parallel salt \parallel 0x000$ By using a unique salt per device, attackers cannot use pre-computed lookup tables. However, this means the SD card is bound to the specific hardware.

How to retrieve your salt for recovery:

udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
# Output Example: ID_SERIAL_SHORT = Phantomdrive:34FC1FA7145467F7

The salt here is 34FC1FA7145467F7.

Level 3: Hardened (Current Implementation) To thwart powerful machines, I added 100,000 rounds of SHA-256: $K = \text{sha256}^{100k}(Pw \parallel salt \parallel 0x000)$

Constraints:

• Unlock Time: ~3 seconds.
• Memory: I cannot use memory-hard algorithms like Argon2 due to hardware limits.
• Customization: You can increase rounds for more security or disable encryption entirely to use software-based tools.

---

AES Modes Comparison

AES is a block cipher (16-byte blocks). To handle streams of data, different "modes" are used:

CTR Implementation Logic

The device encrypts a counter and XORs it with the plaintext:

uint64_t i = 0;
while (i < len(ciphertext)) {
    ctr = aes_encrypt(i);
    ciphertext[i] = plaintext[i] ^ ctr;
    i++;
}

Performance Benchmarks

Verdict: I chose AES-CTR because the speed advantage outweighs the marginal security gain of XTS for my specific use case.

Process Flow