SSD Hardware Encryption Failures

When "hardware encryption" means "no encryption at all"

In November 2018, researchers at Radboud University published findings that should have ended careers: Samsung and Crucial SSDs - representing roughly half the consumer SSD market - had "hardware encryption" that could be bypassed by pressing Enter. The master password was an empty string. The encryption key and user password weren't connected. Unencrypted copies of keys sat in recoverable flash cells. These weren't bugs. They were architectural failures. [1]

The research, titled "Self-encrypting deception: weaknesses in the encryption of solid state drives," revealed that self-encrypting drives (SEDs) from major manufacturers provided what security researchers diplomatically called "no protection at all" in many configurations. Worse, Windows BitLocker had been trusting these drives by default - if your SSD claimed to support hardware encryption, BitLocker would disable its own software encryption and defer to the drive.

Millions of users thought their data was encrypted. It wasn't.

What Self-Encrypting Drives Promise

Self-encrypting drives (SEDs) are supposed to solve the performance problem with disk encryption. Software encryption (BitLocker, FileVault, LUKS) uses your CPU to encrypt and decrypt every read and write. This adds overhead - noticeable on older hardware, measurable even on new systems.

Hardware encryption moves this work to a dedicated chip on the SSD itself. The drive encrypts data before writing to flash and decrypts it when reading. Your CPU never touches the plaintext. Performance is identical to an unencrypted drive. [2]

The implementations follow standards:

  • ATA Security: Password-based access control built into the SATA specification
  • TCG Opal: Trusted Computing Group's specification for self-encrypting storage
  • IEEE 1667: Standard for storage device authentication

On paper, it's elegant. The drive handles encryption transparently. Performance stays high. The encryption key never leaves the drive's hardware. What could go wrong?

Everything Went Wrong

Carlo Meijer and Bernard van Gastel at Radboud University reverse-engineered firmware from Samsung and Crucial SSDs. What they found was catastrophic. [1]

CVE-2018-12037: Password and Key Not Linked

In a proper encryption system, your password derives the encryption key. Know the password, you can decrypt. Don't know the password, you can't.

Multiple drives violated this basic principle. The user password and the data encryption key (DEK) were stored separately, with no cryptographic binding between them. The password checked a flag; the DEK encrypted the data. They had nothing to do with each other. [3]

Attack: Connect to the drive's debug interface (JTAG). Modify the password validation routine in RAM to always return "success." Enter any password. Access all data. The encryption key was right there on the drive, completely separate from whatever password you thought protected it.

CVE-2018-12038: Keys Recoverable from Flash

SSDs use wear leveling - spreading writes across all flash cells to extend drive life. When you "overwrite" data, the SSD often writes to a new location and marks the old location as free (to be erased later). [3]

Samsung's 840 EVO stored encryption keys in flash. When keys were "updated," wear leveling meant old copies remained in cells marked as free but not yet erased. Physical access to the flash chips revealed historical key material.

Even if the current encryption implementation worked perfectly, past keys were recoverable from the drive's flash storage.

Empty Master Passwords

The Crucial MX300 shipped with a master password implementation where the default was... nothing. An empty string. If users didn't explicitly set a master password (and why would they know to?), anyone with physical access could unlock the drive by entering a blank password. [1]

Press Enter. Drive unlocked. "Encryption" defeated.

Single DEK for Entire Drive

Some implementations used a single data encryption key for the entire drive. This simplifies implementation but weakens security - compromise one sector's key and you've compromised everything. Proper implementations use separate keys for different regions.

Low-Entropy Key Generation

Encryption keys must be random. Really random. Hardware random number generators exist for exactly this purpose. Some drives used weak or predictable key generation, producing keys that could be guessed or derived rather than brute-forced. [1]

Affected Drives

The researchers examined drives from Samsung and Crucial (Micron). Their findings: [1]

Critical Security Issues (Both ATA and TCG Opal)

  • Crucial MX100
  • Crucial MX200
  • Samsung 850 EVO
  • Samsung T3 Portable
  • Samsung T5 Portable

Issues in Specific Modes

  • Samsung 840 EVO: Vulnerable in "ATA high" mode; also affected by CVE-2018-12038 (key recovery from wear leveling)
  • Crucial MX300: Empty master password

Samsung and Crucial together represented approximately 60% of SSDs sold between 2014 and 2018. The affected models were mainstream consumer drives - the ones millions of people bought for laptops and desktops.

The BitLocker Problem

Microsoft's BitLocker made this worse. By default, BitLocker detected if a drive advertised hardware encryption support. If it did, BitLocker trusted the drive and disabled its own software encryption. [4]

The logic seemed reasonable: Why do encryption twice? Hardware encryption is faster. If the drive claims to handle it, let the drive handle it.

The result: Users who enabled BitLocker - specifically to encrypt their drives - ended up with drives "protected" only by the flawed hardware implementations. BitLocker's tested, audited, working software encryption was bypassed in favor of proprietary firmware that couldn't do the job.

Microsoft's response after the Radboud disclosure: a Group Policy setting to force software encryption even when hardware encryption is available. But this required administrators to know about the issue and manually change the default.

Why This Happened

The researchers' conclusion was blunt: "Correctly implementing disk encryption is hard and the consequences of making mistakes are often catastrophic." [1]

Several factors contributed:

Proprietary, Unaudited Code

SSD firmware is closed source. No independent security review. No external audit. The only people who examined this code before Radboud were the manufacturers themselves - and clearly, they missed fundamental flaws.

Specification vs. Implementation

TCG Opal and ATA Security specify what features a drive should have. They don't specify how to implement them correctly. Manufacturers had latitude to cut corners, and they did.

No Verification Mechanism

When BitLocker asked a drive "do you support hardware encryption?", it received a yes/no answer. There was no way to verify that the encryption actually worked. The drive said "trust me." BitLocker trusted.

Security Theater Economics

Implementing encryption correctly costs engineering time. Implementing encryption that passes checkbox compliance costs less. The drives could claim "hardware AES-256 encryption" in marketing materials. Whether it worked was another question.

Responsible Disclosure

Meijer and van Gastel followed responsible disclosure protocols. They contacted the Netherlands' National Cyber Security Center (NCSC) in early 2018. NCSC coordinated with Microsoft, Samsung, Crucial, and Western Digital/SanDisk. [1]

The public disclosure came November 5, 2018. By then:

  • Samsung had issued firmware updates for some affected models
  • Crucial/Micron acknowledged the issues
  • Microsoft published guidance on forcing software encryption
  • Dell and other OEMs published mitigation steps for enterprise customers

But firmware updates can't fix drives already in the field if users don't apply them. And many consumer drives never received patches at all.

Seagate's Response

Seagate claimed their self-encrypting drives weren't affected. Their statement: "All Seagate Secure™ TCG Enterprise SSC and TCG Opal SSC based SED and FIPS devices across all interfaces (SAS, SATA and NVMe) provide certified mitigations to the threats referenced in the research study." [5]

The key word is "certified" - Seagate's enterprise drives underwent FIPS validation, which includes security review. Consumer drives from other manufacturers faced no such requirement.

Lessons

Don't Trust Proprietary Security

Hardware encryption sounds sophisticated. Black-box firmware implementing classified algorithms on dedicated silicon. In practice, it meant unaudited code from manufacturers with no security expertise shipping drives that provided the illusion of protection.

Software encryption (LUKS, VeraCrypt, BitLocker in software mode) has been examined by cryptographers worldwide. The code is public. The implementations are tested. When bugs appear, they're found and fixed by a global community. Hardware encryption firmware gets reviewed by... whoever the manufacturer assigns to the project.

Verify, Don't Trust

BitLocker's mistake was trusting drive claims without verification. This is a common pattern: one component trusts another's assertions rather than verifying correctness. The solution is skepticism at every interface.

Defense in Depth

Even if hardware encryption worked perfectly, relying on a single layer is fragile. Software encryption on top of hardware encryption costs minimal performance and provides protection if either layer fails.

Current Status

Since 2018:

  • Microsoft: Changed BitLocker defaults in Windows 10 1903+ to prefer software encryption
  • Samsung: Released firmware updates; newer drives use revised implementations
  • Crucial: Acknowledged issues; published consumer guidance
  • Industry: Increased focus on SED security validation

However:

  • Old drives remain vulnerable unless firmware is updated
  • Many consumers never learned about the issue
  • Enterprise drives with FIPS certification were already better; the gap between consumer and enterprise widened
  • The fundamental problem - proprietary, unaudited security code - persists across the industry

What You Should Do

Use Software Encryption

Don't rely on SSD hardware encryption. Period. Use:

  • VeraCrypt: Open-source, cross-platform, audited. Can encrypt entire drives or create encrypted containers.
  • LUKS (Linux): Standard Linux disk encryption. Integrated with most distributions.
  • BitLocker (software mode): Force software encryption via Group Policy: Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Fixed/Removable Data Drives → Configure use of hardware-based encryption → Disabled
  • FileVault (macOS): Apple's implementation uses software encryption by default.

Check Your Current Setup

On Windows, check if BitLocker is using hardware or software encryption:

manage-bde -status C:

Look for "Encryption Method." If it says "Hardware Encryption" on an affected drive model, you have a problem.

Layer Your Defenses

For sensitive data, use file-level encryption (like VeraCrypt containers) in addition to full-disk encryption. Even if one layer fails, the other provides protection.

Assume Physical Access Means Compromise

If someone has physical access to your drive, assume they can eventually access the data. Encryption raises the bar; it doesn't guarantee protection. Sensitive data should be destroyed when no longer needed, not just "deleted."

The Broader Problem

SSD encryption failures are a specific example of a general pattern: proprietary security implementations fail because they're not subject to scrutiny. This same dynamic plays out in:

  • Intel Management Engine: Proprietary firmware with system access, multiple critical vulnerabilities
  • Baseband processors: Closed-source cellular modems with remote code execution bugs
  • Router firmware: Consumer routers with hardcoded credentials and unpatched vulnerabilities
  • IoT devices: "Smart" products with security as an afterthought

The pattern: marketing promises security, implementation fails to deliver, users trust marketing, and the gap between promised and actual security only becomes visible when researchers spend months reverse-engineering proprietary code.

The solution is consistent: prefer open, audited implementations over proprietary black boxes. When you can't avoid proprietary components, don't trust them as your only defense.

Related Articles

References

  1. Meijer, Carlo and van Gastel, Bernard. "Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)." IEEE Symposium on Security and Privacy (SP), 2019. ieee-security.org
  2. WinMagic. "SED Vulnerabilities - Weaknesses in the encryption of solid state drives (SSDs)." winmagic.com
  3. CERT/CC. "VU#395981 - Self-encrypting hard drives do not adequately protect data." kb.cert.org
  4. Bleeping Computer. "SSD vulnerability breaks (BitLocker) encryption." November 2018. bleepingcomputer.com
  5. Dell. "Self-Encrypting Drives Vulnerabilities (CVE-2018-12037 and CVE-2018-12038): Mitigation steps." dell.com