FIPS 140-2 Level 2 Certified USB Memory Stick Cracked | Hacker News Reader

FIPS 140-2 Level 2 Certified USB Memory Stick Cracked

schneier.com

24 pointsyan9 comments

> ... the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations -- and this is the case for _all_ USB Flash drives of this type. [emphasis mine]

Does that mean what I think it means -- the password is not actually used during encryption? Was it a deliberate back-door or an honest mistake?

I can imagine the commit comment for that "feature":

  [commit 24ebc...]
  Couldn't figure out how to parse and encode the password.
  Always send "123456" as the password.

May be after performing various crypto operations, the effect of the password gets cancelled out or something.

A lot of USB sticks with 'encryption' have serious flaws, similar to the fingerprint USB sticks. Most of them use encryption only to check if the password is correct; if it is, they send some kind of initialization string to the usb stick which activates the stick-side USB Mass Storage Device. The encryption really is only used for marketing purposes.

Wow! I was reading the comments on the blog posting, and the signal-to-noise ratio was shockingly low. I would have thought Schneier readers to be a bit more clueful.

It seems that using a security-less memory stick/usb drive/etc. with an open source cryptographic package might be one's best bet. What are some good options?

Use the open source and cross-platform TrueCrypt.

Don't trust that some company's Taiwanese sub-sub-vendor has any competency at software development.

Actually using software-based encryption is fraught with problems. What if the person you're sharing the disk with can't install the crypto software?

What if the person you're sharing with copies the crypto container off the disk whilst it's plugged in and uses a keystroke logger?

An ideal solution for sensitive data is something that does hardware encryption on chip, uses a read-only partition with a container application and provides two-factor authentication - and doesn't send a static hash over the USB channel.

I evaluated MXI's Stealth MXP a while back. There was a later firmware version that sent the hash over the USB channel but the version I reviewed was good - although I think they only make the bio in that series now and haven't evaluated the new Stealth M - http://www.mxisecurity.com/

To be fair: if the recipient can't access the data, that may be a problem but it's not a security failure. In general, applications that have strong security requirements are usually willing to deal with a little hassle to get it. The whole idea of doing the encryption on the drive was to reduce the hassle of making users do encryption. And it turned out to introduce a fatal bug.

I don't see how your other suggestions are going to provide any more more resistance against security bugs than this drive had. But being hardware solutions, I can guarantee that they will be much less verifiably secury -- thus making it much more likely they'll reach market before the flaw is discovered. Software is more robust in that sense.

Claim some level of security, and you've instantly become a target. Either given enough people poking at it intelligently, or a enough computers brute forcing it nearly anything can be cracked. Of course, when people do the cracking it often ends up showing some design flaws in the product.

> Either given enough people poking at it intelligently, or a enough computers brute forcing it nearly anything can be cracked.

That's technically true, but the time frame it takes to find an algorithmic weakness or complete a brute-force is the important factor here. It comes down to a question of how long your data needs to remain confidential.

As is usually the case, no cryptographic primitives were subverted to 'break' the USB stick. A somewhat silly implementation flaw is to blame.

Reply on news.ycombinator.com