Encryption Cracked On NIST-Certified Flash Drives 252
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."
It's not just the algorithm (Score:3, Insightful)
One weakness in the entire crypto-system can bring the whole thing down.
Re:It's not just the algorithm (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.
Re: (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
Re:It's not just the algorithm (Score:5, 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.
Re: (Score:3, Insightful)
How does this differ from Truecrypt? (Score:3, 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.
Re:How does this differ from Truecrypt? (Score:4, 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.
Re: (Score:3, 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.
Re: (Score:3, 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).
Re: (Score:3, 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?
Re: (Score:2)
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,
Re: (Score:3, 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.
Re: (Score:3, 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(co
Re: (Score:2)
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 a
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3, 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.
Re: (Score:2)
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.
Re: (Score:3, Interesting)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3, Funny)
More to the point, what's the point of a super lock if you're going to tape the key to the door?
Re:How does this differ from Truecrypt? (Score:5, 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.
Re: (Score:3, 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.
Re:How does this differ from Truecrypt? (Score:4, 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:
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.
Always sends the same character string (Score:2, Funny)
"12345"
Re:Always sends the same character string (Score:4, Funny)
That's the stupidest combination I've ever heard in my life! The kind of thing an idiot would have on his luggage!
Re: (Score:2, Redundant)
"12345"
That reminds me that I have to change the combination on my luggage.
Re: (Score:2)
I've got the same combination on my luggage!
Oops. (Score:3, Funny)
Do it 256 times (Score:3, Funny)
IronKey? (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
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.
Re:IronKey? (Score:5, Informative)
Re: (Score:3, Insightful)
Thanks for posting this update. I've always had respect for IronKey and that level of respect just went up a few notches.
Re:IronKey? (Score:4, 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.
Article title misleading... (Score:4, Insightful)
The encryption hasn't been cracked, it's the program that unlocks it that's been compromised.
Re: (Score:2)
I was going to say nearly the same thing. The encryption was not cracked, merely bypassed.
Re: (Score:2)
Re: (Score:2)
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.
Re:Article title misleading... (Score:5, Funny)
At least they used an industry standard for the key.
Re: (Score:2)
Oh fucking god that was funny!
Not so much compromised as badly written. (Score:2)
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...
Not completely hardware based encryption then? (Score:3, 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 [atmel.com]
Re: (Score:3, Informative)
> Seems that they did in software what should have been done in the hardware.
Thereby shaving $.93 off their manufacturing costs.
Re: (Score:2)
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 p
Re: (Score:2)
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
Re: (Score:2)
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.
Comment removed (Score:5, Informative)
Sigh, no (Score:3, Informative)
Correct stuff was already explained above by someone else:
http://it.slashdot.org/comments.pl?sid=1498504&cid=30658760 [slashdot.org]
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
Re:some data (Score:4, Insightful)
Re: (Score:2)
No, it's not. If the hardware gives up the data without requiring the encryption key, the hardware is flawed.
Re: (Score:2)
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.)
You are WRONG (Score:2)
Put the real problem is whose head will roll for this, This needs to attract punitive damages.
Re: (Score:3, 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 whi
Re:some data (Score:4, Insightful)
First, here's the NIST list of approved 140-1 and 140-2 modules [nist.gov].
Note that they approve the module and not the access software. The flaw is in the access software. Therefore, 140-2 compliance or approval isn't proof that your data is safe. It just means that some approved form of encryption is implemented by the crypto module. It appears that the modules in question were given some form of TEMPEST examination as well, but once again, that means nothing in terms of the access software.
Actually, the flaw is indeed in the modules. They ALL use they same unlock key. I'd say that makes them flawed. The software is not helpful - it just obscures the fact that they all use the same unlock key by asking for a unique password that it converts to the common unlock key - but as unhelpful as the software is, it isn't the issue.
To put it another way, there is no way of fixing the software to change the fact that all of these drives can be accessed with one known key, which means its not the software that is broken, its the keys.
Of course, it doesn't help that the software gave up that key, so that is certainly a flaw but if the modules all had different keys it wouldn't be as helpful and it certainly isn't as big as a problem as the modules all being the same!
-Taylor
So instead of challenge response... (Score:3, 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.
Standards urgently required.... (Score:2)
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.
Re: (Score:2)
Shouldn't trust the host computer AT ALL (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...
Re:Shouldn't trust the host computer AT ALL (Score:4, 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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
“any machine it is plugged into” != “a given host machine sends the correct key to the drive”
Re: (Score:3, 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.
Re: (Score:2)
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.
Re: (Score:2)
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 dis
Re: (Score:2)
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.)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
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
Insider (Score:3, Informative)
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.
Re: (Score:3, 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"
Re: (Score:2)
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.
The result is inevitable... (Score:2)
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
Re:Truecrypt (Score:5, 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.
Re:Truecrypt (Score:5, Insightful)
This problem is only that of "closed source" and not one of "Windows only". It would be equally insecure on any OS.
Re: (Score:2)
Re: (Score:3, 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.
Re: (Score:2)
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...)
Re: (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.
Re:Truecrypt (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.
Re:Truecrypt (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
Re: (Score:3, Interesting)
Re: (Score:2)
If they marketed it as encrypting the data on the drive then yes, or at least false advertising.
Re: (Score:3, 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...
Re: (Score:2)
Re: (Score:2)
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 vend
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Hello there Mr. Security by Obscurity, I’d like you to meet the Streisand effect...
Re: (Score:3, 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 o
Re: (Score:2)
Re: (Score:2)
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".
Re: (Score:2)
Re: (Score:3, Insightful)