Linux disk encryption and self-encrypting drives -- A case study on Opal2 drives security

Imagine your computer's hard drive is a high-tech bank vault. For years, we've protected the money inside (your data) by hiring a very careful guard (software encryption) who checks every single bag before it goes in or out. But recently, the vault manufacturers started building the guards into the vault door itself. These are called Self-Encrypting Drives (SEDs), specifically the Opal2 kind. The idea was simple: if the vault locks itself, it should be faster and safer, right?

Well, a team of curious detectives from Masaryk University decided to test this theory. They didn't just take the manufacturers' word for it; they grabbed 38 different "off-the-shelf" vaults from various brands, some brand new and some second-hand, and put them through a rigorous black-box stress test. They didn't know how the vaults were built inside; they just sent commands and watched what happened.

Here is what they found, and why it's a bit of a rollercoaster.

The "Magic Key" That Wasn't So Magic

The biggest surprise? Some of these "smart" vaults were actually playing tricks on the encryption.

Think of encryption like a secret code where every letter you write gets scrambled. To make sure the code is truly secure, the scrambler needs to use a unique "twist" for every single page of your diary. If you write the same sentence on page 1 and page 100, the scrambled version should look totally different.

The researchers found that on several drives (like some from Lenovo and Samsung), the vaults were getting lazy. They were using the same twist for multiple pages. It's like if a spy used the same secret hand-shake for every single agent they met. If an attacker saw the same pattern twice, they could guess what the secret message was, even without the key. In some cases, the drives were using a 4096-byte "block" size internally but pretending it was smaller, causing the "twist" to get reused in the second half of the block. It wasn't a total disaster, but it meant that if you changed your password, some old patterns might still be visible in the scrambled data.

The "Random Number" Generator That Wasn't Random

To lock the vault, you need a truly random key. Imagine trying to pick a winning lottery number. If the machine picking the numbers is broken and always picks "7, 14, 21," you're in trouble.

The Opal2 standard asks the drive to act as a random number generator. The researchers tested this by asking the drives to spit out 1 MB of random data and checking if the numbers were truly mixed up.

• The Result: Several drives failed miserably. Some drives (like certain Lenovo and Samsung models) were so predictable they were basically counting: "1, 2, 3... 32, 1, 2, 3..."
• The Verdict: The paper suggests that if you rely on the drive to generate your secret keys, you might be using a key that an attacker could guess. Because of this, the researchers decided not to use the drive's random generator for Linux encryption. Instead, they stick to the computer's own random generator, which is much more reliable.

The "Super User" Feature That Was Broken

There's a special feature called SUM (Single-User Mode). Think of it as a "Manager" and a "User" key. The Manager can set up the vault, but the User is the only one who can open it. The Manager shouldn't be able to peek inside the User's stuff.

The researchers tried to set this up on the drives. They found that while many drives said they supported this feature, the actual implementation was often broken. On some drives, the "Manager" could still unlock the "User's" data, or the switch between modes was so shaky that an attacker could interrupt the process and steal the data. Because of these glitches, the researchers found that out of 24 drives that claimed to support this "Super User" mode, only 14 actually worked correctly enough to be trusted.

The "Reset Button" Problem

Every vault has a master reset button called PSID (Physical Security Identification). It's a code printed on a sticker on the drive. If you forget your password, you can use this code to wipe the drive and start over.

The researchers found a few issues here:

1. Predictable Codes: On some drives (specifically a batch from Western Digital), the reset codes weren't truly random. They followed a pattern. If you knew the code for one drive, you could guess the code for another drive from the same batch just by trying a few numbers.
2. Forgotten Secrets: Many users don't realize this sticker code is a secret. People post photos of their drives online with the code clearly visible. If a hacker sees that photo and has remote access to your locked drive, they can wipe your data instantly.
3. Lenient Checkers: Some drives (like certain Micron models) were too nice. They accepted the reset code even if you added extra letters to the end of it. It's like a bouncer letting you in even if you say your name is "John Smith" when the list says "John." It's not a direct hack, but it shows the security engineering was sloppy.

The "Pyrite" Imposter

Before they even started testing, the team had to throw out 12 drives. Why? Because they were labeled as "Opal2" (the high-security version) but were actually Pyrite2. Pyrite2 is like a "Lite" version of the vault—it has a lock, but it doesn't actually encrypt the data inside. It's just a door that says "Keep Out" without any actual walls. The researchers had to filter these out to make sure they were testing real encryption.

The Good News: A New Tool for Linux

Despite all these wobbly vaults, the researchers didn't just say "it's broken" and walk away. They built a new set of tools for Linux (the operating system used by many servers and privacy-focused computers).

They created a way to automatically check if a drive is behaving correctly before letting you use it. If a drive tries to use a bad random number generator or has a broken "Super User" mode, the new software will spot it and switch to a safer, standard mode automatically. They also released their "Opal Test Suite" as an open-source tool, so anyone can check their own drives.

The Bottom Line

The paper concludes that while hardware encryption (SEDs) is a great idea, the current reality is messy. The manufacturers are often cutting corners, implementing features incorrectly, or leaving security holes.

• What they ruled out: They proved that you cannot blindly trust the drive's random number generator or its "Super User" mode without checking first.
• What they proved: They measured specific failures in 38 drives, showing that firmware bugs are real and common.
• The takeaway: Hardware encryption isn't a magic shield yet. It's a useful layer, but it needs to be paired with smart software (like the new Linux tools they built) to catch the mistakes the hardware makes. Until manufacturers fix these firmware issues, the safest bet is to treat the hardware as a helper, not the sole guardian of your secrets.