Encryption Cracked On NIST-Certified Flash Drives

← Back to Stories (view on slashdot.org)

Encryption Cracked On NIST-Certified Flash Drives

Posted by timothy on Tuesday January 5, 2010 @06:37AM 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."

252 comments

Aye by Anonymous Coward · 2010-01-05 06:39 · Score: 0

Flash post!
R
It's not just the algorithm by Anonymous Coward · 2010-01-05 06:40 · Score: 3, Insightful

One weakness in the entire crypto-system can bring the whole thing down.
1. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 06:55 · Score: 0
  
  Govt regulation != socialism, it is what regulation were imposed and how they were imposed that matter. Any way why do i bother replying to a troll.
2. Re:It's not just the algorithm by plover · 2010-01-05 07:04 · Score: 4, Informative
  
  This has nothing whatsoever to do with Microsoft, you troll. RTFA.
  The "password" software just sent the "it's OK, decrypt this" to the dongle.
  
  --
  John
3. Re:It's not just the algorithm by hey! · 2010-01-05 07:21 · Score: 5, Insightful
  
  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.
  
  --
  Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
4. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 08:21 · Score: 0
  
  ITT: Trolls trolling trolls.
5. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 08:53 · Score: 3, Informative
  
  I used to do FIPS, Common Criteria and Interac certifications.
  For starts we were paid by the manufacturer of the device so every device passed. There was one case where a product was so obviously flawed we decided not to take the money and they device was certified by another certification shop.
  Second, the cost for the certification is fairly competitive and the competition has driven the price down to the point where the money paid just barely covers doing the paper work. The actual investigation of the devices or software is only hours.
  Third, NIST is extremely sloppy in checking up on the certification houses. They are even sloppy about verifying their own tools for doing known answer tests for well know algorithms.
6. Re:It's not just the algorithm by Monkeedude1212 · 2010-01-05 09:04 · Score: 0, Offtopic
  
  Good for you the Federal Reserve isn't owned by the government. Its a private bank.
7. Re:It's not just the algorithm by Andy+Dodd · 2010-01-05 09:10 · Score: 1
  
  Yup, in this case the crypto algorithm has no issues. Nor is it an implementation issue of the algorithm itself.
  The greatest crypto in the world means nothing if your key management scheme sucks and it's easy for an attacker to get the key. In this case, it sounds like the key is common to all drives, so an attacker just needs to buy a drive, figure out their own key, and then use that key to attack all other drives.
  
  --
  retrorocket.o not found, launch anyway?
8. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 09:26 · Score: 0
  
  Algorithms and security protocols are very often broken - however it takes sometimes decades to find their weaknesses.
9. Re:It's not just the algorithm by negRo_slim · 2010-01-05 10:13 · Score: 1
  
  Govt regulation != socialism ...
  Looks like someone just finished the operator section in their VB book!
  
  --
  On the Oregon Cost born and raised, On the beach is where I spent most of my days
10. Re:It's not just the algorithm by Dog-Cow · 2010-01-05 10:34 · Score: 1
  
  VB doesn't have != as an operator.
11. Re:It's not just the algorithm by clodney · 2010-01-05 11:50 · Score: 1
  
  We already have a tag for "mathishard". What we really need is a "cryptoishard" tag. As you point out, the actual crypto algorithms are incredibly robust. What most developers don't pay any attention to is that fact that all the other pieces of the system have to be equally as robust, or you get a trivial crack.
  Most of these systems are brought down by some very humble flaw. A locked bank vault with the combination hidden under the mat.
12. Re:It's not just the algorithm by ghjm · 2010-01-05 12:38 · Score: 1
  
  ...and therefore all good Libertarians love it like apple pie.
  Right?
13. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 12:46 · Score: 0
  
  Shocking!
  You mean I shouldn't blindly trust Common Criteria certification to mean that all possible security problems have been anticipated and prevented in advance?
  Can you please tell that to my boss? kthx...
14. Re:It's not just the algorithm by witherstaff · 2010-01-05 13:28 · Score: 2, Insightful
  
  If only it was just a private bank, instead of being a government mandated monopoly. Corporatism is not libertarian friendly.
15. Re:It's not just the algorithm by Anonymous Coward · 2010-01-05 13:35 · Score: 1, Insightful
  
  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.
16. Re:It's not just the algorithm by Anonymous Coward · 2010-01-06 02:26 · Score: 0
  
  This guy explained it best.
17. Re:It's not just the algorithm by ArsenneLupin · 2010-01-09 06:31 · Score: 1
  
  And what does this have to do with breaking an encryption scheme that was possible because Microsoft is just bad software?
  Maybe, that it's necessary to define properly what the system is. Your USB stick is plugged in into a computer that is powered by electricity generated by the public power monopoly regulated by the US Department of Energy.
  Now, does the Department of Energy need to be audited in order to certify the USB stick? Obviously not.
  Does the computer need to be audited? It depends...
  Does the password entry program that does come with the stick need to be certified? Apparently yes, as has been shown by this incident.
  Or does it?
  No, not really, because the problem was not one of vulnerability in that program (such as password being able to be spyied upon by a memory reader or keystroke logger), but rather in the specification (to what decryption string should a password map ==> in this case the string was a constant, so obviously not secure).
  This distinction is important to make, or else some really stupid vendors will use security as an excuse to lock down their hardware so much that it can only be used on an OS which is a prime target for keystroke loggers. Be careful what you wish for!
  What really should happen is that vendors of hardware encryption devices should provide specifications, and maybe open-source reference implementations of their external password entry programs. These specifications should then be audited to make sure that they make sense (no "constant unlock string", or weak password hashing functions). Ideally, the entry program should even pass the password as is to the device, and any downhashing should happen securely within the device.
Truecrypt by Anonymous Coward · 2010-01-05 06:41 · Score: 0, Interesting

Does this affect Truecrypt using the same encryption mode?
1. Re:Truecrypt by sakdoctor · 2010-01-05 06:47 · Score: 4, Insightful
  
  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.
2. Re:Truecrypt by Anonymous Coward · 2010-01-05 06:58 · Score: 5, Informative
  
  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.
3. Re:Truecrypt by plover · 2010-01-05 07:07 · Score: 4, Insightful
  
  This problem is only that of "closed source" and not one of "Windows only". It would be equally insecure on any OS.
  
  --
  John
4. Re:Truecrypt by von_rick · 2010-01-05 07:20 · Score: 5, Informative
  
  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!
5. Re:Truecrypt by mick232 · 2010-01-05 07:44 · Score: 1
  
  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.
6. Re:Truecrypt by interval1066 · 2010-01-05 07:45 · Score: 1
  
  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".'
7. Re:Truecrypt by kestasjk · 2010-01-05 07:54 · Score: 2, Interesting
  
  Isn't that fraud? How were they marketed?
  
  --
  // MD_Update(&m,buf,j);
8. Re:Truecrypt by geekmux · 2010-01-05 07:59 · Score: 2, Informative
  
  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...
9. Re:Truecrypt by Gerzel · 2010-01-05 08:02 · Score: 1
  
  If they marketed it as encrypting the data on the drive then yes, or at least false advertising.
10. Re:Truecrypt by sjames · 2010-01-05 08:16 · Score: 1
  
  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.
11. Re:Truecrypt by zullnero · 2010-01-05 08:17 · Score: 1
  
  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.
12. Re:Truecrypt by gumbo · 2010-01-05 08:20 · Score: 1
  
  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...)
13. Re:Truecrypt by plover · 2010-01-05 08:46 · Score: 2, Insightful
  
  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
14. Re:Truecrypt by space_hippy · 2010-01-05 08:50 · Score: 3, Insightful
  
  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.
15. Re:Truecrypt by FatdogHaiku · 2010-01-05 09:01 · Score: 1
  
  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
16. Re:Truecrypt by zuperduperman · 2010-01-05 10:47 · Score: 1, Insightful
  
  > 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).
17. Re:Truecrypt by Anonymous Coward · 2010-01-05 16:25 · Score: 0
  
  Similarly, you'd have to be a complete idiot to give such devices any kind of certification.
  
  Similarly, you'd have to be a complete idiot to rely on a certification without knowing what that certification says and covers and what it doesn't.
18. Re:Truecrypt by uninformedLuddite · 2010-01-05 16:58 · Score: 1
  
  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.
19. Re:Truecrypt by SEWilco · 2010-01-05 18:02 · Score: 1
  
  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.
20. Re:Truecrypt by SEWilco · 2010-01-05 18:06 · Score: 1
  
  I didn't say it would be secure, but it would be compatible with the existing implementation.
21. Re:Truecrypt by Cerebus · 2010-01-06 03:05 · Score: 1
  
  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
22. Re:Truecrypt by Panaflex · 2010-01-07 08:26 · Score: 1
  
  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.
23. Re:Truecrypt by Panaflex · 2010-01-07 08:35 · Score: 1
  
  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.
How does this differ from Truecrypt? by NeutronCowboy · 2010-01-05 06:41 · Score: 2, Insightful

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.
1. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 06:46 · Score: 0
  
  So that they can claim their encryption is better than the one competitors use?
2. Re:How does this differ from Truecrypt? by jimbobborg · 2010-01-05 06:46 · Score: 3, Informative
  
  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.
3. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 06:48 · Score: 0
  
  young skywalker, you mustn't forget that people said the same of md5 when john the ripper came out!
4. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 06:51 · Score: 1
  
  “Consumers shouldn’t have to know what’s inside,” he said. “They should just know it will play.” What applies to entertainment for the drooling masses also applies to security for the drooling masses.
5. Re:How does this differ from Truecrypt? by NeutronCowboy · 2010-01-05 06:53 · Score: 2, Informative
  
  No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.
  But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.
  
  --
  Those who can, do. Those who can't, sue.
6. Re:How does this differ from Truecrypt? by bamf · 2010-01-05 06:57 · Score: 4, Informative
  
  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.
7. Re:How does this differ from Truecrypt? by PylonHead · 2010-01-05 06:58 · Score: 1
  
  The info isn't encrypted, it's just locked with a password.
  Yeah, that's what the story seems to say. But that makes no sense... Why have an AES 256-bit hardware encryption system if you're going to store the data unencrypted? I mean.. it's all just bits as far as the memory chips are concerned.
  
  --
  # (/.);;
  - : float -> float -> float =
8. Re:How does this differ from Truecrypt? by OscarGunther · 2010-01-05 07:03 · Score: 2, Informative
  
  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).
9. Re:How does this differ from Truecrypt? by jimicus · 2010-01-05 07:07 · Score: 2, Interesting
  
  No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.
  But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.
  If it was properly encrypted, the decryption would be carried out on the device using a key supplied by the host PC and the device wouldn't be physically capable of decrypting it without the key. As it stands, the most charitable reading of this is that it IS using AES encryption, but it always uses the exact same key regardless of what the enduser does in the software.
10. Re:How does this differ from Truecrypt? by ragethehotey · 2010-01-05 07:09 · Score: 2, Insightful
  
  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?
11. Re:How does this differ from Truecrypt? by silent_artichoke · 2010-01-05 07:21 · Score: 2, Interesting
  
  This makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event you forget your password.
12. Re:How does this differ from Truecrypt? by gad_zuki! · 2010-01-05 07:29 · Score: 3, Interesting
  
  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:
  
  Also note that, as regards personal privacy, in most cases, it is not safe to work with sensitive data under systems where you do not have administrator privileges, because the administrator can easily capture and copy the sensitive data, including the passwords and keys.
  However, users without administrator privileges cannot encrypt/format partitions, cannot create NTFS volumes, cannot install/uninstall TrueCrypt, cannot change passwords/keyfiles for TrueCrypt partitions/devices, cannot backup/restore headers of TrueCrypt partitions/devices, and they cannot run TrueCrypt in portable mode.
  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.
13. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 07:30 · Score: 0
  
  Can anyone explain to me why the disk manufacturers chose to reinvent the wheel,
  Because then it will be their wheel, which they do not need to pay a hefty(?) licence-fee for every created stick.
  Also, companies in general do not make their product for you (who mistakingly thinks he can expect a decent product, working as advertised), but just as the twenty-eth century equivalent of the old beads and mirrors. The cheaper they can produce their trinkets, the better.
  Its your money they're after, and their product is just a means to the goal.
  Hence laptops (even from well-known brands) with a failure-rate of over 40% in the first year. :(
14. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 07:31 · Score: 0
  
  The whole point of this is to put a bullet point on the box. Uses AES Encryption!!!! It is true, they do use it, however its not really useful, and a full hardware encrypt/decrypt package would cost more...
15. Re:How does this differ from Truecrypt? by JaWiB · 2010-01-05 07:41 · Score: 1
  
  If they aren't encrypted, I assume that means that these devices don't actually meet the NIST standard. Couldn't there be a lawsuit for advertising the drives as such?
16. Re:How does this differ from Truecrypt? by vlm · 2010-01-05 07:45 · Score: 1
  
  This makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event you forget your password.
  Far more likely: makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event law enforcement/military/courts would like to see whats on your drive.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
17. Re:How does this differ from Truecrypt? by Archangel+Michael · 2010-01-05 07:51 · Score: 2, Insightful
  
  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?
  
  --
  Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
18. Re:How does this differ from Truecrypt? by DavidTC · 2010-01-05 07:51 · Score: 1
  
  Yeah, that's what gets me. I mean, it's one thing if they were selling special software and didn't want to have to distribute it, which the GPL would make them.
  But they're selling a drive. I mean, it's just as much work any other way.
  Edit TrueCrypt's interface, put it to autostart from the tiny cleartext partition (Using that autorun U3 trick), have it only look for a specially marked partition on the other drive, and mount it, or prompt for password and format it if the partition is blank.
  Tada.
  Instead, they use a dumbass hardware encryption with a single key.
  I slightly understand the idea of hardware decryption on flash drives, although I still contend there is almost no possible sequence of events where hardware decryption would help vs. a truecrypt file on a flash drive. It doesn't help against keystoke loggers, it doesn't help against mirroring programs, I'll be damned if I can see what it defends against.
  But this is just stupidity on top of that.
  That said, hardware decryption is cool because it doesn't need admin privs...in theory. Although they could just as easily have a user-level version of truecrypt loop back to an installed driver.
  I.e., the drive would have two partitions on it, but actually have three. (Or appear as two entirely separate devices.) Attempts to access the third one would, by the hardware, send a request to a user-space program running on the computer. Which would be Truecrypt, which would read the encrypted data off the drive, decrypt it, and pass it back to the hardware, which would pass it back again.
  Sounds slow, but , hell, it's decryption, and no USB flash drive can keep up with the USB 2.0 standard anyway. Such a loopback chip, which could be some serial interface the hacked truecrypt connects to to get commands and send data, would certainly be cheaper than a hardware decryption chip, although who knows if they're just going to fake it with a single key. (Which is, strictly speaking, not even 'encryption'. It's just a goofy media encoding scheme.)
  Oh, and, tada. Unpatentable for the win!
  
  --
  If corporations are people, aren't stockholders guilty of slavery?
19. Re:How does this differ from Truecrypt? by mick232 · 2010-01-05 07:52 · Score: 1
  
  What's more: because they "use" AES (no matter how they use it), they can also put one more bullet point on the box: FIPS-140 certified by the NIST. This certification is misleading and should no longer be given.
20. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 07:52 · Score: 0
  
  In that event, you can still provision it relatively securely. Using the manufacturer's public key, encrypt the user's key and store that on the drive. Then the drive could be decrypted by the manufacturer, but no one who lacks the manufacturer's private key should have access other than the user.
  It's a helluva back door, but it doesn't have to be a wide open hole that just anyone can waltz on through.
21. Re:How does this differ from Truecrypt? by vlm · 2010-01-05 07:52 · Score: 1
  
  But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.
  Certain corporations want to "poison the well" of encrypted USB drives. Doesn't really matter why and thats not the point of this post. The end result of this incident is every clueless PHB now "knows" that its "impossible" to make a properly encrypted USB drive, and somehow the corps that are intentionally poisoning the well believe they will profit off that incorrect belief. Maybe they want to drive (bad pun) a competitor out, maybe they lack the patents their competitors have, who knows. Maybe they are just don't want to expand the product line to include "secure" devices and want to stick to insecure only.
  I could imagine a situation where a drive manufacturer could not be a profitable concern as long as the competitors can get the high profit of selling secure drives. So, eliminate their ability to sell the profitable ones, by poisoning the whole market.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
22. Re:How does this differ from Truecrypt? by vlm · 2010-01-05 07:59 · Score: 1
  
  Oh, bad of me to reply to one of my own posts, but maybe they need to poison the market for encrypted USB drives because they're about to release a different kind of competing product, like maybe a USB hub that encrypts the traffic flowing thru it to any brand or model of USB drive. Or maybe coincidentally only works with same manufacturers drives.
  Maybe they may want to ruin the sub market of encrypted USB drives because contract terms are getting unfavorable for them in that sub market, and coincidentally they plan to release a different kind of encrypted storage product.
  The cloud encryptor. The combined USB hub/encryptor. Some expensive SW thing. Who knows.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
23. Re:How does this differ from Truecrypt? by geekmux · 2010-01-05 08:05 · Score: 1
  
  No, it's actually encrypted. The problem is that the command to unencrypt the data is always the same. In other words, a small little widget can sit between the password program and the encrypted disk, and just send the right command string, regardless of what password was entered. Instant decryption.
  But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.
  If it's not yet that obvious, let me sum up the definition of "regardless of what password was entered" in two words: Big Brother.
  Perhaps this is the fine print part of "FIPS" certification we never heard about...the master key.
24. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 08:11 · Score: 0
  
  Does anyone know what encryption they are using? Apparently the same stupid software is running on all the thumb drives. So either they're really all the same inside or they pirated from each other (I suspect the former). I don't know if Truecrypt is something they might be using under the covers but that wouldn't surprise me either; they don't appear to have done much original work on the drives at all.
25. Re:How does this differ from Truecrypt? by sjames · 2010-01-05 08:19 · Score: 2, Funny
  
  More to the point, what's the point of a super lock if you're going to tape the key to the door?
26. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 08:27 · Score: 0
  
  How much analysis has gone into attempting to break truecrypt? Is there a backdoor? Who wrote it, anyway; was it an individual or a government?
27. Re:How does this differ from Truecrypt? by vlm · 2010-01-05 08:28 · Score: 1
  
  If it's not yet that obvious, let me sum up the definition of "regardless of what password was entered" in two words: Big Brother.
  Perhaps this is the fine print part of "FIPS" certification we never heard about...the master key.
  Yeah, thats the good news, we know about Big Brother's master key in these software encrypted drives..
  The bad news is we don't know about Big Brother's master key in the OTHER drives.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
28. Re:How does this differ from Truecrypt? by gumbo · 2010-01-05 08:30 · Score: 1
  
  Anyone who sees a encryption device/service that offers the option of recovering your data without the passphrase should already know to run away, quickly. That's admitting right in the open that they have serious weaknesses.
29. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 08:34 · Score: 0
  
  Shhh! Don't give them ideas!
30. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 08:49 · Score: 0
  
  Does TrueCrypt require Windows users to have Administrator privileges to unlock the drive? If so, it would be a non-starter as the Kingston setup does not require admin (and our 90,000 users don't have admin). We'll probably move to using BitLocker for this since we can then unlock with the same Smart Card that users logon with and can easily enforce using GPO - so that if you want to use a USB key read only you don't have to encrypt it, but if you want to write to it you have to do the encryption.
31. Re:How does this differ from Truecrypt? by clone53421 · 2010-01-05 08:56 · Score: 1
  
  Does TrueCrypt require Windows users to have Administrator privileges to unlock the drive?
  If I remember correctly, to automatically mount the volume or to use a hidden volume in the primary partition of the device.
  A TrueCrypt volume that is stored as a regular file on the device and which you mount manually does not require administrator privileges – I think.
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
32. Re:How does this differ from Truecrypt? by jimicus · 2010-01-05 09:05 · Score: 1
  
  TBH, I think it infinitely more likely that the manufacturers considered true hardware AES encryption far too expensive and it's actually a vanilla flash drive with just one difference - it doesn't make the data available until it receives a special instruction generated by the proprietary software. The AES encryption, if it exists, applies to how they secure the stored password in the Windows app.
  Short of taking the top off it and examining under an electron microscope, there's no easy way to prove this. (That is assuming it's a single chip on there. If the flash is separate from the controller, I guess you might be able to very carefully unsolder it and connect a normal controller to the chip).
  In any case, if my second supposition is correct, I would dearly love to know what the certification process is because it clearly isn't worth a damn. Not only that, (if this is correct) I have trouble figuring out how any manufacturer attempting to get such a product certified is NOT attempting to defraud the certifying organisation.
33. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 09:11 · Score: 0
  
  Barack, is that you?
34. Re:How does this differ from Truecrypt? by Andy+Dodd · 2010-01-05 09:12 · Score: 1
  
  Because then they wouldn't be able to charge double the price of a "normal" drive.
  
  --
  retrorocket.o not found, launch anyway?
35. Re:How does this differ from Truecrypt? by Andy+Dodd · 2010-01-05 09:19 · Score: 2, Informative
  
  No, Traveler Mode (running on a machine without TrueCrypt installed) requires admin privileges.
  If TrueCrypt was installed by someone with admin privs, non-admins can then mount TrueCrypt volumes.
  
  --
  retrorocket.o not found, launch anyway?
36. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 09:21 · Score: 0
  
  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.
  Shouldn't be a problem at all. If you're working somewhere that they don't let you have admin privileges then it's almost certain that you're working somewhere that would flip right the fuck out and go postal on your ass if they knew you were plugging an unauthorized USB storage device into one of their computers.
37. Re:How does this differ from Truecrypt? by Andy+Dodd · 2010-01-05 09:21 · Score: 1
  
  Also, these drives (in theory) force the user to encrypt the drive. They can't accidentally forget to use TrueCrypt.
  You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except:
  1) Aforementioned admin privs issues
  2) A user could just reformat the USB drive partition, making it a normal non-encrypted drive.
  
  --
  retrorocket.o not found, launch anyway?
38. Re:How does this differ from Truecrypt? by clone53421 · 2010-01-05 09:33 · Score: 1
  
  I stand corrected. Is there any way to decrypt the files inside a TrueCrypt volume, though, if you know the correct password but don’t have administrator rights on the computer?
  (Naturally, to mount a drive requires having administrator rights. I’d forgotten this. Just reading the files out of the volume, though, shouldn’t... although it would probably be ill advised, since your files would then be stored in the clear on the computer you were using.)
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
39. Re:How does this differ from Truecrypt? by kvezach · 2010-01-05 09:58 · Score: 1
  
  That sounds complex. It's more likely that people can't tell whether the crypto is secure or not, so there's no real incentive to use good cryptography. Adding a simple "CALL is_proper, JNE bad_boy" scheme (hello NOPs!) is much easier than having to go through the hassle of using proper cryptography in the proper words, having to check for various attack scenarios and attacks and proof against them, and so on; and the customer isn't going to tell real AES from braindead AES anyway.
  
  Of course, like in "The Market for Lemons", the result is that everybody knows it's impossible to properly secure a USB drive. The lemons drive out the cherries until the market collapses. The usual way of handling that sort of asymmetry failure is through certification, but it seems NIST fell short of the mark here (if the drives were truly certified).
40. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 10:24 · Score: 0
  
  But still - why do something like try to reinvent crypto, when there's an open format? The license for Truecrypt even allows for commercial use.
  One of the selling points of these drives is that you can use them on any machine, even if you don't have admin rights. This immediately kills the possibility of using Truecrypt in its present form.
41. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 10:42 · Score: 0
  
  Far more likely: makes it very easy for them to charge $large_chunk_of_money for "data recovery services" in the event law enforcement/military/courts would like to see whats on your drive.
  Since TFA said that one vendor is recalling their drives, and another is looking into a possible patch, and the other hasn't shipped and won't ship until they get a fix, I suspect that your hypothesis is incorrect.
42. Re:How does this differ from Truecrypt? by jmorris42 · 2010-01-05 13:29 · Score: 1
  
  > No, it's actually encrypted.
  Bet it ain't. Think like a vendor. All they did was add one secret knock usb command that unlocks the drive. The crypto is purely in the Windows driver. They had to actually use AES somewhere or they really would get a fraud suit thrown at them. But once they did the lameness with the secret knock do you really think they wasted the extra money to put real AES crypto (and either take a performance hit or throw still more money at making it fast) in the stick vs just using a slightly modified regular part? It was pure fraud, with some attempt to have some cover if they got caught.
  
  --
  Democrat delenda est
43. Re:How does this differ from Truecrypt? by ogdenk · 2010-01-05 13:43 · Score: 2, Insightful
  
  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.
44. Re:How does this differ from Truecrypt? by omglolbah · 2010-01-05 14:10 · Score: 1
  
  Unfortunately quite a lot of software requires admin privileges to run. This is especially true in any company doing software or hardware development. I'd love to use an unprivileged account on my work machine but doing it prevents me from *drumroll* working.
45. Re:How does this differ from Truecrypt? by jonwil · 2010-01-05 14:21 · Score: 1
  
  Ok, so if you need to have workers that have work approved "secure" thumb drives, you make the encryption driver (TrueCrypt or otherwise) part of the default install so that you dont need admin privileges when you plug it in (windows can do that AFAIK)
46. Re:How does this differ from Truecrypt? by ogdenk · 2010-01-05 14:37 · Score: 1
  
  Unfortunately quite a lot of software requires admin privileges to run.
  Ever heard of SUID?
  99% of the time there is always a way to run it in an unpriveleged account with some *drumroll* work.
  The "needs to run as admin" thing is usually due to laziness and makes tech support calls easier to handle for $8/hr retard phone "technicians" reading from a script. This is VERY prevalent in Windows-land. There is almost always a way to fix it with some digging.
  I had an issue like this in a Terminal Services environment and I'll be damned if I'm going to give 50 users Admin rights. I found the issue, reported it to the vendor and they blew me off and still tell everyone it needs Admin rights.
  In the land of REAL operating systems however, most of the time this is a non-issue or if you have to, you use the SUID bit.
47. Re:How does this differ from Truecrypt? by Anonymous Coward · 2010-01-05 14:47 · Score: 0
  
  The other, non-rhetorical, reason is that due to peculiarities with how FIPS 140-2 is written it's much easier to get level 2 on a hardware implementation than on a software one.
  So by making an 'pointless' hardware reimplemenation the vendor can get a level 2 validation, but get level 2 using true-crypt (or other software) requires the use of a CC evaluated operation system with specific optional auditing features turned on.
  Level 2 looks better in marketing literature than level 1, so you've got another disincentive to simply bundle existing software.
48. Re:How does this differ from Truecrypt? by omglolbah · 2010-01-05 15:18 · Score: 1
  
  Yup, in a perfect world we would do this.
  Unfortunately the world isnt perfect.
  We have researched this quite extensively, as has the vendor.
  To change the application suite to work without administrator privileges requires a split up of the application in a way which is far into the "non trivial" category.
  It would technically be the best solution but it would not at all make much sense if profit is any motivator ;)
  Unprivileged is fine for most systems, but development work tend to have higher requirements. I sure has hell dont want to make a support ticket every time I open up the debugger...
49. Re:How does this differ from Truecrypt? by omglolbah · 2010-01-05 15:19 · Score: 1
  
  And I would love to give details but I'm not quite sure what I can say due to an NDA >.
50. Re:How does this differ from Truecrypt? by Bigjeff5 · 2010-01-05 16:00 · Score: 1
  
  it doesn't make the data available until it receives a special instruction generated by the proprietary software
  That would never qualify for government use. Simply remove the flash chip and attach it to the same type of controller if that's the case and you have unfettered access to the data.
  No, this is an app on the USB drive that decrypts the data, the "all clear" command is sent by the corresponding software after the password has been accepted.
  The weakness is that the device never re-negotiates the all-clear command. In that case it doesn't matter if the command is encrypted or not, because it is always the exact same sequence of bits that is sent. They got lazy basically, and didn't think through all the points of attack outside cracking the AES encryption. Basically they had an unbreakable door and left the key hanging next to the doorbell. Oops.
  Also remember the old axiom: never ascribe to malaice what can best be explained by incompetance.
  
  --
  Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
51. Re:How does this differ from Truecrypt? by Bigjeff5 · 2010-01-05 16:11 · Score: 1
  
  The data is encrypted, the GP is just a dumbass.
  The weakness is the "password accepted, ok to decrypt" command which actually causes the drive to decrypt the data is always the same, no matter what the password is. The key is never re-negotiated, it is set at the factory and that's it. That's a massive, massive weakness, because you can now ignore the password and spoof the "all clear" sequence and get the drive to decrypt itself.
  A strong system would at the very least create an encryption/decryption key based on the password, and a very strong system would revise that key every time the data is decrypted and re-encrypted. Once the password is shared between the software and the thumbdrive, revisions to the key need not be communicated between them, making it a very difficult system to break.
  
  --
  Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
52. Re:How does this differ from Truecrypt? by jimicus · 2010-01-05 22:16 · Score: 1
  
  In that case, why doesn't the all-clear command include the AES key used to decrypt the data as derived from the passphrase?
  If there's any encryption happening on-key at all (which I doubt), I wouldn't be even remotely surprised if it's something like a simple XOR cipher. TBH, I think you're ascribing competence to government departments where precious little evidence of such competence exists.
53. Re:How does this differ from Truecrypt? by mlts · 2010-01-07 10:33 · Score: 1
  
  If this was done knowingly, this is only going to bite the makers in the butt. There are already proven solid USB flash drives (IronKey) that have solid AES encryption and a very good authentication mechanism, and it will make those drives stand out for people who want solid security.
  What will happen if hardware USB flash drives prove wanting is that more companies will resort to using software based encryption packages to ensure the contents are encrypted. BitLocker is part of the operating system (and in businesses, Windows 7 Enterprise is the only edition of Windows 7 which uses KMS-based activation so expect that to be the most common edition of Windows in businesses, and that edition has BitLocker.) PGP and other third party security companies also offer policies that can completely encrypt removable media before it is allowed to be written to.
  So, unless hardware drive providers can provide us assurances of security, companies will take their cash to PointSec and PGP Incorporated and only buy the bare-bones models USB flash drives without the advanced security features, as the software provides both the security, as well as enterprise level assurance that if the media is removable, it will be encrypted.
Always sends the same character string by Anonymous Coward · 2010-01-05 06:42 · Score: 2, Funny

"12345"
1. Re:Always sends the same character string by pushf+popf · 2010-01-05 07:25 · Score: 3, Funny
  
  "12345"
  
  That's the stupidest combination I've ever heard in my life! The kind of thing an idiot would have on his luggage!
2. Re:Always sends the same character string by plover · 2010-01-05 07:41 · Score: 1, Redundant
  
  "12345"
  That reminds me that I have to change the combination on my luggage.
  
  --
  John
3. Re:Always sends the same character string by narcc · 2010-01-05 08:13 · Score: 1
  
  I've got the same combination on my luggage!
  
  --
  Required reading for internet skeptics
4. Re:Always sends the same character string by Inda · 2010-01-05 22:09 · Score: 1
  
  Who are you calling an idiot?!?!?
  
  --
  This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
Oops. by Brian+Recchia · 2010-01-05 06:43 · Score: 3, Funny

Looks like they forgot the ROT13
1. Re:Oops. by Anonymous Coward · 2010-01-05 07:59 · Score: 0
  
  No they didn't, they used it twice, just to be sure!
2. Re:Oops. by Anonymous Coward · 2010-01-05 09:21 · Score: 0
  
  Oh stop. That "they used ROT-13 twice" joke is sooo old. Quite frankly, I am tired of it.
  The solution is to use ROT-13 four times.
3. Re:Oops. by Anonymous Coward · 2010-01-05 09:43 · Score: 0
  
  No, use it p+1 times, where p is a very, very large prime number.
  Just don't write it down anywhere--that'll spoil the security!
4. Re:Oops. by Anonymous Coward · 2010-01-05 10:04 · Score: 0
  
  You're still not standards compliant. I believe that the new standard is ROT-13-256.
IronKey? by bsDaemon · 2010-01-05 06:45 · Score: 1

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?
1. Re:IronKey? by peragrin · 2010-01-05 06:52 · Score: 1
  
  While I have heard of lumber based hard hack decryption methods I haven't heard of anyone using a whole tree before.
  Oh you meant three sorry. Just ignore the guy behind you with the 2x4.
  
  --
  i thought once I was found, but it was only a dream.
2. Re:IronKey? by Wingman+5 · 2010-01-05 06:53 · Score: 1
  
  No, IronKey uses a hardware crypto chip, these drives are all using software crypto. What this group did was bypass the software crypto.
3. Re:IronKey? by RemyBR · 2010-01-05 06:56 · Score: 3, Interesting
  
  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
4. Re:IronKey? by Andy+Dodd · 2010-01-05 07:02 · Score: 3, Insightful
  
  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?
5. Re:IronKey? by Andy+Dodd · 2010-01-05 07:03 · Score: 1
  
  I would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.
  
  --
  retrorocket.o not found, launch anyway?
6. Re:IronKey? by IronKey+Dave · 2010-01-05 08:51 · Score: 5, Informative
  
  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
7. Re:IronKey? by owlstead · 2010-01-05 10:18 · Score: 1
  
  Nah, the ironkey is made from aluminium not from wood (tree products, could not pass the pun). Having looked at the ironkey protocols they seem quite sturdy. Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems (how do you trust the ironkey that is in your mail, for instance).
8. Re:IronKey? by the_enigma_1983 · 2010-01-05 13:49 · Score: 1
  
  See http://it.slashdot.org/comments.pl?sid=1498504&cid=30659002
  If what that poster said is correct, then the only crypto is the software that verifies you entered the correct password, and then sends the "show second partition" command. And the whole lot is pointless, as that second partition itself is not protected in any way, except by running the vendor software itself on Windows.
9. Re:IronKey? by blacklint · 2010-01-05 14:29 · Score: 1
  
  If you can't trust the computer you're on... why do you want to mount encrypted files on it? Wouldn't that defeat the point?
10. Re:IronKey? by Anonymous Coward · 2010-01-05 14:51 · Score: 0
  
  IronKey looks cool, but even it doesn't solve the untrusted host problem. If you plug your USB key into an untrusted machine and type in your password, then all bets are off -- the machine may be logging your keystrokes, or recording the screen. Or just making a copy of all of the unencrypted bits as you access them.
  The only way to be sure that your encrypted data is still *yours* is to make sure you only access it on a computer that you trust. Too bad no one has invented one yet.
11. Re:IronKey? by Jon+Abbott · 2010-01-05 17:04 · Score: 2, Insightful
  
  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
12. Re:IronKey? by Anonymous Coward · 2010-01-06 03:29 · Score: 0
  
  IronKey looks cool, but even it doesn't solve the untrusted host problem. If you plug your USB key into an untrusted machine and type in your password, then all bets are off -- the machine may be logging your keystrokes, or recording the screen. Or just making a copy of all of the unencrypted bits as you access them.
  The only way to be sure that your encrypted data is still *yours* is to make sure you only access it on a computer that you trust. Too bad no one has invented one yet.
  Me thinks that you are missing the point of these drives. They are not going to help when you plug them into a compromised system, no one who is honest is going to even make that claim. What they are for is the piece of mind you get for when the device is no longer in your control (ie: you lose it, leave it on your keyring when you take it to your mechanic, leave it at home and it gets stolen, whatever). If someone gets ahold of your Ironkey, they have 10 tries to guess your password before it nukes itself, and all the data is gone. That is why you spend the big bucks for them.
Article title misleading... by JazzyJ · 2010-01-05 06:47 · Score: 4, Insightful

The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.
1. Re:Article title misleading... by Anita+Coney · 2010-01-05 06:49 · Score: 1
  
  I was going to say nearly the same thing. The encryption was not cracked, merely bypassed.
  
  --
  If someone says he and his monkey have nothing to hide, they almost certainly do.
2. Re:Article title misleading... by Anonymous Coward · 2010-01-05 06:59 · Score: 0
  
  If I RTFA correctly, the real problem is that all of these USB drives have the same encryption key. The Windows program that unlocks it is irrelevant. You could write your own program to send the fixed key directly to the USB drive, but apparently the researchers found it easier to ride on top of the existing program.
  This reminds me of a web application that went through a sound password authentication system only to then "unlock" all the pages by appending "&AUTH=T" to all the query strings.
3. Re:Article title misleading... by jandrese · 2010-01-05 07:02 · Score: 1
  
  If it can be merely "bypassed" then it doesn't seem like it was encryption at all, just password protection. If this is the case, then they might be in trouble for misrepresenting their product in the advertising.
  
  --
  
  I read the internet for the articles.
4. Re:Article title misleading... by Anita+Coney · 2010-01-05 07:14 · Score: 1
  
  As someone else pointed out, all of the USB drives use the same encryption key. SySS engineers discovered that through the Windows program. Now they can simply use that encryption key to bypass the encryption.
  To me this would be like discovering that all Master Locks used the exact same key. So the validity of the lock would not have been compromised, but it would certainly be quite easy to bypass any protection it offers by using one of the widely availability other keys.
  
  --
  If someone says he and his monkey have nothing to hide, they almost certainly do.
5. Re:Article title misleading... by maxume · 2010-01-05 07:25 · Score: 5, Funny
  
  At least they used an industry standard for the key.
  
  --
  Nerd rage is the funniest rage.
6. Re:Article title misleading... by Anita+Coney · 2010-01-05 07:26 · Score: 1
  
  Oh fucking god that was funny!
  
  --
  If someone says he and his monkey have nothing to hide, they almost certainly do.
7. Re:Article title misleading... by mick232 · 2010-01-05 07:31 · Score: 1
  
  This "encryption" is just as effective as locking one's door with the most powerful locks available while leaving the window wide open... As someone else said: the unlock program is irrelevant. The security must be in the USB stick. But it obviously isn't, hence the device (if not the "encryption" per se) has been cracked.
8. Re:Article title misleading... by AvitarX · 2010-01-05 09:21 · Score: 1
  
  ahhh, the good old days of websites.
  Used to be able to set your prices too.
  
  --
  Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
9. Re:Article title misleading... by zuperduperman · 2010-01-05 10:51 · Score: 1
  
  The whole point of encryption is that no amount of software manipulation can bypass it. The data simply cannot be decoded without the key. If the software can bypass the encryption without the key under any circumstances then the encryption has been broken or didn't exist in the first place.
10. Re:Article title misleading... by Anonymous Coward · 2010-01-06 22:45 · Score: 0
  
  No, it seems more like the method the program uses to authorize decryption is flawed. Anything that program does or could possibly do should never ever break the cryptosystem. Knowing how any part of the system works shouldn't break the cryptosystem.
  The key should either come from the passphrase directly or (better) be decrypted by it at the time of authentication.
  No proper cryptosystem has any part where one component says to another "it's ok to decrypt" without needing to specify the key.
Not completely hardware based encryption then? by tibman · 2010-01-05 06:50 · Score: 2, Interesting

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
1. Re:Not completely hardware based encryption then? by John+Hasler · 2010-01-05 06:56 · Score: 2, Informative
  
  > Seems that they did in software what should have been done in the hardware.
  Thereby shaving $.93 off their manufacturing costs.
  
  --
  Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
2. Re:Not completely hardware based encryption then? by zippthorne · 2010-01-05 07:01 · Score: 1
  
  What difference does it make? As long as the data is really encrypted on the drive, either way the cpu is going to have access to the plain text, and in some ways it's better to do the encryption on the cpu: no plaintext over USB foils usb-attached listening devices. Depending on how it's implemented and what you need the data for, it's even possible to never have plaintext in RAM.
  The article seems to imply that the data is not, in fact, stored on the drive using the claimed AES cipher, or if it is, the password that the user enters is not used to generate the key, but instead used to authorize use of a stored key, which may in fact be exactly the same for all affected devices.
  
  --
  Can you be Even More Awesome?!
3. Re:Not completely hardware based encryption then? by tibman · 2010-01-05 07:40 · Score: 1
  
  Yeah, the article didn't really explain the technical details. From what i got the device needs the software to authenticate (hash matching?) then decrypts the drive's contents with a generic key. But they seem to still require the use of the authentication program? Which means they can't just decrypt the contents with a default key.
  Doing decryption on the host is good for the reasons you listed but that would only be for symmetric keys. I would rather not transfer a private a-symmetric key to the host for decryption. If the host is hostile you would not only lose control of your data but your key as well.
  
  --
  http://soylentnews.org/~tibman
4. Re:Not completely hardware based encryption then? by DavidTC · 2010-01-05 08:05 · Score: 1
  
  That's the thing that gets me about USB hardware encryption. I can't figure out the damn point.
  The only possible advantage is that hardware encryption could maybe work without admin privs.
  
  --
  If corporations are people, aren't stockholders guilty of slavery?
5. Re:Not completely hardware based encryption then? by Anonymous Coward · 2010-01-05 08:54 · Score: 0
  
  From TFA:
  
  The USB drives in question encrypt the stored data via the practically uncrackable AES 256-bit hardware encryption system. Therefore, the main point of attack for accessing the plain text data stored on the drive is the password entry mechanism. When analysing the relevant Windows program, the SySS security experts found a rather blatant flaw that has quite obviously slipped through testers' nets. During a successful authorisation procedure the program will, irrespective of the password, always send the same character string to the drive after performing various crypto operations – and this is the case for all USB Flash drives of this type.
  The problem is, encryption isn't done with the user's password. The user's password only unlocks the generic key.
  The exploit found out what the generic key is (and the fact that the key is the same for all USB drives of this type!!!) so they could tell the stick to unencrypt files on the encrypted partition without knowledge of the user's password.
  Process seems to be this:
  1) First time initialization, ask the user for a password, use this to encrypt the generic key
  2) Any subsequent uses of the stick, prompt for the password, decrypt the generic key and use that to decrypt data
  This would have been perfectly fine if they used a different generic key for each drive, but because ALL drives of this type use the same key (even across different manufacturers) it is a big issue.
  Almost seems like they took pointers on encryption from the guys at the MPAA.
6. Re:Not completely hardware based encryption then? by leuk_he · 2010-01-05 09:57 · Score: 1
  
  If the password matching was done in hardware it would have been visible that the disk was tampered with. You would have to replace the program that is in dedicated hardware to send the "open" key to the disk. That is much harder to do, even if it had the same vulnerability.
  FIPS-140 2 does not require much resitance to hardware tampering, only that it is visible that it is tampered with. But then how many people loop up the "140-2" spec (even if it is in a link in the article) and just think it is ok to trust a laboratory. I cannot even find out what labatory F*cked up by looking at the sandisk web.
7. Re:Not completely hardware based encryption then? by Anonymous Coward · 2010-01-05 11:00 · Score: 0
  
  It sounds like that they made a binary patch to the application that always sends the magic "Password is Okay-Dokay" string to the device.
some data by HBI · 2010-01-05 06:51 · Score: 4, Informative

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.
1. Re:some data by mick232 · 2010-01-05 07:39 · Score: 4, Insightful
  
  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.
2. Re:some data by Lord+Ender · 2010-01-05 08:02 · Score: 1
  
  The flaw is in the access software.
  No, it's not. If the hardware gives up the data without requiring the encryption key, the hardware is flawed.
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
3. Re:some data by Anonymous Coward · 2010-01-05 08:06 · Score: 0
  
  Hi, I'm AC from above, sorry about the dickish post. I must have Greater Internet Fuckwad Syndrome today.
4. Re:some data by gumbo · 2010-01-05 08:24 · Score: 1
  
  My reading is that the hardware decrypts and gives up the data when the right key is sent. However, the right key is unrelated to your passphrase, it's a standard key for either that device or all devices (the article is unclear on this.)
5. Re:some data by Anonymous Coward · 2010-01-05 08:40 · Score: 0
  
  Yeah basically every drive is encrypted with the same key that is in the software.
  When the software first asks for a pw when you start putting files on the drive it simply stores a hash of this pw on the drive.
  Now when you want to decrypt the files the software checks your pw against the hash, if it matches it then decrypts the files using the hard-coded password that's the same for all these drives. Someone found this hard coded password. So it's not a hardware issue it's a software issue, which should be fixable (use the users actual pw to encrypt the files!!) but I'd never trust them now even if they fix it cause this is the dumbest thing ever.
6. Re:some data by Alsee · 2010-01-05 09:13 · Score: 2, Insightful
  
  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.
7. Re:some data by Anonymous Coward · 2010-01-05 10:06 · Score: 0
  
  I see another possibility. Remember the old adage "we'll fix it [the hardware problem] in the software"?
  Maybe the crypto in the stick does not work flawlessly. Maybe it doesn't work with some keys that follow a certain pattern, but it does work with this one key that the host software sends down.
  So instead of fixing the HW, they worked around the issue in the SW.
  Of course this is pure conjecture at this point. I favor the hypothesis that someone didn't understand how security by encryption is supposed to work. Don't attribute to whatever what can be explained by stupidity.
8. Re:some data by Facegarden · 2010-01-05 10:09 · Score: 3, Insightful
  
  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?
9. Re:some data by The+Wild+Norseman · 2010-01-05 11:25 · Score: 1
  
  So, if I'm understanding you correctly, what you're saying is that I have a password to unlock access to a jigsaw puzzle that happens to be jumbled up in exactly the same way as everyone else and not that I have a password to unlock access to information jumbled up in my own random fashion. In the former, all a person has to do is get my password because there is (essentially) a map of how to put together the encrypted data to be read, and the latter, there is both my password plus no map of how I jumbled up the pieces so it's more secure?
  
  --
  "A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
10. Re:some data by Jonathan_S · 2010-01-05 15:00 · Score: 1
  
  This hardware is advertised as superduper AES data encryption, but the hardware does not actually bother to use your password to encrypt the data.
  
  FIPS 140-2 actually forbids modules from using a password as a key or from using a password as input into a key generation/derivation scheme. (There are a few caveats and workarounds, but by and large that's the case)
  That restriction makes more sense in situations where the endpoint is trusted and you're worried about the encrypted data in transit, since password derived keys are theoretically much weaker than random keys.
  Still, even with that requirement this type of device would be significantly more secure if the password verification to access the key happened on the USB hardware, not in the software running on the host CPU.
11. Re:some data by Alsee · 2010-01-05 20:28 · Score: 1
  
  In the former, all a person has to do is get my password because there is (essentially) a map of how to put together the encrypted data to be read
  They do not need to get your password.
  With your jigsaw puzzle analogy, either the puzzles are jumbled the same way
  Either the there's one set of public instructions to descramble the puzzle, or the instructions to descramble the puzzle are printed inside the box.
  The hardware is that box with the jigsaw puzzle. Anyone can plug one of these devices into their computer, and they can either use the public instructions or use the instructions printed in the box. They do not need to your password.
  Along with the hardware they gave you some software. That software is programmed to ask for your password before talking to the hardware, but that doesn't matter. You don't need to use their software, or you can modify it. The box itself has no actual protection. You just can tell the computer to talk to the storage device and directly tell it to hand over the descrambled data.
  -
  
  --
  - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
12. Re:some data by Alsee · 2010-01-05 21:58 · Score: 1
  
  That is correct, but I consciously left that technical complexity out of the simplified explanation. It doesn't fundamentally change the point I was explaining. What they should be doing is storing a key-length random garbage on the hardware, hashing or encrypting that random garbage with your password to generate a key, using that key to encrypt the data, and never storing that key anywhere. That way the key itself is properly random, and more importantly the key is not stored on the device. Then you can't decrypt the data without the password.
  Instead they store the naked key along with your data - which for all practical purposes is the same as not encrypting the data at all. Never never NEVER store the actual key along with the data. The ONLY time you ever need to do that is with DRM. And the fact that DRM requires you to store the key with the data just comes back to the point NEVER store the key along with the data. There is no actual encryption if you're storing the key along with the data. DRM fails exactly because it doesn't (and can't) use any actual encryption.
  this type of device would be significantly more secure if the password verification to access the key happened on the USB hardware
  There is some security value in that sort of hardware, but no real encryption security. You could just use that hardware password verification to access stored plain data. Beating hardware to access a stored key is no more difficult than beating hardware to read naked data. If the key is in there with the data then the data is effectively not encrypted at all.
  For most purposes here it doesn't matter if things are done in the hardware or in software. The important thing is that the key is never stored in the hardware or software. You store a random value and use the password plus random value to generate the key.
  -
  
  --
  - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
13. Re:some data by Cerebus · 2010-01-06 03:08 · Score: 1
  
  You're misunderstanding what FIPS 140 covers. FIPS 140 says nothing about authentication systems, only cryptographic modules. I can write a module using a certified FIPS 140 cryptomodule and encrypt everything with the same key-- 0x0 -- and the system is still FIPS-compliant.
  
  --
  -- Cerebus
14. Re:some data by The+Wild+Norseman · 2010-01-06 03:57 · Score: 1
  
  Cool, I think I understand. Thank you for the explanation!
  
  --
  "A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
So instead of challenge response... by calmofthestorm · 2010-01-05 06:52 · Score: 2, Interesting

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.
1. Re:So instead of challenge response... by Anonymous Coward · 2010-01-05 13:41 · Score: 0
  
  It involves a predictable post with the same predictable replies all the time...sort of like Fox news, or slashdot;)
  You must be new here. Every /. post is unique, as indicated by the comment id (cid). The notion that it might be easier to guess the contents of the next post than the next CID is offensive, but each and every /. post is unique and if you try to argue against me I will start posting Dilbert comics that refer to the uniqueness that is you. Schwab over and out.
Standards urgently required.... by Manip · 2010-01-05 06:54 · Score: 1

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.
1. Re:Standards urgently required.... by Anonymous Coward · 2010-01-05 07:34 · Score: 1, Informative
  
  There is a standard way under Linux, its called LUKS + DM-Crypt
  I use it everywhere I go, the kernel (Linux) and a ram disk allow me to boot my own OS on any computer as long as the computer is allowed to boot from a USB key. The OS's partitions are encrypted and so is everything else.
2. Re:Standards urgently required.... by Anonymous Coward · 2010-01-05 08:38 · Score: 0
  
  Truecrypt?
3. Re:Standards urgently required.... by jandrese · 2010-01-05 08:43 · Score: 1
  
  It's something I'd like to see in the USB3 spec: A standard (but optional) way for the driver to pop up a window and ask the user for input. Make sure Microsoft is on board and agrees to patch Vista and Win7 include it in the first release of their USB stack as well. It would be more difficult to support on Linux, but not impossible. Backwards compatibility would be a concern though. Maybe a better place would be in the ATA driver? I certainly wouldn't mind seeing more laptop drives with built-in hardware encryption. Having a BIOS prompt pop up and ask you for the key to your drive would be nice.
  
  --
  
  I read the internet for the articles.
4. Re:Standards urgently required.... by shutdown+-p+now · 2010-01-05 13:00 · Score: 1
  
  The only thing we have that resembles a standard in any way is TrueCrypt. It's not supported natively by anything, but software is available for all platforms, and the format is open.
  In Windows, you have Bitlocker to Go, but it's supported natively (i.e. password dialog pops up when you plug the drive in, and you get full read/write access) only in Win7 Enterprise and Ultimate; there is a free read-only mounter provided for other editions of 7, and XP/Vista, but nothing for OS X or Linux. It doens't seem to have an open spec either. So all in all the adoption should be marginal at best.
  I'm not aware of anything like that for OS X.
Shouldn't trust the host computer AT ALL by georgewilliamherbert · 2010-01-05 06:57 · Score: 5, Insightful

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...
1. Re:Shouldn't trust the host computer AT ALL by maxume · 2010-01-05 07:11 · Score: 1
  
  What exactly do you mean by trust? Should there be fuses in case the host machine attempts to fry it, or should it run on batteries, or what (the digression into power isn't the point, the fact that trust implies many meanings is the point)?
  This implementation was completely borked, but I don't see what problem there is with something like a truecrypt volume on the drive, that the user decrypts using software running on the host computer. That doesn't protect the user from an untrusted machine, but nothing can.
  
  --
  Nerd rage is the funniest rage.
2. Re:Shouldn't trust the host computer AT ALL by lhunath · 2010-01-05 07:12 · Score: 1
  
  Exactly why they are putting fingerprint readers on these devices now (more usable way of entering a passphrase than a tiny PIN-pad on a tiny thumbdrive).
  Also the reason why you should be getting a smartcard reader with a PIN-pad on it instead of a smartcard reader that relies on "drivers" asking you for a pin code on your computer.
  
  --
  ``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
3. Re:Shouldn't trust the host computer AT ALL by tgd · 2010-01-05 07:17 · Score: 3, Informative
  
  If you don't trust the host computer, why would you unlock the device at all?
  Once its unlocked and mounted, anything on the computer can access it anyway.
4. Re:Shouldn't trust the host computer AT ALL by iammani · 2010-01-05 07:21 · Score: 1
  
  Nope, it should simply refuse to supply the host with unencrypted data, no matter what the host tries to do. It doesnt matter if it is fried or dies in a struggle with a malicious host, it needs to stay stupid and open if the key has been given, if not do nothing.
5. Re:Shouldn't trust the host computer AT ALL by theJML · 2010-01-05 07:33 · Score: 1
  
  And I'll never get one of those because I've found here at work, were we use a fairly high end system for scanning fingerprints, that my index fingers cannot be reliably read, and my thumb prints apparently have changed over time... enough that it's had to be re-entered 3 times now, each after failing to recognize me reliably on numerous occasions. I don't want to be locked out of my own data because of something I have no control over (biometrics are horrible for this).
  
  --
  -=JML=-
6. Re:Shouldn't trust the host computer AT ALL by iammani · 2010-01-05 07:46 · Score: 1
  
  If you don't trust the host computer, why would you unlock the device at all?
  The GP talks about the device trusting the host. Not about the user trusting the device or the host. To clarify further, I always use my encrypted device on machines I trust, but it doesn't mean the device should assume any machine it is plugged into is my trusted machine and it can unlock right away.
7. Re:Shouldn't trust the host computer AT ALL by plover · 2010-01-05 07:49 · Score: 2, Insightful
  
  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.
  
  --
  John
8. Re:Shouldn't trust the host computer AT ALL by zippthorne · 2010-01-05 08:03 · Score: 1
  
  Saw it on mythbusters a few years ago. Your solution is at hand:
  Scan your fingerprint and print it out on label paper. Whenever you have to use the fingerprint reader, just slap the printout of your own fingerprint onto the appropriate finger and use that. Since it worked better than 90% of the time on the show, it'll improve your scan rate, while simultaneously demonstrating the worthlessness of the system to your higher ups.
  Note: do not do so if any of your boss, boss's boss, or their boss lacks a sense of humor, or is otherwise slow to wise to things.
  Note to the GP: FINGERPRINTS AREN"T PASSWORD. They're username, at best.
  
  --
  Can you be Even More Awesome?!
9. Re:Shouldn't trust the host computer AT ALL by Lord+Ender · 2010-01-05 08:06 · Score: 1
  
  This is stupid. A password must be 20 random characters MINIMUM to provide just 128 bit key strength. Nobody's going to type such long passwords on a tiny thumb-drive keyboard all the time.
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
10. Re:Shouldn't trust the host computer AT ALL by Rich0 · 2010-01-05 08:21 · Score: 1
  
  You could store the key in hardened memory (resistant to retrieval at the physical layer), and encrypt that key with a shorter passkey.
  A short password is perfectly secure if the device wipes the full key upon some small number of password failures (rendering all data stored on it lost). Of course, that opens up a DOS avenue, but if somebody can get their hands on the key they can already destroy it pretty easily anyway.
  Where this kind of model should REALLY be used is with ATM and credit cards. Put a display and keypad ON THE CARD. The card signs transaction data internally after verifying a PIN entered on the card itself. Now you have a transaction-certifying device that cannot be defeated without an SEM or observing the PIN and stealing the card and using it before it is noticed, and even then it can be made awfully difficult. Plus, the cardholder is now immune to replay attacks (aka double-charges) from retailers/etc.
11. Re:Shouldn't trust the host computer AT ALL by asdfghjklqwertyuiop · 2010-01-05 08:32 · Score: 1
  
  it doesn't mean the device should assume any machine it is plugged into is my trusted machine and it can unlock right away.
  Why? If only the user knows the key, and a given host machine sends the correct key to the drive, then obviously the user has decided that machine is trustworthy by entering the key in to it.
12. Re:Shouldn't trust the host computer AT ALL by clone53421 · 2010-01-05 08:46 · Score: 1
  
  Would it be practical to hash their password with SHA-256 and use that as the 256-bit key?
  Of course, there’s an obvious question: Is it easier to reverse a SHA-256 hash of a 64-bit password than it is to crack the encryption of 64-bit AES-encrypted data? harder? the same?
  (Obviously a short password will always be poor from a security standpoint. However, short of making people use 256-bit passwords, you have to compromise somehow.)
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
13. Re:Shouldn't trust the host computer AT ALL by clone53421 · 2010-01-05 08:52 · Score: 1
  
  “any machine it is plugged into” != “a given host machine sends the correct key to the drive”
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
14. Re:Shouldn't trust the host computer AT ALL by asdfghjklqwertyuiop · 2010-01-05 08:58 · Score: 1
  
  ... which is why it doesn't trust the machine it is plugged in to until the correct key is given.
15. Re:Shouldn't trust the host computer AT ALL by IronKey+Dave · 2010-01-05 09:20 · Score: 3, Informative
  
  You are incorrect. FIPS validated products cannot use the password for key generation. Instead, they must use a random number generator to create the AES key (eg 256-bit key). They password is used to gain access to the key. So a short password can be used, yet you still get 256 bit encryption. As long as brute force password protection counter is also implemented in hardware and cannot be rolled back, you do not need very long passwords (eg. set a 3 try limit). Also, you should encrypt the random AES key with a SHA-256 hash of the password, so that the key isn't stored in the clear anywhere.
16. Re:Shouldn't trust the host computer AT ALL by clone53421 · 2010-01-05 09:21 · Score: 1
  
  ... which is what iammani meant by,
  
  it doesn't mean the device should assume any machine it is plugged into is my trusted machine and it can unlock right away.
  Once the machine gives it the correct key, then yes, unlock. Until then... no.
  Of course, iammani was replying to tgd’s comment, and tgd seems to have been rather confused anyway, so this whole argument is somewhat moot.
  The correct answer to his question,
  
  If you don't trust the host computer, why would you unlock the device at all?
  is “you don’t trust the host computer until it gives the correct password; you do trust it afterward.” (The obvious problem, in this case, is that the “correct password” is the same on every device and is completely independent of the password that the host computer is supposed to use to authenticate the user before giving the device the “correct password”.)
  This discussion really started off with a question of trusting the host computer. Frying or under-powering the hardware, oddly clocking it, etc. are all ways to try to confuse the on-board logic into giving you the unencrypted data. “Trusting” the host computer means “I trust you to either give me the password, or not... no funny business.” Not “trusting” it means you’re resilient to situations where the computer doesn’t act as you thought it was supposed to.
  If I expect 5V and I am given 3V or 6V, I should either not work at all or I should work as I normally would. If 6V will power up my device but causes my authentication system to glitch out and not restrict the access at all, I am “trusting” the computer to give me the 5V it was supposed to give me. If it doesn’t give me 5V, my security completely breaks down.
  Likewise, if you unlock the device when the host computer authenticates the user and then gives you the correct hardware password, and the host can give you the correct hardware password without ever making sure the user knew his or hers like it was supposed to, you are trusting the host computer too much.
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
17. Re:Shouldn't trust the host computer AT ALL by mrmeval · 2010-01-05 19:51 · Score: 1
  
  I'd prefer the device have the option of delete data or force a power cycle on X failed attempts. I would pick which would be acceptable for the data I have.
  
  --
  I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
18. Re:Shouldn't trust the host computer AT ALL by Lord+Ender · 2010-01-06 03:34 · Score: 1
  
  I assumed the FIPS standard at question set cryptographic standards. I did not know it was actually about hardware rate-limiting. It would seem to me, then, that devices compliant with this standard are far less secure. Instead of having to guess trillions of trillions of passwords (which is physically impossible given our current understanding of computing), an attacker would only need to take apart the hardware (which is not easy, but still quite possible).
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
19. Re:Shouldn't trust the host computer AT ALL by Lord+Ender · 2010-01-06 03:48 · Score: 1
  
  No, that is not a solution. Using a hash just means a brute-force attack would need to add a hashing step. Guessing a short password is still easy, as there are exponentially fewer combinations of letters in a short password compared to a longer password.
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
20. Re:Shouldn't trust the host computer AT ALL by clone53421 · 2010-01-06 05:04 · Score: 1
  
  Obviously the length of the password is the limiting factor when it comes to brute-forcing the data.
  What I was wondering is which is harder (or are they no different):
  o Brute-forcing a 64-bit password using its SHA-256 hash
  o Cracking 64-bit AES encryption with the same 64-bit password
  Either way it’s 64 bits of strength, but is one of them harder than the other? You’re sure the AES encryption has a 64-bit key, but you have no idea what the length of the SHA-256 hash’s source was.
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
21. Re:Shouldn't trust the host computer AT ALL by Lord+Ender · 2010-01-07 07:27 · Score: 1
  
  2^64 combinations, whether they be bits or chars, and whether you're hashing or ciphering, means your algorithm will have to run on the order of 2^64 times for a sure break.
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
22. Re:Shouldn't trust the host computer AT ALL by mlts · 2010-01-07 10:43 · Score: 1
  
  This is why I like drives with proven security records like the IronKey, as well as smart cards. The controller doesn't just want a key for decryption, it will stop bad password guesses by either adding a longer and longer delay time before a password request ir processed, or just overtly erase stored keys after someone guesses wrong. Of course, I'm sure some well-heeled organization with an advanced chip fab can take a smart card apart to yank out a stored key, but an organization that rich likely will start with a rubber hose first (cue proper XKCD panel here.)
  Instead of unlimited guesses, a proper security device limits the amount of brute force guesses to 3-20 or so before the curtain goes down.
23. Re:Shouldn't trust the host computer AT ALL by mlts · 2010-01-07 10:47 · Score: 1
  
  This is why some cryptosystems which still use 56 or 64 bit keys with AES use a method called key strengthening. If a 56 key is going to be used in a cryptosystem, it gets hashed a large number of times to delay CPU usage. This way, an attacker has to spend the CPU cycles on the 2^56 keyspace on each key before they can check to see if that is a valid guess or not.
  TrueCrypt does this. It does a number of hashing iterations of the passphrase before it is attempted to be used as a key to open a volume.
Not so much compromised as badly written. by OmniGeek · 2010-01-05 07:25 · Score: 1

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."
Who cares? by static416 · 2010-01-05 07:25 · Score: 1

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.
1. Re:Who cares? by russotto · 2010-01-05 07:34 · Score: 1
  
  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.
  There's a difference between a "tiny vulnerability" and a "hole a blind man could drive an 18-wheeler through". This one is in the latter category.
2. Re:Who cares? by Improv · 2010-01-05 07:35 · Score: 2, Interesting
  
  Some things really are like locking a house - windows passwords, normal unix passwords, etc. With those things, the user expects that someone has or can get access to things anyhow. However, there are many devices that are not so analogous - if there's sophisticated encryption in the hardware and they're selling it as a reasonably secure device, it's more like your neighbourhood bank, where you probably don't expect jane random to read a secret word on the internet to say to the guards that will have them open the vault.
  
  --
  For every problem, there is at least one solution that is simple, neat, and wrong.
3. Re:Who cares? by bcmm · 2010-01-05 07:46 · Score: 1
  
  This isn't like "having a lock to keep honest people honest". It's like putting a lock on your bike which isn't actually attached to anything and hoping nobody looks too closely to keep honest people honest.
  
  --
  # cat /dev/mem | strings | grep -i llama
  Damn, my RAM is full of llamas.
4. Re:Who cares? by static416 · 2010-01-05 07:52 · Score: 1
  
  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.
  There's a difference between a "tiny vulnerability" and a "hole a blind man could drive an 18-wheeler through". This one is in the latter category.
  Perhaps. But the chances of a truck-driving blind man, or even a relatively well-sighted one, finding my particular hole in the first place is virtually zero.
  Practically every security system is vulnerable at some level. All that matters is it's good enough for your purposes.
5. Re:Who cares? by russotto · 2010-01-05 08:30 · Score: 1
  
  Practically every security system is vulnerable at some level. All that matters is it's good enough for your purposes.
  As far as I can see, the main threats to be protected against for an encrypted USB drive are
  1) Misplacing the drive and having some random ne'er do well find it and read the data off of it.
  2) Having a co-worker, family member or other person with occasional physical access to the drive read the data off of it.
  This hole means the encryption substantially fails to protect against either threat. If this hole is acceptable to you, you probably could have used an unencrypted drive in the first place.
6. Re:Who cares? by clone53421 · 2010-01-05 08:48 · Score: 1
  
  Hello there Mr. Security by Obscurity, I’d like you to meet the Streisand effect...
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
7. Re:Who cares? by Hatta · 2010-01-05 08:48 · Score: 1
  
  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.
  Um, she should be concerned. WEP might as well be an open access point, in which case anyone can sniff anything that goes over it unencrypted. All it takes is one person to sniff her email password over the WiFi and they can cause all sorts of headaches.
  What you don't need to do is explain it to her. Just say "WEP is obsolete garbage, trust me".
  
  --
  Give me Classic Slashdot or give me death!
8. Re:Who cares? by Anonymous Coward · 2010-01-05 10:56 · Score: 1, Informative
  
  I found your mom's hole last night. And fucked it hard.
backdoor by Anonymous Coward · 2010-01-05 07:29 · Score: 1, Insightful

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 ).
1. Re:backdoor by maxume · 2010-01-05 07:35 · Score: 1
  
  The NSA probably wouldn't be quite so blatant.
  
  --
  Nerd rage is the funniest rage.
Sigh, no by Anonymous Coward · 2010-01-05 07:30 · Score: 3, Informative

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
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 ... OK pass hashes to correct value
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!
1. Re:Sigh, no by Anonymous Coward · 2010-01-05 09:35 · Score: 0
  
  Your first explanation is still wrong. The software must send the challenge back to the hardware after the password has been hashed in. It is the hardware that must make the correct/incorrect password decision. Otherwise the software can skip steps 5 through 8.
  Also you shouldn't store the password or a password equivalent in plaintext, even in hardware, because it will be recoverable. If you are going to use challenge hashes, then that's what you are doing. Don't do it that way! Instead, hash the password entered by the user to obtain an AES key, and send that to the hardware. If the AES key is correct then the data is accessible, otherwise it is garbage.
2. Re:Sigh, no by shutdown+-p+now · 2010-01-05 12:57 · Score: 1
  
  Your first explanation is still wrong. The software must send the challenge back to the hardware after the password has been hashed in. It is the hardware that must make the correct/incorrect password decision. Otherwise the software can skip steps 5 through 8.
  His first explanation wasn't of how it should work, but rather of how it does work when used "correctly" (i.e. with their software). His second explanation shows precisely how the scheme is vulnerable to skipping steps 5 through 8, which is what the "hack" is.
Insider by dbrez8 · 2010-01-05 07:35 · Score: 3, Informative

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.
1. Re:Insider by maxume · 2010-01-05 07:47 · Score: 1
  
  So if Joe Breacher walks out of the company with a hardware encrypted flash drive, the data is more secure than if he walks out of the company with an unencrypted drive?
  I don't see it.
  
  --
  Nerd rage is the funniest rage.
2. Re:Insider by plover · 2010-01-05 08:05 · Score: 1
  
  You are looking at only a single risk factor. The most prevalent risk is actually that of accidental loss of the drive or laptop. If the lost data is securely encrypted, it might not be subject to data breach reporting laws.
  
  --
  John
3. Re:Insider by dbrez8 · 2010-01-05 08:11 · Score: 1
  
  Of course. If Joe were to drop his flash drive during his travels, someone who finds it will have to subvert the encryption and authentication to get to his unencrypted data.
  
  Now, if you are alluding to Joe stealing this data, then that is a different attack vector. The inside threat. For threats like these you not only need encrypted storage, but centralized management of said storage. There are products available that can issue remote destruction commands to the flash drive, or prevent its use outside of a specific network for example.
4. Re:Insider by vlm · 2010-01-05 08:18 · Score: 2, Insightful
  
  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
5. Re:Insider by the_pointman · 2010-01-05 08:25 · Score: 1
  
  This has been very helpful. Thanks!
6. Re:Insider by Andy+Dodd · 2010-01-05 09:33 · Score: 1
  
  The problem is that it's next to impossible to find these specs. Hell, with many of these drives it's difficult to identify whether it even has true hardware encryption.
  It's a bad sign when the "flagship" products in three different manufacturer's lines had the key management scheme botched this severely.
  Enterprises designing security are basically screwed now:
  1) TrueCrypt has the issue of the fact that, as you say, users can accidentally store stuff unencrypted. Plus there's the admin rights issue.
  2) All of these hardware-based solutions are closed-source/closed-hardware, and as a result don't have the peer review TC does. Without peer review, you get shit like this incident.
  
  --
  retrorocket.o not found, launch anyway?
7. Re:Insider by Anonymous Coward · 2010-01-05 10:30 · Score: 0
  
  Er... we're talking about a single AES decrypt, at a speed that's limited by the Flash read speed and the USB bus speed. AES was designed to be easy to implement in simple dedicated hardware; it doesn't require the kind of power that a graphics card takes.
  The main processor may also be busy doing other things. By offloading the encryption, you can do those other things in parallel with the decrypt.
8. Re:Insider by owlstead · 2010-01-05 10:37 · Score: 1
  
  Yes, just don't buy a secure flash product that does not specify exactly what is done in hardware and using which protocol. You are much better off using open source software encryption if you don't know how the hardware protection is done.
  As for peer review: you can do with a nice white paper explaining the crypto and asking specific questions to the vendor if you don't get anything. As for peer review; yes, if you are a large company you should ask a crypto/side channel specialist for help. A certification (FIPS or using the international common criteria specs) really does help. But you have to make really sure what is tested. There are many secure devices on this world that are only partly certified. Just buying a "certified device" means absolutely nothing. Most of the time you can get a brief description of the tested components at the certification body.
  As for flag ship products: these are basically flash storage vendors trying to make something on the side. Their flagship product is that large memory/low footprint/fast (in that order) product they are selling. They won't be hit too hard when something like this happens. Buy from a security vendor that has something to loose instead; they are bust if their stuff is broken like these dumb-drives clearly are.
9. Re:Insider by dbrez8 · 2010-01-05 10:51 · Score: 1
  
  Well if IronKey Dave is going to plug his wares, above, then why not..
  
  If you're interested in additional secure flash drive options check out Kanguru Solution's Defender Elite products. We use on-chip password matching and 256bit AES(CBC) hardware encryption. The drive can be remotely administered and deleted per my other post via our KRMC web-based administration console. Please don't let the Sandisk products give our industry a bad name
  
  http://shop.kanguru.com/index.php/flash-drives/secure-storage/kanguru-defender-elite http://shop.kanguru.com/index.php/krmc
10. Re:Insider by DavidTC · 2010-01-05 10:56 · Score: 1
  
  The idea that decryption to/from a USB flash drive would have an CPU effect is laughable.
  At best, a flash drive is getting read at about 30 MB/s (And written slower).
  My laptop, a 1.6 Ghz dual processor Intel, can decrypt AES at 100 MB/s. (Incidentally, I have that entire computer encrypted.) My other computer, a 2.1Ghz AMD, gets 230 MB/s.
  If your CPU cannot do AES at 30 MB/s, or if it's even noticeable, you probably should get a new computer. AES was designed to work on modern processors with minimal CPU.
  Of course, as 'someone who works in the secure flash drive space', you're probably aware of all that, and just shilling for your rather unneeded industry.
  
  --
  If corporations are people, aren't stockholders guilty of slavery?
11. Re:Insider by PhunkySchtuff · 2010-01-05 11:36 · Score: 1
  
  Modern encryption algorithms all share a design goal of being fast to implement in hardware. Using a dedicated crypto chip to decrypt data can easily be faster than using a general purpose CPU to do it, particularly if the CPU is performing other tasks at the same time.
  Either way, this argument is pretty much moot as the speed of decryption in these drives is probably bandwidth limited by the flash controller read speed anyway...
  
  --
  Specialist Mac support for creative pros, Melbourne
12. Re:Insider by maxume · 2010-01-05 11:47 · Score: 1
  
  Ah.
  
  --
  Nerd rage is the funniest rage.
13. Re:Insider by Anonymous Coward · 2010-01-05 13:30 · Score: 0
  
  You fail understanding hardware forever.
  Dedicated hardware is just about always faster (and less power intensive) than general purpose hardware simply because the general purpose hardware cannot be optimised for the specific task.
  Why do you think that a CISC instruction set program being translated by a RISC instruction set microcode program executing on a CPU core connected to the disk by 3 layers of general purpose buses (CPU Frontside, PCI, USB) would be faster than a dedicated chip connected directly to the flash via a special purpose bus?
  You do realise that the dedicated computer chips in your digital watch use less power tracking time then the CPU in your desktop system would, right?
14. Re:Insider by zippthorne · 2010-01-06 14:16 · Score: 1
  
  Not to say HW encryption isn't a good idea from a security standpoint.
  It isn't. A device plugged into a laptop usb port probably isn't a problem, but having the decrypt on the drive instead of the cpu means that many more inches where the data is being transmitted in the clear.
  The cpu would have access to the data anyway, to do whatever it needed to do with it, but why pass plaintext through more hands than it needs to?
  Better yet, put the hardware crypto on the CPU die, so that the plaintext doesn't even exist in ram.
  
  --
  Can you be Even More Awesome?!
15. Re:Insider by Anonymous Coward · 2010-01-06 22:53 · Score: 0
  
  You shouldn't be performing password MATCHING in any case, that's just stupid.
  The password (preferably passphrase) should be used to decrypt the actual encryption key, in which case no matter who handles the password, as without the correct passphrase it's not possible to decrypt the data.
  This has been well-known for decades, what excuse do these companies have for being totally incompetent?
16. Re:Insider by mlts · 2010-01-07 11:22 · Score: 1
  
  There is one thing about your drives that is cool -- enterprise level administration. This way, should an employee leave a company (assuming they relenquish possession of the drive), the data is still recoverable.
  Even without that, that type of encrypted drive is something I wish universities and colleges would give out to their professors who store their lesson plans and tests on removable flash media. This way, if someone rips off the drive from a faculty computing place, it won't reveal the answers to upcoming exams. Also, with the enterprise recovery, should someone lose a password, recovery is easy.
I don't get it by Anonymous Coward · 2010-01-05 07:40 · Score: 0

Why are these self-encrypting thumbdrives so popular? I know I wouldn't trust any of them with my data because obviously they need Windows drivers to even access them reducing platform compatibility and, as has just been proven, reducing security. Why rely on some hardware vendor who might have cut corners?
Is it really so hard to run your data through an encryption application before dragging it around?
Even better. Why are people even allowed/able to access data in this manner? If people are working on some government database and need to take the data somewhere, why not encrypt the data before it leaves the system? This way people will not be able to access it in any way until it reaches the trusted destination where it can be decrypted. People could lose it in the commute or even share all their documents with p2p and it wouldn't matter, provided the encryption scheme and keys are strong enough.
1. Re:I don't get it by mlts · 2010-01-07 11:29 · Score: 1
  
  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.
I do that almost every day, actually by Anonymous Coward · 2010-01-05 07:52 · Score: 0

This "encryption" is just as effective as locking one's door with the most powerful locks available while leaving the window wide open
I actually have some of the best door-locks available (Abloy's higher-security residential locks), but habitually leave the bathroom window open, because we don't have a fan in there.
Fortunately, there are enough busy-body retirees in the neighborhood that I can count on one of them calling the police if they see anyone climbing into one of my house's windows. That's what I call "defense in depth".
imho by hellraizer · 2010-01-05 07:58 · Score: 1

if you are that worried about the security of your data , don't allow usb flash drives , period...
1. Re:imho by Frosty+Piss · 2010-01-05 08:36 · Score: 1
  
  The Air Force banned 'em.
  
  --
  If you want news from today, you have to come back tomorrow.
2. Re:imho by HalWasRight · 2010-01-05 13:24 · Score: 1
  
  The US DoD banned flash drives recently because of virus concerns, not IA concerns.
  
  --
  "This mission is too important to allow you to jeopardize it." -- HAL
The result is inevitable... by joocemann · 2010-01-05 08:42 · Score: 1

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).
You are WRONG by omb · 2010-01-05 08:52 · Score: 1

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.
So this is a USB tumb drive? by Anonymous Coward · 2010-01-05 08:55 · Score: 0

Do we get a new USB device profile reserved for such tumb drives?
Expensive Lock, Cheap Casing by driftingwalrus · 2010-01-05 08:57 · Score: 1

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
1. Re:Expensive Lock, Cheap Casing by clone53421 · 2010-01-05 09:27 · Score: 1
  
  Better analogy.
  It’s like having an impenetrable bank vault, but all the bank vaults have the same master passcode.
  This master passcode is written on a slip of paper and stored in a combination safe with a user-customizable code. Once the code is set, nobody can get the master passcode without knowing the correct code, and since the bank vault is absolutely impenetrable, only someone who has the master passcode can get into the vault.
  To complete this facade of security, there’s a full-time guard with every bank vault whose sole responsibility it is to take your code, open the combination safe, get the master passcode, and open the vault with it.
  ...but anyone who knows the master passcode already doesn’t need to crack the combination safe to get it, and the master passcode is the same on every vault. They can shoot your security guard, ignore your silly combination safe with the master passcode stored safely inside, and open the vault themselves.
  
  --
  Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
let's be clear by hesaigo999ca · 2010-01-05 09:03 · Score: 1

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.
Hmm by ShooterNeo · 2010-01-05 09:19 · Score: 1, Insightful

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.
1. Re:Hmm by Parhelion · 2010-01-05 11:06 · Score: 1
  
  There does exist a possibly vulnerability in Russia's nuclear system. Do a little research about 'dead hand' and you will see that it might be possible to design something that would duplicate a 'command rocket' signal that launches other missiles.
2. Re:Hmm by mirix · 2010-01-05 17:20 · Score: 1
  
  I always figured things like that would be quadruple redundant, straight hardware. Just ancient TTL gates, primitive, but pretty foolproof. No software as such.
  
  --
  Sent from my PDP-11
3. Re:Hmm by Slashcrap · 2010-01-05 21:47 · Score: 1
  
  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.
  Are you going to bother finishing it? Only with plot points like that it sounds like it's going to be a load of old shit.
4. Re:Hmm by Chili-71 · 2010-01-06 02:03 · Score: 3, Insightful
  
  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.
Do it 256 times by cromar · 2010-01-05 09:47 · Score: 2, Funny

No, no, no be sure to do it 256 times. That's the most secure (assuming 8-bit char are used).
What's application level encryption? by jonaskoelker · 2010-01-05 10:01 · Score: 1

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?
1. Re:What's application level encryption? by kvezach · 2010-01-05 10:37 · Score: 1
  
  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.
  
  Application level encryption is like a password on your document or RAR file. Open up the program, enter password. If the app has been hacked, so what, the adversary only got access to that particular document (assuming you didn't do anything stupid like assign the same password to all the files on the disk).
2. Re:What's application level encryption? by gad_zuki! · 2010-01-05 10:48 · Score: 1
  
  >Ermm... what is application level encryption?
  That means its handled on an application by application basis and managed by the application opening in. 7zip password files, rar, etc.
So it's like per-file encryption? by jonaskoelker · 2010-01-05 11:22 · Score: 1

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?
Ironkey ftw! by Anonymous Coward · 2010-01-05 11:54 · Score: 0

You get what you pay for... this is why I went with an IronKey!
Re:Barack Obama lied by ghjm · 2010-01-05 12:40 · Score: 1

It's not even good flamebait. The linked article doesn't quote Obama once!
I have only one thing to say. by gbutler69 · 2010-01-05 13:29 · Score: 1

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.
Doesn't matter to the Government anyways! by Anonymous Coward · 2010-01-05 15:45 · Score: 0

Who cares, the Military realized that USB drives were unsecure no matter how you tried to "protect" them, and ordered that we stop using them over a year ago. Besides the security threat, it is an easy way to introduce dangerous software locally onto a system.
Just a simple back door is all by Aging_Newbie · 2010-01-09 02:06 · Score: 1

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