Slashdot Mirror
Encryption Cracked On NIST-Certified Flash Drives
An anonymous reader writes "USB Flash drives with hardware based AES 256-bit encryption manufactured by Kingston, SanDisk and Verbatim have reportedly been cracked by security firm SySS. These drives are advertised to meet security standards suitable for use with sensitive US Government data (unclassified, of course) as emphasized by the FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology (NIST). It looks likes the Windows-based password entry program always sends the same character string to the drive after performing various crypto operations."
One weakness in the entire crypto-system can bring the whole thing down.
Looks like they forgot the ROT13
These aren't disks, they're USB thumb drives. The folks who "cracked" it just figured out a way to bypass the password and send a specific string that ALL of these devices use to access the data on these USB thumb drives. This seems to be endemic to these things. The info isn't encrypted, it's just locked with a password.
Didn't you even read TFS?
The moral of the story is to buy a normal flash drive and encrypt it using Truecrypt, then you are not at the whims of Kingston/SanDisk/Verbatim, keeping their closed source, windows only software patched.
The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.
First, here's the NIST list of approved 140-1 and 140-2 modules.
Note that they approve the module and not the access software. The flaw is in the access software. Therefore, 140-2 compliance or approval isn't proof that your data is safe. It just means that some approved form of encryption is implemented by the crypto module. It appears that the modules in question were given some form of TEMPEST examination as well, but once again, that means nothing in terms of the access software.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
The Ironkey should not be affected. It uses a different approach: first of all, the data on the drive is really encrypted, the drive is not only "locked" with a password. Secondly and most important, there's no validation of the password happening outside the drive (i.e. on a windows/linux/mac application). The application only lets you input your password, which is then validated by the drive itself via a ROM routine.
Cosplayers.net - The Cosplayers Network
If you set up Truecrypt in portable-mode on a USB key so it acts like these off-the-shelf keys, then it needs administrator privileges to work. That's a big problem for a lot of people.
I don't believe why any portable secure drive needs to or should trust its host computer. This is a particularly stupid implementation, with an obvious and blatant exploit. But the host computer could by definition be compromised, and could intercept or store / cache or misbehave generically with the password you enter to get in.
Put a thumb-key sized numeric or hex keypad on the device, and make the owner punch in the code on insertion into a host device. One could still physically break into and tap the keys somehow, if the device is stolen and then returned without the owner knowing, but the user interface moves to right next to the data...
What I got from the article was the following scenario:
1. Drive asks for a password
2. User enters a password
3a. The password is incorrect -> "DO NOT OPEN" message is sent to the drive
3b. The password is correct -> "OPEN" message is sent to the drive
4. User gains access to the drive
The "crackers" simply bypassed steps 1 and 2 and went straight to 3b. You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.
Actually, the way I read it, these drives all do use hardware crypto... But they use the SAME DAMN KEY. Authentication is handled in software.
Key management FAIL.
retrorocket.o not found, launch anyway?
This problem is only that of "closed source" and not one of "Windows only". It would be equally insecure on any OS.
John
If you were to check the flash drives partitioning, you'll see that it has two separate partitions. The section with encryption program is on the primary partition of the flash drive. When the program executes, you get access to the other partition.
Now I've mounted those drives under Linux by bypassing the login process. Instead of mounting sdc1 (assuming sdc is your encrypted flash drive), you mount sdc2. What I've learnt is that the drive isn't encrypted at all - nor password protected. If you can find a way to format the first partition, you pretty much kill the password protection that comes with the flash drive. The "protected" partition just becomes the default partition when the primary one is unavailable.
TrueCrypt or any other data encryption method is the right way to actually secure your data
Face your daemons!
"12345"
That's the stupidest combination I've ever heard in my life! The kind of thing an idiot would have on his luggage!
Portable Truecrypt has problems. The user will import their private key or at least have it somewhere they can get to it or use conventional cryptography. So there's a lot of security vulnerabilities right there. Oh, forgot to delete your private key? Now Im cracking the conventional encryption that protects it. TrueCrypt portable requierd admin privs:
The idea with these drives is that the app can be run from the drive itself, so no extra software or training is needed. No key management. So that really just leaves us conventional cryptography, not public/private key. The problem of having security on your USB drive that gets plugged into various computers that you might not have control over and may be running trojans is tough to solve. Application level encryption is probably the best way to go but it requires standard installs and trust of the host computer.
Youre better off just carrying a netbook or other trusted security device with an encrypted drive and sharing the files via conventional methods with the host without giving the host all your data - email, ftp, web, plaintext transfers, etc.
Correct stuff was already explained above by someone else:
http://it.slashdot.org/comments.pl?sid=1498504&cid=30658760
The flaw is in the hardware, at least according to TFA. It works like this:
1) SW: OK, let's decrypt the drive, HW, you gives me dat0rz ... OK pass hashes to correct value
2) HW: not so fast SW, you have to confirm if I should give the dat0rz
3) SW: Oh, right silly me, you give me challenge hash then
4) HW: Here u go
5) SW: kthx
6) SW: User, I need pass to verify challenge hash
7) US: here's pass, now give me dat0rz!
8) SW: Working
9) SW: Hey, HW! Guess what? I got correct pass, so it's cool for you to give me dat0rz!
10) HW: cool, here u go!
What these guys did was just make some rogueware
1) RW: OK, let's decrypt the drive, HW, you gives me dat0rz
2) HW: not so fast SW, you have to confirm if I should give the dat0rz
3) RW: Hey, HW! Guess what? I got correct pass, so it's cool for you to give me dat0rz!
4) HW: cool, here u go!
So yes, the problem is that the hardware is not conducting the challenge itself, but depending on software to do it. Also mentioned above, some clueless people were saying that the data on the drive isn't hardware encrypted. No, I assure (again, according to TFA) you, the data is hardware encrypted. But if it's using this scheme, then it isn't encrypted with the hashed key of your password. Your password is only hashed and stored on the drive, but the data must use the same key(set) on all drives. Even without the crappy auth design, this would still be a problem because it dramatically reduces the keyspace if you have physical access. This is most definitely a hardware flaw.
Next class, we're going to go over substitution ciphers! Remember, you have a pop quiz tomorrow on SQL parameterization and validation!
As someone who works in the secure flash drive space, maybe I can shed a little light on some questions/comments I see above..
First and foremost the vulnerability described in this article is related to only the secure flash drives stated in TFA. There are several others available that do not have this vulnerability because instead of password matching in software, they match in Hardware of Firmware, run on the drive itself. Are there others within the industry that may be susceptible? Probably, but all secure flash drives certainly are not. Look to only use drives with password matching done on-chip (HW/FW).
How could a FIPS 140-2 certified flash drive have this vulnerability? Well FIPS is great to prove you use certified encryption algorithms, authentication methods, and so on, but FIPS does not certify the whole system. This is one of those very important security areas that fall outside of the FIPS umbrella. In the future look for additional certifications that will encompass the entire system rather than just the encryption like FIPS..
Why not just use TrueCrypt?? TrueCrypt is a great product, there is no doubt. But at its core, TrueCrypt is a software encryption container for your data. There are some inherent shortcomings with software encryption on USB flash drives.
1. Performance is sacrificed since your PC CPU needs to perform all security operations in software, rather than on the hardware of the flash drive.
2. Though it may work well for consumers that *want* to have their data secure, TrueCrypt would be a nightmare in an enterprise setting. Users could format the drive, or store files outside of the encrypted partition just to make things easier. This is not possible on secure flash drives with forced data encryption via hardware. with these drives an Admin knows that if he sees a drive by company X, that the data on it must be secure. Just to name a couple..
I hope this is helpful to some.
There should be nothing preventing you from putting a Truecrypt volume on the FIPS140-2 compliant drive. It would be similar to having a hidden truecrypt volume within another encrypted volume. So this would satisfy the 'pointy hair boss' with compliance to FIPS140-2 while keeping data secure from the 'crack' mentioned in the article.
IronKey D200 and S200 models are validated to the much more demanding FIPS 140-2 Level 3. The products that are the subject of this hack are validated to Level 2. They are all in fact manufactured by SanDisk. Previous authors are correct, their architecture has serious design flaws. They are relying on the host PC to do password verification, and essentially using a static code to tell the device to unlock. Basically it's a back door to all of those affected SanDisk, Kingston and Verbatim devices. I will be posting an FAQ later today on the https://www.ironkey.com/ website describing the flaws and how IronKey's architecture does not have these issues. IronKey validates all passwords in hardware. We have password replay prevention and encrypted USB command channels. We also use a hash of the password to decrypt the data AES key, so it's cryptographically impossible to unlock an IronKey without the password. Finally, IronKeys store encryption keys and brute force counters in a hardened CryptoChip. The SanDisk, Kingston and Verbatim products store them in Flash memory, which isn't even part of their FIPS 140-2 security policy. Dave
Having spent 8 years in the Naval Security Group working with NSA and another 10 years as a defense contractor working with NSA on secure communications, I can tell you for a fact that if you don't have physical security, you don't have security. Period.