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.
Can anyone explain to me why the disk manufacturers chose to reinvent the wheel, instead of using Truecrypt? As far as I know, Truecrypt encryption hasn't been broken yet.
Those who can, do. Those who can't, sue.
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.
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...
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
so all their usb drives use a stored key to encrypt the data ( let me guess, it's the same for all the usb sticks ), but the user does use a password, therefore thinking that the key is unique. Alas, the password just authorizes access to the stored secret key. Sounds like a scam to me, or a backdoor on purpose ( .. cough N cough S cough A ).
The flaw clearly is in the device! The access software is irrelevant because anyone can copy or modify such software. The device must protect the data regardless whether the access software has been compromised. If the FIPS approval does not consider this, then it's nothing more than a marketing gag.
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.
You're assuming your short production run / limited power / simple architecture / limited heat dissipation hardware is faster than running it in software on a commodity processor, which RAID card manufacturers have falsely been pushing for years (decades now?). Think about it, it implies a USB sized and USB powered gadget runs faster than the PC its plugged into.
Also assumes the limiter to overall system speed is processing the data. Feeding "a couple megs" to a multicore processor running "several gigs" is not going to saturate it... The processor is going to spend most of its time doing something else.
Not to say HW encryption isn't a good idea from a security standpoint.
Or if, in some crazy world, the drive is attached to something that is actually lower powered than the flash drive (maybe a data logger appliance or something) then it makes sense.
Or, if the add on device has a special ATX connector so it can suck down almost as much power as the CPU, like modern video cards, and is hyper parallelizable like a modern video card, then "doing it in dedicated HW" makes sense.
But in general, always a bad idea to replicate what the main processor already does, but badly or more slowly.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Read some of the other posts then. One Linux user says that if he plugs one of these drives in and simply mounts /dev/fdd2 he has full access to the data. It doesn't matter much how you implement the software on any OS when that's the security model.
John
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.
Note that they approve the module and not the access software. The flaw is in the access software.
As a programmer and hardware geek with a passing familiarity with crypto. It is quite clear what this device is doing (and what it is not doing). In fact the design issue here is so fundamental and blatant that I hesitate to even call it a "flaw". The hardware does not actually offer any crypto security at all, none.
The hardware is doing one of two things, although I don't have enough information to be sure which of the two.
The less likely possibility is that all of these modules are encrypted with the exact same key. To use the standard car analogy, it's like a manufacture advertising that their cars use super-secure AES locks on their cars (and yes AES locks are insanely uncrackable locks) but they manufacture all the cars to use the same key. The software us written not to sick that key in the car unless you enter your password, but that is not a software flaw - the is hardware designed to open for anyone who sicks in that public key. It is flagrant deception to advertise these cars as being "protected by super locks". Yeah, the superlock is technically present but it is effectively unused. Anyone can stick in the blank key and drive off with your car and your data.
The second and much more likely possibility is that each car lock really does use different random keys, but the hardware actually keeps a copy of that key mounted inside the lock, and the car merely has a button on the outside of the door to rotate that key in the lock. Again the software may be written not to press that hardware button unless you enter your password, but again it is not a software flaw. The hardware flaw is that it stores the key duct-taped to your data, and to make matters worse the hardware has a public button to automatically use that key to unlock your data for anyone. Again, the "superlock" is technically present, but again it is effectively unused.
Either way, the hardware is designed to open for (1) anyone with a blank key or (2) anyone without any key at all.
Tossing unused solar panels in the trunk of a car does not make it a solar powered car. That's not a "flaw", and it is completely false to advertise it as a solar powered car.
This hardware is advertised as superduper AES data encryption, but the hardware does not actually bother to use your password to encrypt the data.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
I wonder how good the security REALLY is on nuclear arms. It's entirely possible that there are holes as glaring as this one in the internal equipment used to control the launch of nuclear missiles.
Course, it is the ultimate in obscurity. No one is ever allowed to connect any kind of debugger or sniffer to the control systems in a missile silo. The plans of the system are a secret, and as I understand it many of the computers in there are very old, running obscure OSes (or no OS, just an assembly code loop) that no one has ever heard of, made custom for the project.
The original designers knew, but those guys might have worked on the project in the 70s or 80s, and many of them are probably dead or retired now.
No one is allowed physical access to any of the equipment either, with a "2 man rule" for anyone doing maintenance. I would suspect that the techs who work on the system aren't given detailed enough design documents to work out how it actually functions.
So, not sure if it's really a problem. Can't come up with ideas for attacking a system if you don't even know what the system is. Kind of like being told that someone is encrypting a message, but you don't know how they are going to do it, nor can intercept any of the communication.
Still, in a sci fi story I am working, a group of terrorists are able to get physical access to the equipment in a missile silo, and they are helped by an AI who can instantly figure out how to hack into a system if given access to the equipment.
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.
Actually, the flaw is indeed in the modules. They ALL use they same unlock key. I'd say that makes them flawed. The software is not helpful - it just obscures the fact that they all use the same unlock key by asking for a unique password that it converts to the common unlock key - but as unhelpful as the software is, it isn't the issue.
To put it another way, there is no way of fixing the software to change the fact that all of these drives can be accessed with one known key, which means its not the software that is broken, its the keys.
Of course, it doesn't help that the software gave up that key, so that is certainly a flaw but if the modules all had different keys it wouldn't be as helpful and it certainly isn't as big as a problem as the modules all being the same!
-Taylor
Worldwide Military budgets: $2100 billion. Worldwide Space Exploration budgets: $38 billion. Really, world? Really?
> 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.
Honestly, I think you could gain significant publicity if you publish detailed steps somewhere to demonstrate this. If you do, this is a huge and significant case of misleading advertising by the flash driver makers. Google ads + a single blog page probably will make it worth your time.
On the other hand, you could be mistaken, misleading us or something else. (I'm not saying you are, just that the claim you are making is huge and deserves / needs followup).
Thanks for posting this update. I've always had respect for IronKey and that level of respect just went up a few notches.
Slashdot's first reaction to VMware