Hacker News new | past | comments | ask | show | jobs | submit login

Litany of failures:

* Firmware protection in drives is almost uniformly broken, so that they can get code execution (through JTAG or through hacked firmware images) routinely. This is bad, but shouldn't be the end of the world, since in the drive encryption threat model you don't want to have to depend on the firmware anyways. But:

* Two Crucial SSDs encrypt the drive with a key unrelated to the password; the password check is enforced only with an "if" statement in the firmware code, which can be overridden.

* Another Crucial SSD uses PBKDF2 to derive keys, but then has a master override key, which is blank by default. It also has a multi-volume encryption interface (Opal) with slots for volume keys, all of which are populated whether they're in use or not, and if they're not in use, they're protected with an all-zeroes key that recovers the master key for the device.

* Two Samsung drives implement PBKDF2, but not in the default mode, which is "password is checked in an if statement, like the Crucial drive". Also, the wear-leveling logic in one of the drives doesn't zero out old copies of the master key, so that when you change your disk password (or set it for the first time), unprotected copies of the data encryption key are left in blocks on the device.

* The Samsung T3 portable drive uses the drive password in an "if" statement and is trivially unlocked through JTAG. Its successor, the T5, is no more cryptographically sound, but is simply harder to obtain code execution on.

People have strange ideas about what disk encryption is good for (in reality, full-disk encryption really only protects you from the situation where your powered-down, locked device is physically stolen from you and never recovered [if you get the drive back, you have to assume, at least from a cryptographic standpoint, that it's now malicious.])

But the net result of this work is that Samsung and Crucial couldn't even get that right. This paper is full of attacks where someone simply steals your drive and then unlocks it on their own. It's bananas.

Great summary. Ill also note FDE also lets you quickly erase a drive by zeroing out a key. That can either eliminate the need during disposal for HD overwriting and/or destruction. It can also help in situations where an attack is incoming and they want to avoid durress. That's why so-called Inline, Media Encryptors and Enclosures with Zeroize buttons were used in Defense sector a lot. Example I modeled some designs on was ViaSat's that NSA recommended:


Also has 2FA, a trusted path for PIN's, and emanation shielding. Being Type 1 means they focused hard on the RNG, algorithm implementations, firmware/protocol code, and error-handling code. Typical for high-assurance crypto. Just one of a few internal and external enclosures that do the job right due to security regulation for certain products. We can't buy them of course since they actually work and NSA uses them.

Then, unregulated vendors in private market are doing least they can for actual quality/security, doing most they can on marketing it, and making a killing with no or limited liability for preventable defects. Typical. I still maintain pretty much all of them are insecure and/or negligent until proven otherwise.

The high-assurance community selling to defense shows they couldve built better designs 10-20 years ago if they just followed standards, had a specialist for crypto, and hired some experienced breakers to check it. Peanuts for these big, companies' profits. Useful in protecting the IP that generates those profits, too. They still do this shit... Always will without better incentives and/or regulation...

> physically stolen from you and never recovered

... or taken out of service and scrapped/resold/otherwise leaves your control. Which all drives eventually will.

Are there regulations in any industry which require the name of software authors on binaries/products, or at least the name of someone who approved the security claims made by the device?

Absolutely not.

... but in this particular case, people used their e-mail addresses as PBKDF2 salts, so we do have some idea. ;-)

(Of course, blaming whatever engineer isn't useful.)

Buy drives with FIPS 140-2 certification. At least then you know a third party lab has reviewed the implementation.

It is almost definitely not the case that FIPS certification of any kind reliably informs you that a capable crypto engineer verified the implementation.

Respectfully, I'll need a citation on that.

Sure. Find any device crypto vulnerability, and check to see if the device was FIPS 140-2 certified. For instance, Infineon with their batshit RNG (the ROCA vulnerability).

Does your argument boil down to any review process that doesn’t catch 100% of problems is worthless? I don’t think anyone claims fips certification is always going to garuntee perfection but it’s better than nothing. It also stipulates things like tamper evident seals which would mitigate attacks that need jtag access to muck with firmware.

If someone lifted your drive - the thing FDE is supposed to protect against - tamper evident seals are not going to offer much in the way of mitigation.

that isn’t what the seals are for.

They keep the data USDA Grade A fresh.

So looking at the ROCA vulnerability, it looks like the vulnerability wwas with how the primes were generated, not with the correctness of the actual crypto algorithm. Fips typically certifies that the algorithm is correct, but it can't be faulted for bad primes.

So I'm still going to have to ask for an actual citation

Edit: I also didn't see where that device is Fips certified either

Fips typically certifies that the algorithm is correct, but it can't be faulted for bad primes

I think I rest my case.

How? I honestly don't follow your logic at all.

Treating a certification of algorithm correctness as a certification of a well engineered product is a poor choice, because many security critical things in the product are not considered in the certification.

That makes a lot of sense, thank you! I got the impression that the parent comment meant that the certification itself means nothing, hence my confusion.

I mean; a crypto certification that doesn't tell you very much about the effective security of the product doesn't provide very much value though, does it? All it tells me, is that someone thought it would increase their sales enough to justify the time and money; they may not have spent time and money to generate random numbers properly, and may just use 4 all the time; they could probably still get a fips cert, because it's out of the scope of the certification.

Pretty much, yep.

In this SSD case, if they only certified the algorithm then all the SSDs would be fine (probably). The encryption itself is probably good and wouldn't be easily broken if you only had access to the encrypted data. It's the key generation and usage outside of the algorithm that is broken in these drives.

If the algorithm is FIPS 140-2 compliant but the key-handling/checking fails best practices...

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact