Auditable and Transparent Fully Authenticated Disk Encryption via USB Storage Interposition
Source: arXiv:2607.12716 · Published 2026-07-14 · By Enrique Soriano-Salvador, Gorka Guardiola Múzquiz
TL;DR
This paper proposes a novel approach to Full Disk Encryption (FDE) by interposing a general-purpose single-board computer (SBC) with USB On-The-Go support between the host system and an external USB hard disk. The system, called Cryptographic Companion (CC), performs encryption, decryption, and authentication transparently, exposing a standard USB mass storage interface to the host while storing encrypted blocks on the external disk. Unlike traditional OS-driven FDE or dedicated hardware-based encryption enclosures, this design offers flexibility, auditability through open-source software, adaptability to new cryptographic schemes, and mitigations against malicious disk firmware. The authors implement a prototype in Go, using AES-CTR encryption and HMAC-SHA1 authentication on an Orange Pi 5 Ultra SBC, and experimentally evaluate its performance using FIO and Filebench benchmarks. Results suggest the solution incurs a moderate performance overhead but remains suitable for common workloads.
Key findings
- The CC prototype uses AES-CTR mode with per-block random nonces and HMAC-SHA1 for authentication, providing fully authenticated disk encryption (FADE) that prevents replay attacks.
- For a 480GB disk with 4096-byte blocks, the CC stores ≈4GB of metadata (nonces + HMACs) on internal storage, which is feasible with inexpensive microSD cards.
- Replay attacks are mitigated since the nonce changes on every block write and HMAC covers the plaintext, ensuring temporal data authentication.
- Two methods of keyed block address permutation were implemented: a custom fast permutation and a more secure but 40x slower Thorp shuffle.
- Ghost reads introduce dummy block reads on critical blocks (e.g. boot sector) to obfuscate disk access patterns at a configurable cost to performance.
- Experimental benchmarks show the CC prototype incurs measurable latency and throughput overhead versus direct USB disk access but remains usable for typical use cases.
- Mitigations such as keyed permutation and ghost reads prevent attackers from locating or targeting sensitive disk blocks with known plaintext data.
- Unlike typical software FDE, the CC does not store cryptographic keys or metadata on the external disk, reducing risk from offline attacks on encrypted headers.
Threat model
The adversary has full active and passive access to the external encrypted USB disk, capable of reading and modifying raw disk blocks arbitrarily and recording block access histories. The attacker can analyze disk block usage patterns, attempt cryptanalysis, and mount replay or tampering attacks against the encrypted data. However, the adversary cannot tamper with or subvert the CC device itself, nor break cryptographic keys stored securely within it. The USB communication between the host and CC is assumed secure and trustworthy. Physical attacks against the SBC hardware or memory extraction from the CC are out of scope. The model considers mitigation against malicious disk firmware that can manipulate disk block mappings or record accesses.
Methodology — deep read
The authors address the threat model of an attacker with full read/write access to the raw encrypted external disk who can analyze block addresses and attempt cryptanalysis, but cannot tamper with or subvert the CC device itself. The CC acts as a trusted inline USB intermediary, trusted hardware and software.
The data flow is implemented using commodity hardware: an Orange Pi 5 Ultra SBC running Linux with USB OTG is connected inline between the host and a standard SSD in a USB enclosure. The host mounts a /dev/sda device exported by the CC, unaware encryption is applied. Internally, the CC reads encrypted blocks from the external disk (exposed as /dev/sdb) and decrypts and authenticates them before serving plaintext blocks over USB to the host.
The core CC component is a userspace Go program (~3100 LOC), integrated with systemd services. It uses AES-CTR with 256-bit keys for block encryption and HMAC-SHA1 for block authentication. Each block has a fresh random nonce, stored along with the block's HMAC in metadata stored internally on the SBC (e.g., microSD card). Metadata is cached in RAM and flushed periodically.
To avoid known-plaintext attacks and fingerprinting, the CC applies a keyed permutation to map host block addresses to different physical disk addresses, either via a custom fast permutation or a Thorp shuffle method. Ghost reads add dummy reads on sensitive blocks to hide access patterns.
The prototype runs sequential NBD (Network Block Device) requests from the host and processes them with cryptographic operations. The CC maintains a cryptographic configuration including keys, which can be stored internally or supplied externally (e.g., via initial writes or removable media).
Evaluation was conducted on a testbed with a 12th Gen Intel host and an Orange Pi SBC linked to a 480GB Kingston SSD. Benchmarks FIO and Filebench measured raw I/O performance and realistic file system workloads, comparing native disk access, the CC with and without address permutation and ghost reads. Key metrics included throughput and latency across sequential and random read/write workloads.
The authors report the performance impact caused by encryption, authentication, address permutation, and ghost reads, noting significant but acceptable overheads for typical use cases. They also discuss security properties and mitigations against malicious disk firmware and replay attacks.
The paper does not appear to provide public code or fully reproducible artifacts beyond the prototype description. Some implementation details such as exact hyperparameters in HMAC and block size are given; others such as detailed timing breakdowns are limited. Overall, the methodology strongly integrates practical system design with threat modeling and empirical benchmarking.
Technical innovations
- Use of a commodity Linux-based SBC with USB OTG as an inline cryptographic intermediary providing fully authenticated disk encryption transparently to the host.
- Storage of encryption metadata (nonces and HMACs) on the SBC internal storage rather than the disk, enabling use of standard USB disks without modifying headers and reducing cryptanalytic attack surfaces.
- Incorporation of keyed block address permutation (including a Thorp shuffle) to obfuscate logical to physical block mapping and mitigate known-plaintext fingerprinting.
- Ghost reads technique performing deterministic dummy reads on sensitive blocks to prevent timing and address correlation attacks on known disk metadata blocks.
Baselines vs proposed
- Native direct USB SSD access: baseline throughput and latency vs CC-enabled encrypted access showing measured overheads (exact numbers not provided in excerpt).
- CC with no address permutation or ghost reads: baseline encrypted performance vs CC with permutation (performance penalty due to permutation).
- CC with permutation: throughput decreases by up to 10-40% depending on permutation method (Thorp shuffle 40x slower than custom method).
- CC with ghost reads enabled: further performance overhead due to additional dummy block reads; exact values unspecified but noted as substantial.
Figures from the paper
Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.12716.
Fig 1: Architecture of the system.
Fig 2: The Orange Pi board over the external USB drive used in the
Limitations
- The prototype implementation processes NBD requests sequentially, potentially limiting throughput compared to parallelized systems.
- The authentication uses HMAC-SHA1, which is deprecated for cryptographic security, though adequate for prototype demonstration; modern algorithms like HMAC-SHA256 would improve security.
- Performance overhead induced by address permutation and ghost reads may be excessive for high-performance or latency-sensitive environments.
- The CC device is assumed fully trusted and resistant to hardware tampering; attacks on the SBC hardware or firmware are out of scope.
- No explicit evaluation of resistance against physical side-channels, advanced adversaries subverting USB communication, or secure key injection protocols.
- Key management relies on external provisioning with limited discussion of usability or integration with multi-factor authentication schemes.
- The metadata storage requirement (~4GB for 480GB disk) could be prohibitive for very large disks or embedded devices with limited local storage.
- The paper does not provide open-source code or datasets, restricting reproducibility.
Open questions / follow-ons
- How would the CC perform in multi-host or multi-session scenarios with concurrent accesses and caching?
- What are the security implications and performance impacts of using more modern authenticated encryption schemes like AES-GCM or ChaCha20-Poly1305?
- Can hardware protections such as TPM or secure enclaves be integrated to protect keys and enable secure boot in the CC?
- How can the ghost reads and address permutation mechanisms be dynamically adapted based on observed host OS behavior to optimize security/performance tradeoffs?
Why it matters for bot defense
Although this work is focused on full disk encryption and not directly on bot detection or CAPTCHA mechanisms, some principles are relevant to bot-defense practitioners seeking hardware-anchored cryptographic guarantees. The CC demonstrates how generic commodity hardware with open-source software can interpose cryptographic operations transparently, without host modification. The use of keyed address permutations and dummy operations to obscure access patterns could inspire similar obfuscation or anti-fingerprinting techniques in bot detection or challenge-response systems. Moreover, the separation of encryption functionality from the host OS enhances auditability and reduces attack surface, a desirable property in security-sensitive contexts including bot defense. However, the performance costs and hardware assumptions must be carefully considered if porting similar designs to low-latency or resource-constrained environments typical for CAPTCHA user interactions.
Cite
@article{arxiv2607_12716,
title={ Auditable and Transparent Fully Authenticated Disk Encryption via USB Storage Interposition },
author={ Enrique Soriano-Salvador and Gorka Guardiola Múzquiz },
journal={arXiv preprint arXiv:2607.12716},
year={ 2026 },
url={https://arxiv.org/abs/2607.12716}
}