NIST Investigating Mass Flash Drive Vulnerability

Lucas123 writes with a followup to news we discussed earlier this week that the encryption on NIST-certified flash drives was cracked. "A number of leading manufacturers of encrypted flash drives have warned their customers of a security flaw uncovered by a German company. The devices in question use the AES 256-bit encryption algorithm and have been certified using the FIPS 140-2, but the flaw appears to circumvent the certification process by uncovering the password authentication code on host systems. The National Institute of Standards and Technology said it's investigating whether it needs to modify its standards to include password authentication software on host systems. Security specialist Bruce Schneier was blunt in his characterization of the flaw: 'It's a stupid crypto mistake and they screwed up and they should be rightfully embarrassed for making it.'"

Comments

Encryption algorithm's aren't the weak link

[Anonymous Coward]

Encryption algorithm's aren't the weak link, its the implementation. But most people just look at how big the key is not who implemented it.

Re:Encryption algorithm's aren't the weak link

[Anonymous Coward]

My understanding of these devices puts the analogy at:

A super solid, near uncrackable/breakable safe, but all models use the same 12345 passcode, and the owners cannot change this.

To make matters worse, the door of the safe has been mounted on a normal house door that only has a sign saying 'do not open if this is not yours'.

This way, the safe owners dont need to rember such a complex code as '12345', and you get all the security of the full safe. Unless a intruder happens to have a brain, then they will just open the house door that holds the safe door thus negating the entire system.

If anyone could design a worse system, they are truely rube goldberg masters.

Re:Encryption algorithm's aren't the weak link

[Anonymous Coward]

A slightly better analogy is the following:

A super solid uncrackable safe which has a 12345 passcode for all models. This safe however, has a removeable front panel door that covers the passcode entry input. This front panel has it's own combination input that can be user set, and when the user inputs the correct user set passcode, the front panel automatically inputs the 12345 into the underlying safe door.

So all is well and good until someone comes along and just removes the removeable front panel.

This isn't just an implementation flaw in the software from these companies, it is an overall design flaw with the devices. This cannot be fixed in software since the devices need the capability to process and verify the password themselves, which these devices apparently don't have.

Essentially, someone in management asked the question:

Hey Bob, is there a way we could make our security functionally useless while saving 25 cents per unit?

Unfortunately, they got an answer that they liked.

Re:If you want to encrypt your data

[MK_CSGuy]

I think simply implementing the breaking algorithm in your favorite language on your PC would be more convenient and also give results much faster ;-))

You are right of course:

Nevertheless the victor's 1.4 GHz laptop, running his own code, took less than a minute to find the settings for all 12 wheels... 240 times faster than Colossus. If you scale the CPU frequency by that factor, you get an equivalent clock of 5.8 MHz for Colossus. That is a remarkable speed for a computer built in 1944.

You still get massive geek cred. either way :)

Doesn't NIST have a clue?

[Gnavpot]

I really do not understand this part:
"The National Institute of Standards and Technology said it's investigating whether it needs to modify [CC] its standards to include password authentication software on host systems."

This has already been proven to be very unsafe hardware. The fact that you can access the data without using the original software and without knowing the user's password should leave no doubt. As long as you have some software which says "Open Sesame" in the same way as the original software, you will get access.

So why was this not discovered during the NIST certification process? And why do NIST state that they may need to approve the software too to protect against this?

It seems to me that NIST blames the software so they will not have to take blame for their faulty certification of the hardware.

Re:Doesn't NIST have a clue?

[Anonymous Coward]

NIST doesn't actually certify things as "secure", it makes very specific certification of particular tests that may or may not represent what you think of as "secure". It's only the marketing that makes you think that if the words "NIST", "Certified" and "Security" appear in the same sentence that someone has done a proper end-to-end review.

It's like the way that the auditors' certificate in financial reports makes people think that the auditor is guaranteeing that there cannot be any fraud in the company and that the company is a good investment - in fact neither of those things are true.

Re:Doesn't NIST have a clue?

[Jaime2]

So why was this not discovered during the NIST certification process?

Because the certification the hardware received only verifies that the algorithm strength is sufficient and that the device is hardened against physical tampering.

It seems to me that NIST blames the software so they will not have to take blame for their faulty certification of the hardware.

Nope, it seems that the NIST has recognized that the certification, as currently written, isn't sufficient and is looking into making it more robust. Had they audited the software, they would have discovered that the software-to-hardware interface is poorly designed and not granted the certification.

Best part of TFA

[dr2chase]

is how everything is carefully run through the make-nice factory. The memory chip makers ucked fup. NIST ucked fup. Yet, NIST cannot say, "whoa, we blew it, we have to fix that standard immediately" (else it will be completely worthless). No, they're organizing a committee to appoint a task force to propose revisions to the standard, pending who-knows-what. And even the guys who got it right, try to make nice with a handy excuse for how this came about -- "difficult to administer with all those different passwords". You set two passwords for each device, duh, and let either access the bits. Vendors provide them with a customer-specified admin password, or vendor supplies a chip initialization utility where customer may bake in an admin password.

Re:If you want to encrypt your data

[TubeSteak]

Standard AES-256 is actually just fine, problem with these devices is that the manufacturers screwed up the implementation *majorly* (as I understand it, use the same key for every device and depend on a usermode app to say GOOD_GUY/BAD_GUY to the hardware) - but that's covered elsewhere.

The fact that so many major companies have the same exact flaw in their product suggests (to me) that there is only one manufacturer and multiple vendors who just rebadged the item.

I think it's less likely that multiple companies independantly managed to screw up their products in exactly the same way.

Doing file security the wrong way

[Old Man Kensey]

Any flash drive whose "security" involves a required app running on the host system will not be suitable for cross-platform use even if the app is well-written. The only right way to do it is to encrypt the data written to the drive, using well-known secure encryption algorithms run on the host. And for that purpose a cheap, dumb drive works just as well as a super-expensive "secure, tamper-proof" drive.