Normal encryption protects files until the owner discloses the password. However, in some countries, a person may be forced to unlock the media, and the very fact of having an encrypted section can cause additional questions. The open project Phantomdrive offers a different approach: when connecting the flash drive, the usual 8 GB drive shows the computer, and the remaining memory is not determined by the operating system.
The hidden section opens without a separate program. The user edits the text file on the available part of the drive and records the string password
UTYOURPASSWORDHERE, substituting your password instead of the template. The device intercepts the record, retracts the password, disables the visible partition and connects the encrypted area. Encryption and decryption are performed inside the flash drive itself using AES-256.
passwordUTYOURPASSWORDHERE
The developer positions Phantomdrive as a carrier with plausible external content. The computer receives information only about the 8 GB open and does not see the remaining disk capacity. The approach is different from the hidden volume of VeraCrypt: the software container usually leaves signs of additional encrypted space, while Phantomdrive limits access at the level of the USB storage controller.
The project is fully open. In free access, a principled scheme, a printed circuit board, firmware and the design of the body are published. Open tools were used for the design, so the device can be studied, changed or assembled independently.
The basis of the drive is the microcontroller CH569. The chip is produced by the same company that produces a CH340 converter, well known on low-cost boards compatible with Arduino. Phantomdrive uses a USB 3.0 controller, an SD/eMMC interface and the AES hardware unit. Inside the CH569 there is also a module of the Chinese SM4 algorithm, but it is not used in the project.
The memory is stored on the SD card. The developer planned to apply eMMC, but the growth in demand from equipment manufacturers for artificial intelligence raised prices for such chips. The eMMC version should appear later when the value of the memory decreases.
The SD card remains physically available when dismantling the body, but the entire hidden area is encrypted. Half of the body is glued with epoxy resin, so the autopsy will most likely damage the drive. Such protection does not replace a specialized body with intervention sensors, but complicates the imperceptible extraction of the map.
The electronic part consists of CH569, USB connector, two reduction voltage converters, SD cards, firmware update buttons and auxiliary components. The fee also provides contact areas of UART, which are used during development and debugging.
After the publication of the project on GitHub, automatic reports of possible vulnerabilities appeared. Part of the comments described already corrected errors, some contained incorrect conclusions, and some real restrictions were sued without taking into account the model of threats. The most meaningful discussion touched upon the AES-XTS mode, which is commonly used to encrypt disks.
The developer checked the work of the cryptographic part with functional tests. The firmware encrypted known data, after which the result was compared with the implementation of AES in OpenSSL. The coincidence confirmed that the hardware unit and the software logic perform conversions in the same way.
The password cannot be used directly as the AES-256 key. The algorithm requires a 32-byte key, but a simple addition of a password with zeros almost does not complicate the cost. A weak combination like password1234 Modern equipment can be checked in a short time.
uint8_t key[32] = {0};
memcpy(key, password, password_length);
An additional problem is created by pre-calculated tables. The attacker can once prepare the keys for common passwords, and then quickly compare them with the data of different devices. Phantomdrive adds to the password a unique salt associated with a specific instance of a flash drive. Therefore, the table has to be recalculated for each drive.
Salt can be found in Linux through the serial number of the USB device:
udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7
In the above example, the salt is a sequence 34FC1FA7145467F7. The value must be saved separately: without it, it will be more difficult to recover data after breaking the controller. It will not be possible to rearrange the SD card to another instance of the Phantomdrive either, since the new controller uses another salt.
The name of the device, manufacturer identifiers and the USB product can be changed in the firmware. This setting allows you to disguise Phantomdrive under another drive, but the wrong values can cause compatibility problems or make it difficult to restore data.
The key development function performs 100 thousand rounds of SHA-256. Repeated hashing slows down every attempt to select a password. The drive itself opens a hidden section in about three seconds, and the attacker is forced to spend a comparable amount of calculations on each checked combination.
for (uint32_t i = 0; i < 100000; i++) {
sha256(password_and_salt, input_length, key);
memcpy(password_and_salt, key, sizeof(key));
}
Argon2 or scrypt algorithms could more complicate too much, as they require a large amount of memory. The capabilities of CH569 are limited, so such functions are not fit into the available resources and acceptable unlocking time. The owner can increase the number of SHA-256 rounds, but then the hidden section will open longer.
The developer also allows dual encryption by means of the operating system. In another script, hardware encryption can be disabled and used by Phantomdrive only to hide the section by entrusting VeraCrypt, LUKS or BitLocker data protection.
AES processes blocks of 16 bytes, so the disk needs a mode that connects many blocks into a single stream. The simplest version of the AES-ECB encrypts each fragment separately. The same open blocks are transformed into the same ciphertext, which is why the structure of the original data is partially preserved.
The ECB mode also does not protect the order and integrity of the blocks. The attacker can delete or rearrange the sections of encrypted data, and after decryption, the changes will predictably affect the content. For a disk drive, such a scheme is unsuitable.
Phantomdrive supports AES-CTR. The mode encrypts the sequence of meter values, and then combines the result with the open text XOR operation. Simplified logic is as follows:
uint64_t i = 0;
while (i < len) {
uint8_t stream_byte = aes_encrypt_counter(i);
ciphertext = plaintext ^ stream_byte;
i++;
}
The main risk of AES-CTR is associated with the reuse of the meter. An attacker can copy the encryption, return the device to the owner, wait for the recording of new data and re-get the contents of the disk. If one of the two versions is partially known or guessed, the repeated stream allows you to recover information from another.
AES-XTS is usually used for disks. The mode uses two keys: the first encrypts data, the second creates a variable value for each sector and block. The sector number is involved in the calculation, so the same fragments at different parts of the disk receive different ciphertext.
tweak = AES(key2, sector_number)
C0 = AES(key1, P0 XOR tweak0) XOR tweak0
C1 = AES(key1, P1 XOR tweak1) XOR tweak1
C2 = AES(key1, P2 XOR tweak2) XOR tweak2
XTS fixes the main recurrent problem, but requires more calculations. Phantomdrive records data with AES-CTR at a speed of about 9 MB / s and reads at a speed of 20 MB / s. With AES-XTS, the speed drops to about 6 MB / s when recording and 10 MB / s when reading.
The developer has chosen CTR as a compromise between speed and its threat model, but directly warns of restrictions. A user who is more important than resistance to re-removing the disk image can switch to XTS or further encrypt the media with software.
The firmware is based on two open libraries.
https://github.com/hydrausb3/wch-ch56x-lib
https://github.com/hydrausb3/wch-ch56x-isp
The controller does not disassemble the file system and does not know where the particular text file is located. When exchanging with a computer, it receives USB Mass Storage commands WRITE10 and READ10, and then transfers them to the SD card commands. Therefore, the password is searched directly in the raw stream of the recorded data.
void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
const char *prefix = "password:";
const size_t prefix_len = 9;
uint32_t i;
for (i = 0; i + prefix_len <= len; i++) {
if (buf != 'p')
continue;
if (memcmp(buf + i, prefix, prefix_len) != 0)
continue;
size_t pw_start = i + prefix_len;
size_t pw_end = pw_start;
while (pw_end < len
&& (pw_end - pw_start) < sizeof(pending_pw)
&& buf[pw_end] != '\n'
&& buf[pw_end] != '\r'
&& buf[pw_end] != '\0') {
pw_end++;
}
size_t pw_len = pw_end - pw_start;
memcpy(pending_pw, buf + pw_start, pw_len);
pending_pw_len = pw_len;
memset(buf + i, 0, pw_end - i);
return;
}
}
The function views each entry into the open section and searches for a sequence password:. Symbols after the prefix are copied into the RAM before the translation of the string, zero byte or the achievement of the established limit. Then the original buffer is filled in with zeros, so the password does not get on the SD card.
The approach creates a risk of accidental action. If the user stores large amounts of data on the open part, and a sequence will occur within one of the files password:, the controller may accept the following text as the unlock command. The firmware does not check the file name and its location as it works below the file system level.
Phantomdrive remains an experimental device, not a certified cryptographic medium. Of course, this flash drive does not protect against a weak password, computer compromise, hardware analysis of the controller and coercion, in which the inspector is already aware of the existence of a hidden partition. The selected AES-CTR mode also requires taking into account the risk of re-coating of the ciphertext.
The main feature of the storage device is not in the new encryption algorithm, but in a combination of hardware-hidgent capacity, local password processing and a fully open design. Any specialist can check the firmware, replace the CTR with XTS, change the number of rounds of key development function or redesign the unlocking mechanism under its own threat model.
The hidden section opens without a separate program. The user edits the text file on the available part of the drive and records the string password
UTYOURPASSWORDHERE, substituting your password instead of the template. The device intercepts the record, retracts the password, disables the visible partition and connects the encrypted area. Encryption and decryption are performed inside the flash drive itself using AES-256.password
UTYOURPASSWORDHEREThe developer positions Phantomdrive as a carrier with plausible external content. The computer receives information only about the 8 GB open and does not see the remaining disk capacity. The approach is different from the hidden volume of VeraCrypt: the software container usually leaves signs of additional encrypted space, while Phantomdrive limits access at the level of the USB storage controller.
The project is fully open. In free access, a principled scheme, a printed circuit board, firmware and the design of the body are published. Open tools were used for the design, so the device can be studied, changed or assembled independently.
The basis of the drive is the microcontroller CH569. The chip is produced by the same company that produces a CH340 converter, well known on low-cost boards compatible with Arduino. Phantomdrive uses a USB 3.0 controller, an SD/eMMC interface and the AES hardware unit. Inside the CH569 there is also a module of the Chinese SM4 algorithm, but it is not used in the project.
The memory is stored on the SD card. The developer planned to apply eMMC, but the growth in demand from equipment manufacturers for artificial intelligence raised prices for such chips. The eMMC version should appear later when the value of the memory decreases.
The SD card remains physically available when dismantling the body, but the entire hidden area is encrypted. Half of the body is glued with epoxy resin, so the autopsy will most likely damage the drive. Such protection does not replace a specialized body with intervention sensors, but complicates the imperceptible extraction of the map.
The electronic part consists of CH569, USB connector, two reduction voltage converters, SD cards, firmware update buttons and auxiliary components. The fee also provides contact areas of UART, which are used during development and debugging.
After the publication of the project on GitHub, automatic reports of possible vulnerabilities appeared. Part of the comments described already corrected errors, some contained incorrect conclusions, and some real restrictions were sued without taking into account the model of threats. The most meaningful discussion touched upon the AES-XTS mode, which is commonly used to encrypt disks.
The developer checked the work of the cryptographic part with functional tests. The firmware encrypted known data, after which the result was compared with the implementation of AES in OpenSSL. The coincidence confirmed that the hardware unit and the software logic perform conversions in the same way.
The password cannot be used directly as the AES-256 key. The algorithm requires a 32-byte key, but a simple addition of a password with zeros almost does not complicate the cost. A weak combination like password1234 Modern equipment can be checked in a short time.
uint8_t key[32] = {0};
memcpy(key, password, password_length);
An additional problem is created by pre-calculated tables. The attacker can once prepare the keys for common passwords, and then quickly compare them with the data of different devices. Phantomdrive adds to the password a unique salt associated with a specific instance of a flash drive. Therefore, the table has to be recalculated for each drive.
Salt can be found in Linux through the serial number of the USB device:
udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7
In the above example, the salt is a sequence 34FC1FA7145467F7. The value must be saved separately: without it, it will be more difficult to recover data after breaking the controller. It will not be possible to rearrange the SD card to another instance of the Phantomdrive either, since the new controller uses another salt.
The name of the device, manufacturer identifiers and the USB product can be changed in the firmware. This setting allows you to disguise Phantomdrive under another drive, but the wrong values can cause compatibility problems or make it difficult to restore data.
The key development function performs 100 thousand rounds of SHA-256. Repeated hashing slows down every attempt to select a password. The drive itself opens a hidden section in about three seconds, and the attacker is forced to spend a comparable amount of calculations on each checked combination.
for (uint32_t i = 0; i < 100000; i++) {
sha256(password_and_salt, input_length, key);
memcpy(password_and_salt, key, sizeof(key));
}
Argon2 or scrypt algorithms could more complicate too much, as they require a large amount of memory. The capabilities of CH569 are limited, so such functions are not fit into the available resources and acceptable unlocking time. The owner can increase the number of SHA-256 rounds, but then the hidden section will open longer.
The developer also allows dual encryption by means of the operating system. In another script, hardware encryption can be disabled and used by Phantomdrive only to hide the section by entrusting VeraCrypt, LUKS or BitLocker data protection.
AES processes blocks of 16 bytes, so the disk needs a mode that connects many blocks into a single stream. The simplest version of the AES-ECB encrypts each fragment separately. The same open blocks are transformed into the same ciphertext, which is why the structure of the original data is partially preserved.
The ECB mode also does not protect the order and integrity of the blocks. The attacker can delete or rearrange the sections of encrypted data, and after decryption, the changes will predictably affect the content. For a disk drive, such a scheme is unsuitable.
Phantomdrive supports AES-CTR. The mode encrypts the sequence of meter values, and then combines the result with the open text XOR operation. Simplified logic is as follows:
uint64_t i = 0;
while (i < len) {
uint8_t stream_byte = aes_encrypt_counter(i);
ciphertext = plaintext ^ stream_byte;
i++;
}
The main risk of AES-CTR is associated with the reuse of the meter. An attacker can copy the encryption, return the device to the owner, wait for the recording of new data and re-get the contents of the disk. If one of the two versions is partially known or guessed, the repeated stream allows you to recover information from another.
AES-XTS is usually used for disks. The mode uses two keys: the first encrypts data, the second creates a variable value for each sector and block. The sector number is involved in the calculation, so the same fragments at different parts of the disk receive different ciphertext.
tweak = AES(key2, sector_number)
C0 = AES(key1, P0 XOR tweak0) XOR tweak0
C1 = AES(key1, P1 XOR tweak1) XOR tweak1
C2 = AES(key1, P2 XOR tweak2) XOR tweak2
XTS fixes the main recurrent problem, but requires more calculations. Phantomdrive records data with AES-CTR at a speed of about 9 MB / s and reads at a speed of 20 MB / s. With AES-XTS, the speed drops to about 6 MB / s when recording and 10 MB / s when reading.
The developer has chosen CTR as a compromise between speed and its threat model, but directly warns of restrictions. A user who is more important than resistance to re-removing the disk image can switch to XTS or further encrypt the media with software.
The firmware is based on two open libraries.
https://github.com/hydrausb3/wch-ch56x-lib
https://github.com/hydrausb3/wch-ch56x-isp
The controller does not disassemble the file system and does not know where the particular text file is located. When exchanging with a computer, it receives USB Mass Storage commands WRITE10 and READ10, and then transfers them to the SD card commands. Therefore, the password is searched directly in the raw stream of the recorded data.
void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
const char *prefix = "password:";
const size_t prefix_len = 9;
uint32_t i;
for (i = 0; i + prefix_len <= len; i++) {
if (buf != 'p')
continue;
if (memcmp(buf + i, prefix, prefix_len) != 0)
continue;
size_t pw_start = i + prefix_len;
size_t pw_end = pw_start;
while (pw_end < len
&& (pw_end - pw_start) < sizeof(pending_pw)
&& buf[pw_end] != '\n'
&& buf[pw_end] != '\r'
&& buf[pw_end] != '\0') {
pw_end++;
}
size_t pw_len = pw_end - pw_start;
memcpy(pending_pw, buf + pw_start, pw_len);
pending_pw_len = pw_len;
memset(buf + i, 0, pw_end - i);
return;
}
}
The function views each entry into the open section and searches for a sequence password:. Symbols after the prefix are copied into the RAM before the translation of the string, zero byte or the achievement of the established limit. Then the original buffer is filled in with zeros, so the password does not get on the SD card.
The approach creates a risk of accidental action. If the user stores large amounts of data on the open part, and a sequence will occur within one of the files password:, the controller may accept the following text as the unlock command. The firmware does not check the file name and its location as it works below the file system level.
Phantomdrive remains an experimental device, not a certified cryptographic medium. Of course, this flash drive does not protect against a weak password, computer compromise, hardware analysis of the controller and coercion, in which the inspector is already aware of the existence of a hidden partition. The selected AES-CTR mode also requires taking into account the risk of re-coating of the ciphertext.
The main feature of the storage device is not in the new encryption algorithm, but in a combination of hardware-hidgent capacity, local password processing and a fully open design. Any specialist can check the firmware, replace the CTR with XTS, change the number of rounds of key development function or redesign the unlocking mechanism under its own threat model.
