Phantomdrive: An Open Source Secure USB Drive with Hidden Volumes

Phantomdrive: An Open Source Secure USB Drive with Hidden Volumes

Phantomdrive provides hardware-level plausible deniability

Phantomdrive is an open-source USB drive designed to hide sensitive data from unauthorized users, including those who may force a user to decrypt their media. The device initially presents itself as a standard 8 GB drive; the remainder of the disk remains invisible to the operating system until a specific trigger is met. To unlock the hidden section, the user must edit a plaintext file on the visible portion of the disk and enter a password in the format password:PUTYOURPASSWORDHERE. Upon detection of this string, the device unmounts itself and remounts the second, AES-256 encrypted hidden section.

Hardware Architecture and Design

The Phantomdrive is built using open-source firmware, hardware, and mechanical engineering. The core components include:

  • Controller: The CH569 chip, which provides USB3, SD/eMMC support, and an AES block.
  • Storage: An SD card is used for memory (chosen over eMMC due to current market costs). The device is encased in epoxy to prevent physical access to the SD card without destroying the device.
  • Connectivity: The board includes a USB port, two buck supplies, and UART test points for firmware development.

Cryptographic Implementation

The device employs AES-256 for encryption and decryption in place. The author has verified the implementation against OpenSSL's AES implementation via functional tests.

Key Derivation Function (KDF)

To prevent brute-force and precomputed table attacks, Phantomdrive uses a custom Key Derivation Function (KDF):

  1. Salt: Each device uses a unique salt derived from the device's serial number (ID_SERIAL_SHORT). This ensures that an SD card cannot be moved to another device and that attackers cannot use global lookup tables.
  2. Hashing: The KDF performs 100,000 rounds of SHA-256. This number was chosen to balance security with user experience, resulting in an unlock time of approximately 3 seconds. The author notes that memory-hard algorithms like Argon2 were not feasible due to the hardware's compute and memory limits.

AES Modes and Performance

The device supports different AES modes, though the default choice involves a trade-off between speed and security:

  • AES-CTR (Counter Mode): This is the primary mode used for performance, yielding approximately 9MB/s write and 20MB/s read speeds. However, it is susceptible to "counter reuse" attacks if an attacker can capture multiple versions of the ciphertext.
  • AES-XTS (Tweaked Codebook Mode): The industry standard for disk encryption. While more secure against counter reuse and bit-flipping attacks, it is slower, providing 6MB/s write and 10MB/s read speeds.
  • AES-ECB (Electronic Codebook): Explicitly avoided due to lack of diffusion and predictability.

Firmware and Password Snooping

The firmware is built upon the wch-ch56x-lib and wch-ch56x-isp libraries. Because the device is not filesystem-aware, it implements a "snooping" mechanism to handle the unlock trigger. The firmware monitors all USB WRITE10/READ10 commands; when it detects the string password:, it captures the subsequent characters into RAM, zeros out the buffer to ensure the password is never written to the physical disk, and triggers the remount of the hidden volume.

Community Critique and Security Analysis

Discussion among technical users on Hacker News highlighted several critical security concerns regarding the device's design:

KDF and Brute Force Vulnerabilities

Critics argue that a SHA-256 based KDF is insufficient against state-level adversaries.

"He can't use a memory-hard KDF because of his BOM... but that doesn't change the fact that this KDF is probably ~50x faster than standard bcrypt hardness and on realistic human passwords is probably crackable in minutes-to-hours on a dedicated rig."

Furthermore, since the KDF is performed in software on the device, an attacker who clones the disk image can perform the brute-force attack on high-end GPU clusters, bypassing the device's 3-second unlock delay.

Plausible Deniability and Detection

Some users pointed out that the act of owning a "Hidden Drive" from a specialized company may undermine the very plausible deniability the device seeks to provide. Additionally, the use of an embedded SD card reader may be detectable via X-ray or hardware analysis.

AES-CTR Risks

Security researchers noted that AES-CTR allows an attacker to flip bits at chosen offsets in the plaintext without knowing the key, which could be used to modify binaries (e.g., changing a password check in a sudo binary) without decrypting the data. AES-XTS is recommended to mitigate this risk.

Alternative Suggestions

Community members suggested several alternatives for those requiring higher security:

  • Using a TPM (Trusted Platform Module) to rate-limit password guesses at the hardware level.
  • Utilizing established software solutions like VeraCrypt hidden volumes or Linux LUKS partitions.
  • Embedding the encrypted volume within a non-storage device (e.g., a camera or power bank) to reduce suspicion.

Sources