Hardware Encryption on USB Drives and Disks: How to Tell If It’s Real

⏱️ Reading time: 15 min

Lenovo was selling a USB flash drive with a fingerprint sensor advertised as encrypted. A subsequent teardown, documented in a Reddit thread, showed that inside there was nothing more than a generic microSD card: no cryptographic chip, no AES engine, nothing encrypting a single byte. The biometric sensor merely unlocked a Windows application; the drive, read directly with any card reader, handed over the files in plain text.

📑 En este artículo

1. TL;DR
2. What Is Hardware Encryption?
3. Why It Matters
4. How It Works Under the Hood
5. How to Verify It in Practice
   1. 1. Check the ATA Security Feature Set with hdparm
   2. 2. Confirm TCG Opal with sedutil-cli
   3. 3. Verify the FIPS Certificate in NIST’s CMVP
6. Real-World Use Cases
7. Common Mistakes and Best Practices
8. Comparison with Alternatives
9. Going Deeper
10. Frequently Asked Questions
    1. Is a USB drive’s hardware encryption always real if it says AES-256 on the box?
    2. What’s the difference between a self-encrypting drive and software encryption like VeraCrypt?
    3. How do I check if my disk supports TCG Opal?
    4. Does a fingerprint sensor replace a strong password?
    5. What does it mean for a cryptographic module to have FIPS level 3 validation?
    6. What exactly happened with Lenovo’s fingerprint USB drive?
11. References

This case isn’t an isolated bug from one manufacturer. It’s a symptom of an entire market where the word ‘encrypted’ appears on the box without any verifiable property behind it. This article explains what makes hardware encryption real, which standards certify it, and how to check it on any USB drive or external disk before trusting it with sensitive data.

TL;DR

• Real hardware encryption requires a dedicated AES chip that encrypts data before it reaches the flash memory.
• A fingerprint sensor that only unlocks a Windows app encrypts nothing: the memory remains readable in any card reader.
• FIPS 140-2 or FIPS 140-3 validated in NIST’s CMVP registry is the only verifiable proof of a real cryptographic module.
• TCG Opal defines how a self-encrypting SSD protects the data key without exposing it to the operating system.
• Commands like hdparm -I and sedutil-cli –scan reveal whether a disk supports and has hardware encryption enabled.

What Is Hardware Encryption?

Hardware encryption is the technique in which a dedicated chip inside a disk or USB drive’s controller encrypts and decrypts every byte with AES before writing it to or reading it from flash memory, without the operating system or any program intervening in the process or having direct access to the key.

The difference from software encryption (BitLocker in standard mode, VeraCrypt, LUKS) lies in where the key and the computation live. With software encryption, the operating system loads the key into RAM and uses the main processor to encrypt each block. On a genuine self-encrypting drive, the key lives inside the controller, and not even a memory dump of the machine exposes it.

A fingerprint sensor, on its own, says nothing about where the encryption happens. It can be the key to legitimate encryption, as in a certified drive, or it can be merely the trigger for an app’s login window, as in Lenovo’s case. The fingerprint identifies the person, but it says nothing about what happens to the data afterward.

Why It Matters

The risk isn’t just losing a file. A company that buys 500 ‘encrypted’ USB drives for its sales team and trusts that label is exposing customer data under a false sense of regulatory compliance. If the device gets lost and it never actually encrypted anything, any regulatory framework that exempts encrypted equipment from breach notification no longer applies, leaving the company exposed to a breach notification it thought it had avoided.

The fingerprint sensor isn’t a security measure: it’s a decorative lock on top of a drive with no real protection, when the manufacturer never implemented genuine hardware encryption.

This isn’t exclusive to cheap flash drives. In the past, academic research on commercial SSDs advertising hardware encryption found flawed implementations that allowed bypassing the key without knowing the password, which led Microsoft to stop trusting by default the hardware encryption reported by the drive itself to protect BitLocker volumes. The underlying problem is always the same: a claim with no independent verification.

The problem repeats outside low-cost USB drives: external disks, portable SSDs, and even some home NAS devices use the word ‘encrypted’ on the packaging without ever publishing a standard, a verifiable algorithm, or a certification number. The only way to know if there’s anything real behind it is to ask about the standard, not the adjective.

How It Works Under the Hood

A self-encrypting drive (SED) separates two keys. The Media Encryption Key (MEK) is the one that actually encrypts every data block with AES, almost always in XTS mode. That key is generated once, inside the chip, and never leaves it.

The second key is the Key Encryption Key (KEK), derived from the PIN, the password, or, in well-designed biometric devices, from a secret that the fingerprint sensor releases after verifying identity. The KEK doesn’t encrypt the data: it encrypts the MEK, which is stored in a reserved area of the disk. Without the correct KEK, the MEK is still there, but unusable.

This separation is what enables instant cryptographic erasure: discarding the MEK, without touching a single bit of the actual data, renders all the content unreadable in milliseconds, because no key capable of decrypting it exists anymore. It’s the mechanism behind features like ‘secure erase’ on enterprise SSDs, and the reason a multi-terabyte drive can be securely decommissioned in seconds.

The standard that defines how these pieces should behave in an SSD or HDD is TCG Opal, published by the Trusted Computing Group. USB drives don’t necessarily follow Opal, originally designed for SATA and NVMe, but serious ones document an equivalent scheme: a controller with an AES engine, a KEK derived from the PIN or fingerprint, and an MEK that never crosses the USB bus unencrypted.

flowchart TD
    A["User's fingerprint"] --> B{"What does the sensor unlock?"}
    B -->|"Only a Windows app"| C["The app displays the files"]
    C --> D[("Unencrypted flash memory")]
    B -->|"Derives the controller's key"| E["Controller's AES chip"]
    E --> F[("Flash memory encrypted with AES-XTS")]

Lenovo’s drive had none of this. There was no MEK, no KEK, no AES engine. There was a standard microSD card, the kind sold loose in any store, behind a fingerprint reader connected only to the desktop app’s logic.

How to Verify It in Practice

Before trusting the label on a USB drive or external disk, there are three concrete checks you can run without disassembling anything.

1. Check the ATA Security Feature Set with hdparm

On Linux, install hdparm (sudo apt install hdparm on Debian or Ubuntu, sudo dnf install hdparm on Fedora) and query the disk’s security block:

sudo hdparm -I /dev/sdb

A disk with the ATA Security feature set enabled shows something like this in the output:

Security: 
	Master password revision code = 65534
		supported
		enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	2min for SECURITY ERASE UNIT.

If the block says ‘not supported’ or doesn’t appear at all, the disk doesn’t implement the ATA Security feature set. That’s normal for most simple USB drives and isn’t, by itself, proof of fraud, but combined with the absence of any other technical documentation, it’s the first warning sign.

2. Confirm TCG Opal with sedutil-cli

For SSDs and self-encrypting drives that claim TCG Opal compliance, the Drive Trust Alliance maintains sedutil-cli, a command-line tool that isn’t packaged in every repository, so the safest route is to build it from its official GitHub repository or install the package if your distribution offers it. The basic scan is:

sudo sedutil-cli --scan

The command lists every connected disk alongside an indicator of the detected Opal support level, for example 2 for Opal 2.0. A dash in that column means the disk doesn’t implement Opal, regardless of what the packaging says.

3. Verify the FIPS Certificate in NIST’s CMVP

When a manufacturer advertises FIPS 140-2 or FIPS 140-3, a public certificate number has to exist. Look it up in NIST’s Cryptographic Module Validation Program: it lists the module name, the manufacturer, and the validated security level, from 1 to 4. If the exact model isn’t on that list, the ‘FIPS’ on the box is just marketing, even if the internal algorithm is genuine AES.

sequenceDiagram
    participant U as User
    participant H as Host
    participant C as Disk controller
    U->>H: enters PIN or fingerprint
    H->>C: sends authentication credential
    C->>C: derives the Key Encryption Key
    C->>C: unlocks the Media Encryption Key
    C-->>H: decrypted data in real time
    Note over C: the key never leaves the chip

On Windows, manage-bde -status C: shows whether BitLocker is using hardware encryption (eDrive) or falling back to software because the disk doesn’t support it. On macOS, diskutil info doesn’t distinguish hardware from software on third-party external disks, so for those devices it’s better to rely directly on the FIPS certificate published by the manufacturer.

Real-World Use Cases

Companies that handle regulated data (healthcare, finance, government, defense) typically require by contract that any corporate USB drive have validated FIPS 140-2 level 3. Lines like Apricorn Aegis Secure Key, iStorage datAshur PRO, or Kingston IronKey publish their certificate number and exact level in their documentation, precisely because their customers will verify it before signing the purchase.

⚠️ Heads up: Cryptographic erasure on a self-encrypting drive destroys the key in milliseconds and renders all data unreadable, but that guarantee only exists if the encryption was real by design: on a drive like Lenovo’s, there’s no key to erase.

In healthcare, losing a USB drive with patient records that lacks real encryption can trigger the obligation to notify every affected patient. Some regulatory frameworks reduce that obligation when the device had certified encryption, so the certificate isn’t a bureaucratic detail: it’s what decides whether thousands of notification letters need to go out.

Outside the corporate world, the simplest use case is anyone traveling with sensitive data (contracts, personal medical records, access credentials) on a USB drive. For that use, a certified self-encrypting drive justifies its premium over a generic flash drive with an ‘AES-256’ sticker and no backing.

Common Mistakes and Best Practices

Confusing the algorithm with the implementation is the most common mistake. AES-256 is a public, free algorithm: anyone can print ‘AES-256’ on a box without that implying the chip inside actually runs it, that the key is protected, or that the biometric sensor has anything to do with the encryption.

Assuming that anything with a fingerprint reader is more secure than a password is another mistake. A cheap biometric sensor with no cryptographic engine is, in practice, weaker than a long password: there’s no way to ‘change’ a compromised fingerprint, and in Lenovo’s case it wasn’t even protecting anything.

The ATA Security feature set, older than TCG Opal, has a known history of factory master passwords that some manufacturers never rotated or documented how to rotate, which in certain older models allowed unlocking the disk without the legitimate user’s PIN. That’s why modern implementations migrated to TCG Opal, which doesn’t depend on a universal manufacturer master password.

Repair and teardown communities, like the one that exposed the Lenovo case on Reddit, end up being the real quality control for this market: checking a teardown video or thread for the exact model before buying is worth more than reading the product description.

Best practice: always ask for the FIPS certificate number before buying, not after. A serious manufacturer has it printed on the product datasheet, not hidden in a support email.

Comparison with Alternatives

Not everything sold as ‘encryption’ sits at the same trust level. The table below ranks the three real categories that exist in the USB and external disk market.

flowchart TD
    A["Device advertises encryption"] --> B{"Does it have a verifiable FIPS certificate number?"}
    B -->|"Yes, it's in CMVP"| C["Validated hardware encryption"]
    B -->|"No, or not published"| D{"Does it support TCG Opal or ATA Security?"}
    D -->|"Yes, confirmed with hdparm or sedutil-cli"| E["Likely hardware encryption, uncertified"]
    D -->|"No, just an app or biometric sensor"| F["Marketing encryption: don't trust it"]

The middle row is the most common and the most ambiguous: many decent brand-name flash drives fall there. They’re not a scam like the Lenovo case, but they don’t offer the audited guarantee of a FIPS module either. And there’s a scenario where even the top row isn’t the right fit: if you need to sync the same encrypted container across Windows, macOS, and Linux without depending on a physical sensor that can fail or a recovery PIN with limited attempts, a software container like VeraCrypt is still more practical than a self-encrypting drive tied to a single biometric reader.

Going Deeper

AES-XTS, the mode used by almost all self-encrypting drives, was designed specifically for disks: it encrypts each sector independently so that a single-bit change in the plaintext doesn’t affect neighboring sectors, something necessary when storage is accessed in fixed blocks rather than as a continuous stream.

💭 Key point: The separation between MEK and KEK is what makes it possible to change a self-encrypting drive’s PIN in seconds: only the MEK, a few bytes, gets re-encrypted, never the full data, no matter how many terabytes the disk holds.

FIPS 140-2 and 140-3 security levels, from 1 to 4, don’t measure the algorithm, but the physical implementation: resistance to hardware tampering, key erasure upon attempted opening, quality of the random number generator. A level 3 module, the most common in corporate USB drives, requires physical evidence of tampering and intrusion-response mechanisms.

The Trusted Computing Group itself documents Opal 2.0 with explicit states for the drive: Locked, Unlocked, Frozen, and an attempt counter (Try Limit) that, once exhausted, can lock the disk until a reboot or force a cryptographic erasure, depending on how the administrator configures it. None of this exists on a device that, like Lenovo’s, never implemented the standard.

One real limitation worth clarifying: even a perfectly implemented hardware encryption protects nothing if the disk is left unlocked and connected. Encryption defends against the loss or theft of a powered-off device, not against someone using it while it’s unlocked. That’s the job of other security layers, not the AES chip.

Your next step: plug in an external disk or USB drive you have on hand, run sudo hdparm -I /dev/sdX, and check whether the Security block shows as supported before trusting the word ‘encrypted’ on any box.

Frequently Asked Questions

Is a USB drive’s hardware encryption always real if it says AES-256 on the box?

No. AES-256 describes a public algorithm, not a certification. The only thing that confirms a real, audited implementation is a FIPS 140-2 or FIPS 140-3 certificate number verifiable in NIST’s CMVP.

What’s the difference between a self-encrypting drive and software encryption like VeraCrypt?

VeraCrypt and LUKS encrypt using the machine’s processor and keep the key in the system’s RAM while the volume is mounted. A self-encrypting drive does the work inside the disk’s own controller, and the key never reaches the host machine’s RAM.

How do I check if my disk supports TCG Opal?

With sedutil-cli --scan on Linux, or by asking the manufacturer directly about the supported Opal level, for example Opal 2.0. The absence of a technical answer is usually the answer.

Does a fingerprint sensor replace a strong password?

Only if that sensor actually derives or releases the controller’s Key Encryption Key. If it merely unlocks an application, as in Lenovo’s case, it replaces nothing: the drive remains exposed to anyone who reads it directly.

What does it mean for a cryptographic module to have FIPS level 3 validation?

It means that, beyond using the correct algorithm, the hardware was evaluated for physical resistance to tampering and for erasing its keys upon a detected opening attempt. It’s the level typically required by corporate and government contracts.

What exactly happened with Lenovo’s fingerprint USB drive?

According to the teardown documented on Reddit, the device advertised as encrypted turned out to be a generic microSD card with no cryptographic component at all, with a fingerprint reader that only controlled access to a desktop application.

References

• Reddit r/technology: thread documenting the teardown of Lenovo’s fingerprint USB drive.
• NIST, Cryptographic Module Validation Program (CMVP): official registry for verifying a FIPS 140-2 or 140-3 certificate number.
• Wikipedia, Self-encrypting drive: technical explanation of how self-encrypting drives (SEDs) work.
• Trusted Computing Group: organization that publishes the TCG Opal standard used in self-encrypting disks.
• hdparm: Linux utility used to query a disk’s ATA security features.

📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion

Featured image: Foto de Diogo Brandao en Unsplash