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.
"12345"
Looks like they forgot the ROT13
I got an IronKey from my parents for Christmas. I haven't used it on a Windows machine yet, just my MacBook Pro and Linux EeePC at home and my iMac at work. The article doesn't mention whether or not that platform is affected by a similar type of issue or not -- is anyone more familiar with this that can weigh in on that? I'd be kind of pissed if my brand new toy turns out to just be a toy after all, but IronKey is also FIPS 140-2 certified. Do the tree products noted just use the same original vender for the encryption?
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.
Seems that they did in software what should have been done in the hardware. The USB hardware should consider itself safe and the host machine suspect.. atleast in my mind. ATMEL has some good chips like: http://atmel.com/products/securerf/cryptocompanion.asp?family=646
http://soylentnews.org/~tibman
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.
It involves a predictable post with the same predictable replies all the time...sort of like Fox news, or slashdot;)
Alternatively, instead of challenge-response it's greeting-response.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
Does anyone else feel like standard ways of encrypting USB Drivers are urgently requires so we no longer need to depend on third party vendor software to do the job [badly]?
Unfortunately only Microsoft or to a lesser degree Apple could roll out such a standard since nobody else have the leverage.
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.
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!
If I understand the article correctly, the access application in effect ignores the entered password, and instead - probably as a result of miserable software design - uses a fixed-string password for the encryption/decryption. In that case, it's not so much a compromise as an own-goal by the fools who wrote and tested (?) the Windows access application. The encryption implementation itself is probably fine if it's given decent keys...
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
Every time anyone discovers some tiny vulnerability in any computer security system (WPA, TKIP, AES, etc) nerds everywhere leap into action, spreading FUD while shunning the now flawed protocol and anyone who still chooses to use it.
But the reality is that for almost everyone, the flawed protocol is still fine. Most people only need to protect their data from another average computer user, not a hacker, sophisticated encryption-cracking security firm or a government.
It's like locking your car or your house. It's really only designed to keep honest people honest.
So please don't go scaring the ignorant needlessly. I don't want to spend 30 minutes trying to explain to my mother how WEP is different than WPA and why she shouldn't be concerned. All I get out of that transaction is a confused and paranoid mother whose password is still her last name.
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 ).
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.
Similarly, you'd have to be a complete idiot to give such devices any kind of certification. We all know that companies can sell any junk they want, that's why we rely on certification agencies. But now we know that certification agencies really work as marketing agencies, boosting the sale of junk hardware by sticking their logo on it.
Yeah, that's my understanding as well. Its not an issue with Windows, per se. I would use TrueCrypt as well. (Which I do.)
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Isn't that fraud? How were they marketed?
// MD_Update(&m,buf,j);
if you are that worried about the security of your data , don't allow usb flash drives , period...
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
IF in fact what you've discovered is true across several vendors "FIPS certified" flash drives, then I'm not sure what is more disturbing; The idiot who designed this "encryption" scheme, or the idiot in charge of rubber stamping the FIPS certification on it.
I knew there was more than one reason I use TrueCrypt everywhere...
If they marketed it as encrypting the data on the drive then yes, or at least false advertising.
You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.
Strongly agreed! This tells me that none of those vendors can be trusted. NIST also cannot be trusted.
That sort of snake oil is way too common in "secure" USB drives. The first one I personally tested was equally bad. It supposedly used fingerprints to secure the data. It did in a sense, but an incorrect fingerprint just caused the drive to claim it was smaller than it actually was. It would happily allow you to read those sectors past the reported "end of disk" though, so it wasn't exactly secure. The vendor had actually never considered that someone might send raw SCSI commands rather than depend on the standard OS drivers.
Provided, of course, they follow the same specs when they create their Linux or MacOS or otherwise client software. I've seen many situations where one OS will make it trickier than another to implement a particular security feature, so that feature gets pushed back for that platform and misses the release. I didn't read the article, so I don't know if they tested any sort of Linux or MacOS based password auth client to see if it has the same vulnerability, but from the general gist of what people are saying, I'm not expecting that there even is a Linux or MacOS based password client. All I know is that I wipe that crap off my flash drives as soon as I get them and opt for an OSS solution (lately truecrypt, but there have been others...I wrote a little one myself a few years back that didn't have this particular problem...but probably had other security shortfalls) to lock things down.
Unfortunately, if you work in the federal government, you need that FIPS 140-2 compliance. While I'd love to use Truecrypt all over the place instead of commercial software that I don't really trust, it's not really an option.
Now, for personal use, absolutely. But I'd have to assume that people already just use Truecrypt for personal use (assuming you're the kind of person who reads Slashdot, at least...)
Once there has been established a perfect unbreakable encryption, they will then have to work on establishing perfect and unbreakable people that deal with the information; and that's much harder to do.
I think it is a smart move to keep putting up walls of security with encryption; people should try to maintain their secrecy for whatever purpose that is... But history shows that the encryption will most likely be broken. And given the day that the encryption cannot be broke, more focus will be applied to the human intelligence collection effort and the fallible characteristics of humans will then be the Achilles's heel (not that this approach isn't already well underway).
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.
As you will see from the rebuttals below, you are just wrong.
Put the real problem is whose head will roll for this, This needs to attract punitive damages.
This is like having a bank vault, and investing thousands in an expensive lock - then placing that lock on the outside of the vault in a tin box. All they have to do is smash off the box and turn the knob behind it. There's a word for this: incompetence. I'm not sure why companies still put up with this kind of stupidity. Seriously, if a doctor pulled this kind of stunt he'd lose his license.
Paul Anderson
"I drank WHAT?!" -- Socrates
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.
Exactly. First thing I do is clear out all the crap that shipped on the drive, then set it up the way I would like it. I don't care about the platform allegiance issue, but why use unknown tools when it's so easy to avoid them.
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
This is not to say that they broke the encryption, but just to say they figured out a way to bypass the encryption scheme altogether
which is not to say, that with a proper fix to the software or hardware, that the usb key is useless.
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.
No, no, no be sure to do it 256 times. That's the most secure (assuming 8-bit char are used).
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.
Storing your data, even temporarily, on computers you don't trust (i.e. down administrate yourself) means the administrator can get your data. If you don't like that, avoid it.
Application level encryption is probably the best way to go
Ermm... what is application level encryption? Either a machine you don't trust is decrypting your data or it isn't. By definition of not trusting the machine, you aren't 100% sure what the application does, even if you've run what appears to be the same application on a machine you do trust.
Yes, I know it's possible to compute on encrypted data; i.e. for some class of function g, there exists functions f such that f(E(x)) = E(g(x)), where E is the encrypting function. That lets you compute on your data on someone else's computer. But what you probably want in 99% of the cases is to see and interact with your data. It's not much fun inserting characters into your document if you can't see where you're inserting them. And why not just insert them on a computer you trust, if you go through the trouble of setting up the function that can do the encrypted computation? I mean, this is not what you mean by application level encryption, right?
> 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).
Application level encryption is like a password on your document or RAR file.
Ah, per-file encryption.
assuming you didn't do anything stupid like assign the same password to all the files on the disk
Right. I'm going to remember a high-entropy password for each of my files. My long-term memory is capable of that. And it's capable of rotating them.
the adversary only got access to that particular document
If you don't mind the adversary getting access, why encrypt in the first place? Which threat are you secure against?
On the other hand, if you do mind, which threat are you secure against?
It's not even good flamebait. The linked article doesn't quote Obama once!
YOU ARE THE MAN! This is one of the best posts I've heard in like, FOREVER! I am going to remember this. I am going to use this on as many people as possible. I've often said this to people, but, not so eloquently and succinctly. I'll be sure and give you credit Mr. Anonymous Coward. I've read a lot of your posts before, but, this vindicates everything else you've ever said. This beer is for you AC!
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
You'd of course have to be a complete idiot to design an authenticating mechanism in this manner. TrueCrypt does not share this design.
What is even more worrying is that this device actually complied with some/any official standard. It doesn't matter which standard. it demonstrates that the device's method of keeping your data safe is retarded. Also that those who make and regulate these standards are also retarded.
How many people would have kept confidential data on these things due to a mistaken belief that the standards themselves aren't broken let alone the device that has been certified as complying with them.
The new right fascists are bilingual. They speak English and Bullshit.
It appears that it would be trivial to add Linux support for these devices.
Just ask for a password, then emit the magical string to them.
I didn't say it would be secure, but it would be compatible with the existing implementation.
FIPS 140 doesn't cover authentication systems, FIPS 140 only covers cryptography. They got the crypto right, but the authentication system was a sham.
Common Criteria certification would cover the authentication system. Note these drives carry no CC certification.
-- Cerebus
The data is encrypted on the drive, however the USB interface is cleartext. Authentication should unlock a (hopefully random, hopefully stored encrypted) drive specific key.
The real failure is certifying labs - NIST contracts third party labs to follow the guidelines and only reviews the final documentation. Source review should have caught this. The operational test should have caught this.
Oh well!
I said no... but I missed and it came out yes.
Well, true, but FIPS 140-2 *does* cover key storage, key load and minimum sizes. Also, their security policy may specify certain physical security requirements which could lead to a certification under these circumstances.
Of course, at level 1, this probably didn't mean much, depending upon where they defined the security boundaries.
NIAP is changing CC evaluation, and FIPS 140-3 is a *long* time coming. Hopefully these minimum standards can also take into account mobile devices at some point, as there is an entirely different set of needs when you compare a secure SCIF to some guy loosing his USB key down at the bar.
I said no... but I missed and it came out yes.
Hardware encrypted USB drives offer two things over software:
1: Can be made to be platform independent. The encryption can work just as well if you plug the drive on an AIX machine, just as if you plugged it onto Windows.
2: It does not require root or admin level privs, especially if one is using computers at a public computer lab which are locked down completely. Some universities lock down their computer labs, so having the AES encryption in hardware is the only way to ensure that private documents stay private.
Just like the filesystem problem, unfortunately, there is no one block encryption standard that allows mounting filesystems across all platforms. The closest is likely TrueCrypt because it supports Linux, Macs, and Windows. However other widely used platforms like AIX, Solaris, and HP-UX are left out.
They just discovered a back door for the convenience of the IT folks.
"The reason current FIPS standards don't defend against the vulnerability is because in a corporate environment, being able to unlock and manage hundreds of USB flash drives with a single administrative password is useful, Jevans noted, "which is effectively what this vulnerability is."
The device password, which is unlocked by a user password, is built into the software that resides on all of the USB drives."
One password to unlock them all. Better be sure to make it a real strong one :-)