Forgot your password?

typodupeerror
Security Data Storage Windows Hardware

Encryption Cracked On NIST-Certified Flash Drives 252

Posted by timothy
from the whoopsie-daisy dept.
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."
This discussion has been archived. No new comments can be posted.

Encryption Cracked On NIST-Certified Flash Drives

Comments Filter:
  • by Anonymous Coward on Tuesday January 05 2010, @02:40PM (#30658430)

    One weakness in the entire crypto-system can bring the whole thing down.

  • by NeutronCowboy (896098) on Tuesday January 05 2010, @02:41PM (#30658462)

    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.

  • Re:Truecrypt (Score:5, Insightful)

    by sakdoctor (1087155) on Tuesday January 05 2010, @02:47PM (#30658542) Homepage

    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.

  • by JazzyJ (1995) on Tuesday January 05 2010, @02:47PM (#30658546) Homepage Journal

    The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.

  • by georgewilliamherbert (211790) on Tuesday January 05 2010, @02:57PM (#30658744)

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

  • Re:IronKey? (Score:4, Insightful)

    by Andy Dodd (701) <atd7 AT cornell DOT edu> on Tuesday January 05 2010, @03:02PM (#30658816) Homepage

    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.

  • Re:Truecrypt (Score:5, Insightful)

    by plover (150551) * on Tuesday January 05 2010, @03:07PM (#30658874) Homepage Journal

    This problem is only that of "closed source" and not one of "Windows only". It would be equally insecure on any OS.

  • by ragethehotey (1304253) on Tuesday January 05 2010, @03:09PM (#30658890)

    Assuming your last comment wasn't a rhetorical question, you already know the answer to this: Because the perceived value-add of selling an encrypted drive allows them to charge more than simply bundling TrueCrypt with a bog-standard USB drive. The public justification would be that their software is easier to use (and, if they're feeling particularly full of themselves, more secure).

    But with a minimal amount of work they could simply take the source, rename it and give it a pretty interface, and never have problems like this?

  • by hey! (33014) on Tuesday January 05 2010, @03:21PM (#30659020) Homepage Journal

    Only? It's *mainly* defects in the rest of the system that tend to bring things down.

    Algorithms, once they get to the point where the experts trust them, are very seldom broken in the everything-laid-completely-bare way that faulty system design gets you. It's usually more like "could be broken with a week of supercomputing time ten years from now" or "can calculate a hash collision for certain specially constructed messages" variety of crack.

    Of course once you get to that point, you have to assume that some really bright people will find a way to generalize the fault in the algorithm. If they'd broken AES, or even found an unexpected weakness in it, that'd be *huge* news. Instead, what they've found appears to be a classic case of plain old brain damaged design.

    If the article is to be believed, the researchers found a really, really stupid flaw, the kind a non-expert like I could understand and probably exploit with not much effort. I would paraphrase this way: all these drives *effectively* have exactly the same key, but that fact is obscured by the software.

  • backdoor (Score:1, Insightful)

    by Anonymous Coward on Tuesday January 05 2010, @03:29PM (#30659118)

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

  • Re:some data (Score:4, Insightful)

    by mick232 (1610795) on Tuesday January 05 2010, @03:39PM (#30659258)
    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.
  • by plover (150551) * on Tuesday January 05 2010, @03:49PM (#30659408) Homepage Journal

    While I agree that trust belongs on the device (via a device-based keyboard), you still have to trust the host computer to not abuse the trust by copying the now-unlocked data or otherwise tampering with it. You are still at risk if you unlock the device and plug it in to a coffee shop PC.

  • by Archangel Michael (180766) on Tuesday January 05 2010, @03:51PM (#30659420) Journal

    If what you are saying is true, that it uses the same encryption key for all devices, that would have to be by "Design", or worse, negligence. I seriously doubt that the engineers for this thing thought one key to rule them all would be acceptable, which leaves us with "Design".

    However, I'm reminded of the old addage, "Any sufficient level of incompetence is indistinguishable from malice".

    My view is that sufficient levels of incompetence should be treated exactly like malice. And in this case the company(companies?) should be held responsible on a criminal level. Criminally incompetent, or Fraud.

    Why don't we have a corporate death penalty?

  • Re:Insider (Score:3, Insightful)

    by vlm (69642) on Tuesday January 05 2010, @04:18PM (#30659774)

    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.

  • Re:Truecrypt (Score:3, Insightful)

    by plover (150551) * on Tuesday January 05 2010, @04:46PM (#30660270) Homepage Journal

    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.

  • Re:Truecrypt (Score:3, Insightful)

    by space_hippy (625619) on Tuesday January 05 2010, @04:50PM (#30660330)

    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.

  • Re:some data (Score:3, Insightful)

    by Alsee (515537) on Tuesday January 05 2010, @05:13PM (#30660716) Homepage

    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.

    -

  • Hmm (Score:2, Insightful)

    by ShooterNeo (555040) on Tuesday January 05 2010, @05:19PM (#30660828)

    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.

  • Re:some data (Score:4, Insightful)

    by Facegarden (967477) on Tuesday January 05 2010, @06:09PM (#30661566)

    First, here's the NIST list of approved 140-1 and 140-2 modules [nist.gov].

    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

  • Re:Truecrypt (Score:2, Insightful)

    by zuperduperman (1206922) on Tuesday January 05 2010, @06:47PM (#30662030)

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

  • by witherstaff (713820) on Tuesday January 05 2010, @09:28PM (#30663994) Homepage
    If only it was just a private bank, instead of being a government mandated monopoly. Corporatism is not libertarian friendly.
  • by Anonymous Coward on Tuesday January 05 2010, @09:35PM (#30664046)

    So- what was the point of the on-board encryption? The hardware had the capability and did the on-board encryption? It just didn't sent the password the user entered? It used a generic password to both encrypt and decrypt? If that were true then wouldn't any password the user entered or decrypt the drive work? I'm a little confused about what exactly the problem was here. Unless these drives never did on-board encryption at all.

  • by ogdenk (712300) on Tuesday January 05 2010, @09:43PM (#30664104)

    I don't allow my users to have admin privs on their desktops but they all have thumb drives. That's suicide. It becomes a maintenance nightmare and I can't stand it when I go to a user's desktop and find 500 IE toolbars and 20 icons in the System Tray. Get a clue. I hope you're not a network admin.

    All my users have unprivileged accounts. Windows users are further restricted via Group Policy.

  • Re:IronKey? (Score:3, Insightful)

    by Jon Abbott (723) on Wednesday January 06 2010, @01:04AM (#30665788) Homepage

    Thanks for posting this update. I've always had respect for IronKey and that level of respect just went up a few notches.

  • Re:Hmm (Score:3, Insightful)

    by Chili-71 (768964) on Wednesday January 06 2010, @10:03AM (#30668904)
    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.

I know you're in search of yourself, I just haven't seen you anywhere.

Working...