

FIPS 140-2 Level 2 Certified USB Memory Stick Cracked - yan
http://www.schneier.com/blog/archives/2010/01/fips_140-2_leve.html

======
rdtsc
> ... 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.

~~~
pieter
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.

------
ShabbyDoo
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?

~~~
iuguy
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/>

~~~
ajross
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.

------
tibbon
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.

~~~
lonestar
> 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.

