Slashdot Mirror
7 Secure USB Drives Reviewed
jcatcw writes "Computerworld has reviewed seven USB drives that use either encryption or a physical keypad to protect stored data, and found big differences in I/O speeds, ease of use and strength of security. In the case of the drive using a key pad, the editors were able to break open the device and access the data, bypassing the PIN security. They also state that there is little difference between 128-bit and 256-bit AES encryption because neither has been broken yet. The drives reviewed were the SanDisk Cruzer, the Lexar JumpDrive, the Kingston DataTraveler, the Imation Pivot Plus, the Corsair Survivor, the Corsair Padlock and the IronKey Secure USB Drive. The editors chose the IronKey as the most secure."
For the love of /root, use the print link.
We dont want to see a little bit of content over 9 pages!
How are any of these better than using TrueCrypt in traveller mode? The only thing I can think of is that TrueCrypt requires administrator rights to use. And I suppose they may be easier to use for people who don't know much about computers or encryption. But I trust TrueCrypt a hell of a lot more than anything which comes preinstalled on these things.
... and not a single one of them is secure enough for me. I simply want a USB drive that whenever somebody, not authorized by me, touches it, heats their body to like a million kelvins and melt them. A few hundred thousand won't cut it. Until then, Lexar ain't impressing me with their little math based schemes. Unless it causes total vaporization, it's just not secure.
I got a catholic block.
Another analysis of some of the ICs used in popular secure USB tokens (not usb storage devices) can be found here:
http://www.flylogic.net/blog/
They often de-cap the ICs and reverse engineer from a microscope. Really interesting stuff!
twitter.com/gravitronic
For the love of convenience, sanity, and saving money, just use any flash memory drive and TrueCrypt.
"Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux"
Their passwords may no longer be feasible to guess/crack, but if they are compromised in some other way - like snooping - you've guaranteed that they will stay permanently compromised.
When information is power, privacy is freedom.
Corsair Flash Padlock - physical security only: crack it by breaking open the case.
The Corsair Survivor - no security, so TrueCrypt is needed, but setup instructions for TrueCrypt are included.
The Imation Pivot Plus Flash Drive - uses AES-256, but in the insecure ECB mode. Hey, I suppose it's better than ROT13 at least.
The IronKey Secure Flash Drive - "To use the IronKey flash drive, you need to activate an online account." Well, that sounds like a great idea.
The Kingston DataTraveler Secure -- Privacy Edition - "Kingston refused to say what encryption mode the device runs in, citing that it was proprietary information." So that would be ECB again, then. Or maybe something even more pathetic.
The Lexar JumpDrive Secure II Plus - Special proprietary software is required to use this one.
The SanDisk Cruzer Professional - ECB again.
Really short summary: buy a conventional USB stick and do the encryption yourself using free software that you can trust. Because customers cannot tell the difference between a well secured device and some snake oil junk, there is no incentive to make these things work properly.
>north
You're an immobile computer, remember?
Maybe not yet, but presumably, when they are broken, they're likely to be broken in such a manner that 128-bit falls way before 256-bit. So if you only care about someone not stealing your data right now, they might both be equivalent, but if you're worried about someone stealing your data at any time and then reading it further down the road, one is likely to be much better than the other.
Also, I'm sure there will be some debate on this, but I'm not entirely convinced that if someone like the NSA has thrown a few billion dollars at the problem including having a custom-made super computer with their own unique, dedicated processors that are highly optimized for cracking encryption, that perhaps 128-bit AES is already compromised and we simply don't know. The relative advantages of 128 vs 256 bit might depend both on how long you want to keep your data secure, and on who you're trying to keep it secure from.
Can anyone tell me how to set my sig on Slashdot?
The big difference is WHEN they will be broken.
With an algorithm like AES, if you need your data to stay secure longer, use a bigger key.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
...on the loss of your mother, when she happened to pull your USB drive out of one of your pockets before she threw your jeans in the wash.
It doesn't matter that much that there's little difference right now between 128-bit and 256-bit AES. It will matter later. There will almost certainly be time after 128-bit AES is broken but before 256-bit is broken. During that time, the extra 128 bits will mean the difference between secure and insecure. And remember, attackers who can read but not crack your messages can still keep them for later when they're crackable. If your messages still have value at that time, they will crack them then.
Of course, even 256-bit AES will eventually be broken. Everything will eventually be broken. But you have to consider that what you're buying for your encryption dollar isn't secrecy, period, but rather secrecy for a period of time. 256-bit AES buys more time.
--
make install -not war
One of our vendors sent us a demo drive, it was a small enclosure for a laptop size drive, and had a firewire interface. Instead of two firewire ports on the back, it had a firewire port and another identical looking firewire port, which was for the key. I assume the key was merely a very small firewire flash drive with the encryption key on the drive.
The vendor assured us it was properly secured, and I got first crack at it. We were quite disappointed.
I found that while each block on the hard drive WAS encrypted (by the firewire-to-ide bridge board), they were each encrypted using the same key, and no salt. This means that every block was encrypted in the same way.
This by itself probably seems harmless, but it reveals information that should not be revealed. Let me propose a scenario:
I engineer myself a position working at a rival company, and get physical access to their R&D lab, unsupervised. I have a 1/2 hr lunch break of time to find the drive containing the comany's secret recipes. I open the cabinet and find 30 of these secured drives. I was intending on taking the drive and copying it, but christ, there's 30 of them. I brought along a portable 1gb drive which would fit maybe 5 of them, but not 30.
So which ones do I copy? The bad news... I can tell which ones to copy.
I can look at the blocks on the disk and immediately spot any drives that have not been formatted, because their first 50 blocks are all going to contain the same random garbage in each block. OK that narrows it down to 8 drives. I can only image 5. So I look further.
I can now tell which drives are formatted FAT32, APS (apple HFS), etc. I can do this because I know what blocks are zeros (because there are a lot of them and they are all the same) and so I can tell which bytes in the other blocks are NOT zeros, and this makes determingin format AND used space trivial. I know the drive I'm looking for is FAT32, and that breaks it down to 3 drives. I could just go with the one drive that clearly has 30 gb used on it, and skip the others that appear very lightly used, but this has given me plenty of time so I happily image the 3 drives to my portable and sneak out in under 20 minutes.
Now of course we have to break the data, but the moral of the story here is, they allowed me way too much information from the supposedly secure drive, and it was enough to make what could have been a fruitless attempt into what may be a very successful attempt.
I brought this issue to the manufacturers, and was brushed off. They did not consider this a problem. riiiiight.
I work for the Department of Redundancy Department.
"This requires trusting the OS with your password, ..."
All drives except those with separate keypads trust the OS with the password. Hardware keyloggers will see the password if there is no separate keypad. But that's not the problem. The problem is losing the drive. Hopefully the drive would not be lost in the same place someone is using a key logging device.
Root is required only to install TrueCrypt, not run it.
Most of it sounds great, but "If someone does happen to gain access to your flash drive and they fail to type in the correct password more than 10 times, IronKey will self-destruct, permanently locking out users and wiping out all the data on the drive."
Seems pretty easy for someone to destroy the drive/data if they wanted to. Even accidentally destroy the drive/data.
FYI I am using an IronKey (4GB Enterprise edition) right now on a Mac OSX box with the key formatted with FAT32.
It works wonderfully on the Mac for basic encryptio/decryption/file access, and I am also mounting it to a WinXP virtual image within VMWare Fusion. The VM XP thing works flawlessly, including auto-mounting, and I initialized the key on the VM prior to using it on the Mac.
The company promises Linux drivers soon.
What if you want to read the data on a computer that doesn't have TrueCrypt installed?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
One of them won't even tell you the full details of the algorithm they use, saying it's 'proprietary' which is another word for "It's secret and it doesn't actually work." in the security industry.
Not only that, but each and every single one of them uses software on my computer to do the encryption. I can get the same thing by using decent drive encryption software like dm-crypt and LUKS. And those are publicly viewable and peer reviewed so they're much more likely to be secure than some stupid random algorithm slapped together by a few techs they paid to do it out of the spare change jar. So that's just totally silly.
I was hoping for something where the encryption was really done in the drive itself and it required me to enter something on a little keypad attached to it in some way in order to decrypt anything. I bet the one that sounds like it might do that just causes the USB device to refuse to talk to the world unless you enter the right thing on the keypad. You could pull that thing apart, attach a few leads and I bet you could read every bit off there (including the PIN) in the clear.
Security isn't that hard to do right. But nobody seems to want to bother. They just want to slap the word on their product, make the user jump through a few hoops and call it good.
Need a Python, C++, Unix, Linux develop
It is hard to say what is better, a long password that has fewer obscure characters, or a shorter password that has a strict password quality policy.
It is not hard at all to say when discussing Windows systems. Passwords of less than 15 characters can be trivially cracked by OphCrack - no matter how complex they are, assuming the attacker has the appropriate rainbow tables. Passwords greater than that length cannot be cracked this way.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
A few years ago I bought a 1 gigabyte BioStik and it works really well. It can read 2 fingerprints. The only down side is, you need to actually issue the linux 'eject' command (or in windows remove safely option) or else the filesystem basically gets corrupted. Other than that, it's a great stick and quite secure. It has anti-tampering on it, so if someone tries to open it up, it immediately wipes the disk clean.
TrueCrypt can put data into files, rather than using the whole drive. Put TrueCrypt on the drive as well as the file, and run it from there. So what if they know what program you encrypted it with, as long as you have a properly strong password, it won't matter.
But I'd be wary using a secure key on any public PC... you can't trust the PC, and the key could easily be compromised if the machine is. The chain of security is only as strong as it's weakest link.
My blog. Good stuff (when I remember to update it). Read it.
That is true, because by default Windows Server 2003 and XP keep a LAN Manager password hash. This can be fixed by going into Group Policy, enable the "Do not set LAN manager hash on next password change" option, then changing all passwords.
Thankfully this is set differently by default in both Windows Vista and Windows Server 2008, so the LAN Manager hash is worthless. Of course, this doesn't mean that one can ignore physical security completely, but it raises the bar for password cracking.
To be safe, blincoln has the right idea -- minimum 15 characters, so even if the LAN Manager compatibility gets enabled for some $DEITY-forsaken reason, the passwords are immune to rainbow table cracking.
Long term, unless done already, MS needs to take a page from TrueCrypt's playbook [1], and perhaps offer the ability for passwords to be encoded with a varying number of rounds, (for example, SHA-512 hashing a password with a random salt, repeating a million times.) This will slow down brute forcing as an attack vector significantly.
Hint: 72693 transistor hardware AES implementation at one word of plaintext to one word of ciphertext per cycle runs much faster than 4978652193 transistor Pentium 4 decoding and executing an instruction set. Same with a dust-size ARM. Using a simple chip that does 1 round and has to be run 16 times might just get you 1MB/s at 4MHz. The chip can be simplified down to having a lookup table taking 4096 bytes of ROM to do 3 stages of a round, operating on 32-bit words in 4 stages; this will block the circuit doing that operation for 4 cycles though, so you could implement the circuit 4 times (4 lookup tables?) for 1MB/s at 1MHz. Also the final XOR would be 4 32-bit XORs or (better) just one 128-bit XOR.
With the 4xLookup optimization and the 128-bit XOR in a pipeline, this simple chip would do one AES block per 16 cycles. By duplicating the circuit and pipelining, you would do 2 rounds per clock. Get creative with it.
Support my political activism on Patreon.
A friend of mine ordered the Iron Key a few months ago. It didn't work at all, so he sent it back for a replacement. The replacement broke after 3 days. I would think reliability should be incorporated into the 'security' factor. If the data is lost, even if its into thin air, that's not very secure at all. SO the question is: was my friend's experience with the Iron Key an isolated incident/bad luck, or is there indeed a reliability problem (and thus a security problem) with the Iron Key??
Some admins are just working in larger environments where they can't sit down with hundreds or thousands of users and hold their hand and teach them nifty memorization tricks to help them remember their sufficiently complex password.
The Disk encryption theory article on wikipedia lists some modes of operation that are practical for disk encryption, most notably XTS, which is used by truecrypt. Wikipedia also lists different disk encryption apps, and the modes of operation they use.
SCO employee? Check out the bounty
The winner was the same product that I see advertised here on slashdot while typing this response.
I'm sure that's just pure coincidence, though.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Any good flash stick should be doing wear leveling in the controller chip so the filesystem you use shouldn't matter as much as it would with directly connected flash chips.
Microsoft's encryption uses some weird public key stuff that is tied to the user hash (i call it a hash - mean that big numbery-string thing that shows when the user isn't in the local systems SAM database)
Basically, the whole point of it is that you can't take some random encrypted drive somewhere else and read it - kind of defeats the purpose of using it on a flash drive, unless you want it (or the specific paths that are encrypted) locked to the PC.
Yes, the NTFS encryption is crap, unless you set up windows JUST RIGHT and then encrypt it, or use the 'crypt' command line utility (built in) to update it all.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Yes, the problem with Microsoft's NTFS encryption is that it is tied to the operating system User Name and password. Crazy!
That means if the user account is damaged, the data is lost forever, unless the user info can be restored from a domain server.
There are complaints on MS user groups from people who have lost months of hard wok that way.