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

Comments

But

[Anonymous Coward]

But do they run linux?

For the...

[Creepy Crawler]

For the love of /root, use the print link.

We dont want to see a little bit of content over 9 pages!

Re:For the...

[MobileTatsu-NJG]

For the love of /root, use the print link.

We dont want to see a little bit of content over 9 pages! Great. Let's Slashdot a few sites with their print link and cause them to make those annoying, too.

Mass Storage Devices

[William Robinson]

Not sure....How different it is from security of any other mass storage device?

Solution:

[RandoX]

Crack open the PIN-based one, fill with epoxy, reseal.

Re:Solution:

[leuk_he]

It is very doubtful it is any good...

See this encrypted usb HARD drive:

http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136/0

Some 128 bit encryption was involved, but not implemented a correct way, so it was easy to decrypt beacuse only a xor key was involved.

Re:Solution:

[Chyeld]

If he was able to remove completely the number pad and simply trick the main board into thinking the correct combination had been entered, it's a fairly safe bet that snipping off the numberpad and using the leads that used to go to it would work just as well. Your epoxy solution would only cover part of it. Plus, IF the data is being storied unencrypted and the only issue is physical access, eventually epoxy can be removed. Once that happens, you are pwnt.

Print Link

[phantomcircuit]

http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9062527

TrueCrypt

[ceswiedler]

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.

Re:TrueCrypt

[CodeBuster]

It only requires administrative rights to use if you are trying to use it on another computer besides your own laptop while traveling, but anyone who does that without the dip switch set to write protect and the entire volume encrypted is just asking for trouble anyway. The ideal solution is to simply encrypt the entire volume on the USB thumb drive and then set the dip switch to write protect when it is not plugged into your laptop OR you are not using it for writes. That way if the thumb drive is lost it will be useless, other than as a storage device, to anyone who finds it (i.e. they may format it and use it themselves but your data will be safe). Why would you want to trust the closed source USB thumb drive vendor's encryption software when TrueCrypt is usable, powerful, proven, and open source? In fact, if I were a thumb drive manufacturer then I would simply distribute TrueCrypt with my thumb drives and be done with it.

Re:TrueCrypt

[KlaymenDK]

Well the Padlock one is better because it's platform agnostic.

The Ironkey sounds really good, but since I need to swap between a Windows and a BSD pc, it's effectively useless.

With TrueCrypt you could make it work cross-platform, but you'd need non-Windows host computers to have TrueCrypt already installed.

Re:TrueCrypt

[click2005]

In fact, if I were a thumb drive manufacturer then I would simply distribute TrueCrypt with my thumb drives and be done with it.

Corsair already does on some of their drives (like the Flash Voyager 32Gb)

Re:TrueCrypt

[hummassa]

I trust TrueCrypt a hell of a lot more than anything which comes preinstalled on these things. Funny thing is, Survivor comes with TrueCrypt preinstalled... :-)

Re:TrueCrypt

[fishbowl]

>How are any of these better than using TrueCrypt in traveller mode?

There is a possibility that the average IT decision maker will have heard of one of them. The de-facto media embargo against Free software does not help.

What product available through your wholesale office supply dealer uses TrueCrypt? As an independent person you know better than to base a security decision on a Computerworld article, but what if your professional hands are tied? (My answer to this is "get promoted to a level where you have the authority to untie them").

Few who complain about IT management ever seem willing to listen to my solution :-)

Re:TrueCrypt

[heartless_]

I run TC in traveler mode all the time without Admin rights and I've never figured out why it says you need them to run... maybe I am missing something?

Re:TrueCrypt

[houghi]

Cold Boot Attacks on Encryption Keys

Re:TrueCrypt

[ACMENEWSLLC]

Am I the only one that gets corrupt TrueCrypt volumes on my USB drive because the drive will fail to dismount when I right click in TrueCrypt and select dismount? Usually this is caused by the AV engine stuck with a lock on a file. I quit using TrueCrypt for my entire 160GB USB drive due to this, and now just use it on static content.

Re:TrueCrypt

[Drawsalot]

I don't know about BSD (guessing here) but the IronKey works well with my Vista PC, Windows XP boxes and my Mac running OS X. I think it would work with your BSD.

Re:TrueCrypt

[rduke15]

You can install TrueCrypt as an admin, and then you can use it without admin rights on that machine.

or

You can also not install anything, and just start it ("traveler mode"), but it must then be able to add it's driver when starting. And that needs admin rights.

So unless the OS already knows about that driver, you do need admin rights.

Re:TrueCrypt

[Amiralul]

Needing Administrator privileges to see the TrueCrypt encrypted drive, is a huge drawback. I mean, not every Joe have admin rights on his PC (or even knows his admin password) and if I want to use my USB on his computer... Well, I can't.

Yeah I glanced these over...

[explosivejared]

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

Re:Yeah I glanced these over...

[blincoln]

heats their body to like a million kelvins and melt them.

That extra 273 degrees makes the critical difference between this approach and lesser celsius-based systems.

1210.

[shamer]

choose from 10, or follow the link for 12 models.

http://www.informationweek.com/story/showArticle.jhtml?articleID=206901163&cid=RSSfeed_IWK_All

Another analysis (similiar vein)

[th0mas.sixbit.org]

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!

A false sense of security is actually worse

[blhack]

This is not a good thing.
How many of these devices are going to have the equivalent "1111" or "1234" or "8520" (the center of the keypad that users think is just OH so clever) as the password?

At least if the person is smart enough to know that they NEED encryption on their disk and they don't have it, they'll [hopefully] be smart enough not to just leave the thing laying around.

With this thing, it gives users a false sense of security...now they don't NEED to worry about losing the thing because "Oh, its ENCRYPTED!"
No amount of hardware will EVER replace proper training.

Example:
At first, we used a pretty strict password policy at work...+8 characters, numbers, symbols, capitols etc. all required. YOu have to change your password every month.
This is a security DISASTER! Everybody will set their password to like "jason1!" the first month, then "jason2@" the next month", then "jason3#" the next month and so on. Finally I changed the policy. Now a user can request a password that never changes, so long as it meets *MY* requirements...

Re:A false sense of security is actually worse

[moderatorrater]

Now a user can request a password that never changes, so long as it meets *MY* requirements... That it be so complicated that they have to write it on a post it note and put it on their monitor?

Re:A false sense of security is actually worse

[Jah-Wren Ryel]

Now a user can request a password that never changes, so long as it meets *MY* requirements... Seems like you have just shifted the problem.
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.

Re:A false sense of security is actually worse

[Anonymous Coward]

Now why did you go posting my pins to my three bank accounts... DRAT....

Re:A false sense of security is actually worse

[xrayspx]

At first, we used a pretty strict password policy at work...+8 characters, numbers, symbols, capitols etc. all required. YOu have to change your password every month. This is a security DISASTER! Everybody will set their password to like "jason1!" the first month, then "jason2@" the next month", then "jason3#" the next month and so on. Finally I changed the policy. Now a user can request a password that never changes, so long as it meets *MY* requirements...

I've found a lot of Security Noobs do this, and it's friggin annoying. It leads to people emailing their password to themselves, putting it on sticky notes, business cards, etc.

A policy of a password that changes and meets requirements is a Good Thing, but 30 days is too quick, and if every password has to look 1337, no one will ever remember them. Yes, passwords can be trivially cracked on good hardware and administrator access to a Domain Controller. You know what? Lock down that Admin access and don't let 80% of your company be Domain/Local admins.

Re:A false sense of security is actually worse

[mlts]

Here is a compromise which I saw on a blog, but forgot where: The password rule was a password change every 45 days, and one greater than 15-16 characters, but the complexity requirements were very lax (pretty much disallowing all "1"s or "abcd".) This allowed users to have long, but fairly easy to remember stuff like "1duffbeervs.2skittlebrau". With a decent access control system, someone trying to brute force passwords would either force the account to lock, start getting tarpitted where each access takes longer and longer, or the source where the brute forcing is coming from would get locked from accessing the login server.

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. I personally choose the longer passwords, although length is not everything, and if long passwords are implemented with too lax a quality meter, dictionary cracking would make the length absolutely pointless.

As for USB drives, why can't one of the USB manufacturers that does the two drive trick also add a hook in for generic OS support. For example, a file that one can write to which the drive would use as a pipe. For example, I stick in a secure USB drive, edit "password" which is a zero byte file on there, type in the password and save the file, and it would grant access. Same if I did an "echo 'password' > /usbdrive/password" on a UNIX machine. Of course there are issues with writable and read-only drives.

Re:A false sense of security is actually worse

[Sancho]

So modify the policy so that if the password is compromised, it must get changed. If it is changed to something which fits HIS requirements, it is made immune to the periodic change requirements.

Honestly, I figured that this would be obvious, however I underestimated the pedantic nature of some people to pounce on the tiniest flaw in a post (most likely the mis-use of the word "permanent".)

Re:A false sense of security is actually worse

[blhack]

Wow, this portion of my post was really just a footnote, but everybody seems to be responding to it...so I'll bite.

Maybe most admins are really detached from their users and never talk to them/hate them/think they're stupid/whatever, but I'm not.

I TALK to the users, and TRAIN them on WHY they need to choose a good password. If they want to create a new one, and have it never change, they can come and talk to me. I'll sit there and help them remember it for a few minutes, explain WHY they aren't supposed to write it on a post-it note, and what will happen if they do (somebody could log into their account and they will be liable for it), etc.

Are most admins really that arrogant? OMG STUPID USERS THAT JUST DON"T GET IT!!! LOLZ IF ONLY THEY WERE AS SMART AS ME!!! HAHAHAHAHA
Seriously guys, get a life.

Re:A false sense of security is actually worse

[blincoln]

Yes, passwords can be trivially cracked on good hardware and administrator access to a Domain Controller. You know what? Lock down that Admin access and don't let 80% of your company be Domain/Local admins.

Or you could require 15+ character passphrases and essentially eliminate the problem altogether, along with there being no real reason to force your users to use anything other than lowercase letters.

Re:A false sense of security is actually worse

[blincoln]

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.

Re:A false sense of security is actually worse

[Mr Z]

At work, they generate passwords FOR us, and then we get to pick out of a list which one we want. 8 characters, alphanumeric, mixed case. They expire every 6 months or so. So, I end up with passwords like f3nqDe4C* and the like.

I usually DO have to write it on a Post-It to remember the MixEd cAsE for at least a couple days, but that stays in my wallet, and gets thrown out pretty quickly. Such fun.

--Joe

* Not an actual password, but similar in character to passwords I've had.

Re:A false sense of security is actually worse

[mlts]

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.

Re:A false sense of security is actually worse

[bluefoxlucid]

although length is not everything

Who let the girl on slashdot?

Re:A false sense of security is actually worse

[dave562]

Are most admins really that arrogant? OMG STUPID USERS THAT JUST DON"T GET IT!!! LOLZ IF ONLY THEY WERE AS SMART AS ME!!! HAHAHAHAHA Seriously guys, get a life.

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.

Re:A false sense of security is actually worse

[xrayspx]

We're on the same team. I'm anti-over-complicated passwords that change every 4 days. I do agree that they need to change occasionally due to keyloggers, but 60 or 90 days is probably fine from an 80/20 standpoint. What I was getting at with Security Noobs is that they get a little responsibility and change the password policy to 14 character mixed-case alphanumeric with a minimum of 1 number and 2 "special characters", and have the password change often. I think that's a huge mistake that leads to sticky notes and users mailing their password to their GMail account.

Re:A false sense of security is actually worse

[blhack]

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. Then you need to either learn to better manage your time, or you need to talk with your boss and get her/him to hire you some help.

Re:A false sense of security is actually worse

[dave562]

And you need to get out in the real world where you have more than a handful of users to deal with. You're obviously rather inexperienced when it comes to dealing with any good sized organization. In the real world, where you have more than a couple of departments and a handful of users, there are employee policies and handbooks that are given to new employees. The policies in there include IT policies, and those IT policies include password policies. The IT staff, department heads and HR have already gotten together and sorted the issue out. The password is going to meet certain complexity requirements and that is that. There isn't going to be any hand holding. There isn't going to be any explaining the rational behind the decision. If people want to access the network they are going to follow the password policy. That's the reality of corporations with multiple sites and hundreds of users spread across the country/globe. If you are working a quiant environment where you can be all lovey dovey with your users, more power to you. Just because that is your reality doesn't make people who don't have time to sit down with every user in an organization of hundreds or thousands of users bad administrators. In fact, I'd say it's just the opposite. If you have to meet with all the new users and explain to them how to come up with a good password instead of being able to just give them a document that has already been created explaining those things to them, then you're the one who needs some better time management skills.

Re:A false sense of security is actually worse

[Jah-Wren Ryel]

So modify the policy so that if the password is compromised, Just how do you intend to find out that it was compromised?

Honestly, I figured that this would be obvious, however I underestimated the pedantic nature of some people to pounce on the tiniest flaw in a post (most likely the mis-use of the word "permanent".) Are you high?

Re:A false sense of security is actually worse

[blhack]

Calm down.

Yes, obviously I DO work in a much smaller environment than I could. But guess what? I LOVE my job, I make more money than the VAST majority of people that work in my field, I get to work my own hours, I get to work on the projects that I WANT to work on, and if somebody tries to implement something stupid, I can change it.

Wanna know why?
Because I am the type of person that DOES take the time to sit down with users and explain WHY things are the way they are (or, if necessary, schedule a training meeting with their department heads and allow the knowledge to trickle down). Every person in the company (we're small, only about 220 employees) has my cell phone number and email address written on a paper that I gave them explaining why some common problems will occur, and how to fix them. The times that I HAVE been called at 3:00am (which is VERY VERY rare...training can go a LONG way) I am very polite to the person on the other end of the line.

Companies notice things like this.
Appearantly you work in a job that you hate, where you probably get no recognition for anything that you do (if you are allowed to do anything other than what is written in your, appearantly sacred, employee handbooks).
My suggestion to you would be to increase your skillset, and go find another job.
Also, practice interacting with other people other than what you can do online. This is absolutely the NUMBER ONE thing that you can do that will increase your pay/responsibility.
Good luck.

Re:A false sense of security is actually worse

[TheLink]

No it should be complicated so that they write it on a piece of paper and put it in their wallet or purse.

Then the IT security policy is:
1) Keep your wallet/purse and their contents safe.
2) If your wallet/purse goes missing, call up IT (after calling the banks to cancel your cards etc) to disable your account till you can be reverified.

If you do this, even if they are given new passwords every 3 months, there's no big change to their workflow.

Re:A false sense of security is actually worse

[sjames]

What many admins don't understand is that the relation between actual security and the difficulty of authorized access procedures is far from linear. In fact, it usually has a sharp dropoff at one or more thresholds of pain.

From a practical standpoint, it means a password can only get so complex or rotate so often before it WILL be written down no matter what policy says. If policy strictly forbids writing it down, it will be written down and left in any of a number of 'clever' places that anyone can guess. If the policy says write it down and keep it only in your wallet or purse, you'll get more meaningful compliance. You might get some traction teaching users to make up silly phrases and bits of bad poetry and taking the first letter or two from each word (perhaps with 1337 spelling). It just might sound whimsical or fun enough to get better passwords in use. Of course, that only goes so far, so you may also need to allow simpler passwords that last longer in order to INCREASE security.

Threatening them with responsability for break-ins only goes so far, because guess what their boss and HR people do with THEIR passwords!

Adding an easy to use second factor can be quite helpful. A small key device adds no extra burden to the user since they already keep track of their car and house keys, one more won't likely hurt.

The same applies to physical security. A simple access card system will get 100% compliance. Add man traps and "enter your 2000 digit PIN in 3 seconds or we release the nerve gas" and someone else will add bypassed fire exit alarm and a brick.

Re:A false sense of security is actually worse

[sjames]

The password is going to meet certain complexity requirements and that is that. There isn't going to be any hand holding. There isn't going to be any explaining the rational behind the decision.

And if they're late to dinner, no fruit cup!

The policy manual should include the strategy for memorizing a good password. Even so, make it too complex or changing too frequently and they WILL write it on a post-it and stick it on their monitor. So will anyone responsable for spotting and punishing the infraction. The real art to security is understanding that compliance falls off sharply beyond a threshold of pain.

Consider, speed limits are clearly posted. They are the LAW. If you ignore them, you will get a ticket. So naturally, we have near 100% compliance right?

Considering that you (as an IT person) don't have the power to lock employees up or carry a gun in the office, what are the odds you'll get better compliance?

Re:A false sense of security is actually worse

[dave562]

The original point I was making is that not everyone has the luxury of sitting down with their users to explain every nuance of why everything is a certain way on the network. That's it. I was just pointing out that not everyone lives in the reality that you live in, or has the luxury of doing things the way you do them.

Now, you could have just accepted that and moved on, but you didn't. You took it as some sort of attack, probably because you were expecting it given that you were basically bad mouthing anyone who isn't compassionate enough (or whatever your meta reason was) to not hand hold their users through basic security practices.

From there you went on to assume that both my time management skills and my boss both suck. In reply to my reply to that, you now seem to think that I hate my job, that I don't get any recognition for what I do, and that I need to increase my skillset to find a better job. Oh ya, I also need to practice my interpersonal interactions.

Now having laid out all of your gripes one by one, I could go through and refute them, and point out how when you assume you just make an ass out of u and me, but there isn't any point. It's glaringly obvious that you're right in your own mind and everyone should just do things the way you do them. Thanks for contributing. I'll make sure that you get your nod for uber sysadmin of the year.

Re:A false sense of security is actually worse

[xrayspx]

Thank you, you said it much more succinctly than I had been. There's a balance to everything. If the security admins are doing their jobs, the compromise of 1 desktop user password shouldn't be the end of the world for a company. They get access to a very limited set of data that that user has access to, and that's it. The attacker shouldn't be able to drop hash tables of passwords, shouldn't be able to copy the companies database backups, etc.

Sensible 2 factor access control can also be a very good thing. "password plus USB token" for instance is pretty straightforward, mostly brainless from the user's perspective, etc.

Truecrypt: Linux, OS X, and Windows. Free.

[Futurepower(R)]

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"

Re:Truecrypt: Linux, OS X, and Windows. Free.

[hummassa]

At least one of the drivers (Survivor) uses TrueCrypt.

Re:Truecrypt: Linux, OS X, and Windows. Free.

[Sancho]

This requires trusting the OS with your password, having root at a minimum to install it and possibly to use it, and assumes that you don't want to use your thumbdrive on other operating systems. A truely hardware-based system where the drive doesn't even announce itself as a mass storage device until it is unlocked would be the best option.

Re:Truecrypt: Linux, OS X, and Windows. Free.

[Spokehedz]

And since 5.0 introduced WDE for Windows machines, it is a viable alternative for PGP on the homefront.

Unless people can tell me reasons otherwise.

Re:Truecrypt: Linux, OS X, and Windows. Free.

[Chyeld]

My friend, I fear you do not see the point. Have we not said that hardware based encryption is far superior to software based encryption? Does this chart tell you nothing?

Indeed, our thumb drives utilize gold connectors to ensure the fidelity and privacy of your porn collection. Other thumb drives use cheap, base metals. These are highly susceptible to corruption and thus are insecure. Don't take the risk and go cheap; after all, do you really want the whole world to see your midget clown photo sets?

Re:Truecrypt: Linux, OS X, and Windows. Free.

[un1xl0ser]

One aspect of the IronKey that makes it appealing is the protection from an off-line dictionary attack. Only once you have successfully authenticated with your key does it decrypt the flash drive and present it to the OS. It also will simply stop working with a certain number of authentication attempts failing and is fully potted to allow it to be able to resist physical tampering.

It seems to use a randomly generated key (cryptographically the best thing that you can do) to encrypt the flash memory. This doesn't prevent anything, but ensures that having a weak password will not make an off-line dictionary attack any easier.

Finally, only the authentication protocol has to be ported when this needs to be moved to a new OS or platform.

If you don't have a need for this level of paranoia, then simply say so. If you think that TrueCrypt and BestCrypt with a random thumb-drive are equals to this, do your homework. They seem to have put in a decent amount of time thinking this through. I think that IronKey should be given some credit for their product.

The only practical attack against it is a keylogger. If you wanted to make the device more fragile, but fix this whole you could have six random digits on an LCD on the device that cycle every minute or so (like a SecurID). This could be a pre-fix or a suffix to that is verified by the chip and can't be snooped by having a keylogger. Anyone who implements this, please send me a freebie.

Re:Truecrypt: Linux, OS X, and Windows. Free.

[uniqueme]

TrueCrypt under Linux requires a kernel module, which doesn't always compile with the latest stable kernel. FreeOTFE http://www.freeotfe.org/ does not require a kernel module, supports LUKS http://luks.endorphin.org/, supports many of the features of TrueCrypt (such as hidden volumes), and is free/libre software that compiles for Windows, Linux and PDA (Windows Mobile 2003/2005 and Windows Mobile 6 platforms).

Re:Truecrypt: Linux, OS X, and Windows. Free.

[bytesex]

A good solution would be where the drive holds a little (rechargable) battery, which can use a led to display whether we're in locked or unlocked mode, plus a little keypad (like the one on a briefcase, with wheels, but then electronic, and larger (more numbers) to unlock it. You have to unlock it just before you enter it into the USB slot, and it will lock automatically when you take it out. The drive is naturally locked (that is, the data is stored encrypted), and the voltage on the USB drive feeds a decryption mechanism on a little extra chip. Does this stuff exist yet ?

Re:Truecrypt: Linux, OS X, and Windows. Free.

[Sancho]

I haven't heard of such a device, but it sounds like a neat design.

Re:Truecrypt: Linux, OS X, and Windows. Free.

[AdamInParadise]

The mechanism you've just described is used by the Bull Trusway PPS key. There is still a few differences. First, there is a single wheel so you have to enter the PIN code digit by digit. Second, it does not use a battery: you have to plug it in first. However the data is accessible only if the PIN is entered correctly.

The only drawback is that it is not really something you can buy "off the shelf."

IronKey and OSX/Linux/etc

[numbski]

So...it never states if you can format this drive with the filesystem of your choice and use it. It is critical that whatever drive I use be usable on pretty much any OS. I am constantly switching between FreeBSD, Linux, OSX, and occassionally Windows.

Re:IronKey and OSX/Linux/etc

[AMuse]

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.

Slashvertisement?

[PseudoLogic]

There has been ads for the Iron Key running on Slashdot for some time (though they're not up today). I guess I'm feeling a bit cynical today.

Re:Slashvertisement?

[Mr Z]

Slashdot has ads?

Short summary

[Cheesey]

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.

Re:Short summary

[Anonymous Coward]

If I had mod points, you would now be "Insightful"

Re:Short summary

[bluefoxlucid]

I want a kingston drive, or at least the software program. He who haveth one, have fun. http://www.amazon.com/gp/product/159749237X/

Re:Short summary

[chappel]

Note that the online activation is completely optional for the IronKey. I've had one for a while, and am satisfied with it, other than the time it's taking them to release Linux support (beta should be coming out shortly).

The anonymous browsing works well. I haven't had as much luck with the password-keeper feature. Note that so far only basic file access works on OSX, but it works easily.

I opted for the online activation, and used the password recovery successfully - and am glad I got to test that instead of the '10 guesses and the drive dies' feature.

In general, IronKey seems to have a healthy philosophy toward security; I've recommended it often (not that any one has listened). They are still a fairly new organization and I think they still have a few internal growth issues to work out, but they seem to be coming along nicely.

Re:Short summary

[MikeBabcock]

Thanks for the summary -- that was much quicker to read than the original article (which I gave up on after the second page of verbosity).

I use LUKS on my USB drives on my Linux boxes, and I understand there's a way to use it from Windows as well although I haven't tried yet.

Not yet- but do you care about your data tomorrow?

[Phat_Tony]

They also state that there is little difference between 128-bit and 256-bit AES encryption because neither has been broken yet.

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.

Big difference between 128- and 256-bit security

[davidwr]

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.

My condolences...

[Radon360]

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

Re:My condolences...

[Anonymous Coward]

I would imagine that would be the loss of at least a full city block if not more. City blocks just can't withstand "firepower" of that magnitude.

128 vs 256 Bit AES

[Doc Ruby]

there is little difference between 128-bit and 256-bit AES encryption because neither has been broken yet.

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.

Re:128 vs 256 Bit AES

[PingXao]

The notion that "everything will eventually be broken" is one I do not share. If by "broken" you mean the technical cryptological definition of "finding a weakness", then I would agree. But flat-out broken, as in, "I can read all your encrypted messages", then no, I do not agree. Most breaks, certainly the more celebrated ones, have more to do with flawed implementation of the security system as a whole, rather than the vulnerability of the underlying crypto algos.

Before satellite TV hackers were shut down and forced off the internet, one of the largest providers had already evolved their security card mechanism to the point where nobody was getting "free TV" anymore. In fact, the earlier "free satellite TV", er, "solutions", worked by fooling the equipment and not by cracking any encryption. The same goes for many digital cable TV systems in use today in America, at least, that use "access cards" to control who gets what.

There have been some really lame attempts at security and encryption systems in the consumer space, such as that used on DVDs. Too many people have convinced themselves that just because good security is hard to do right, that nobody will ever do it right. Those people are in for a rude awakening before too long. Look at Vista (OK, don't look at it if you just ate lunch). It's been out for over a year and if anyone has devised a way to "break" the method by which it controls which device drivers are and are not allowed to load in a normal boot sequence, well, I haven't seen it yet.

And the Vista DRM and product activation stuff was done all without the benefit of TPM. In the PC arena, when TPM is ready for primetime and deployed on a widescale basis, many people will have to learn how to whistle a new tune as the fallacy of, "everything can and will be broken" becomes apparent.

Re:128 vs 256 Bit AES

[Doc Ruby]

Your argument about encryption algorithms vs products actually argues that encrypted messages will be readable at will earlier than when the algo is broken, not later. And your example of the TV systems is different from how easy it is to access the encrypted messages on the Internet.

You really didn't offer an argument why a message encrypted with AES-128 could be trusted not to be read after AES-128 is eventually broken. Saying "Vista isn't broken yet" isn't a good argument. For one, only a small fraction of people use Vista. When cracking it is as valuable as cracking, say, the current XP installed base, then there will be more people working on cracking it. For another, there's no way to know it isn't cracked. We certainly can't rely on Microsoft to admit it. And of course we can't rely on actual bad guys to report it publicly. We're likely not to know about any working cracks until well after they're a serious risk, which likely would be after Vista is a popular enough to "harvest" it.

And then of course "hasn't been broken in over a year" is hardly "forever".

Everything ever offered to day has been eventually cracked, except for some recent stuff that we have no reason to expect will not eventually be cracked (and except for symmetric/one-time-pad, which is something else). Further, tractability analysis says eventually everything will be cracked. Even the basic models of quantum physics say everything will be cracked, except perhaps simulations of black holes, which aren't available in any products today :).

Re:128 vs 256 Bit AES

[Doc Ruby]

That's why I said "almost certainly". These attacks nearly always break only one key bit-length version, because the key length is so closely tied to the successful operation of the algorithm.

Re:128 vs 256 Bit AES

[Bryson]

Data has an "intelligence life": the period in which its exposure is harmful.
The NSA ended its Venona project not because they could recover no more
plaintext, but because the information was too dated to be of value. U.S.
Census data on individuals is seeled for 72 years; then it is public record.

Right now 72 bits is at the outer edge of what we can break exhaustively. If
we accept Moore's law as indicating that each 18 months we can take on another
bit, then 128 bits is good for 84 years.

The systems here have problems that vastly dominate the difference between
128-bit AES and 256-bit AES. Moreover, we really don't have any systems
where direct attack of 128-bit AES is the week link. 128 vs 256 Bit AES
is so far down the list of security issues that it should not occupy one
second of our attention. Doh! Too late.

Re:128 vs 256 Bit AES

[Doc Ruby]

Excellent summary of the issues (and of _Applied Crytography_ ;).

The point I made is that though 128 vs 256 AES cracking shouldn't concern us right now, it could concern us in the future. I don't think Moore's Law is linear for computation over the next 84 years, especially when we're up against so many limits today (heat dissipation, litho scale, tractability of parallel programming complexity). A pessimist would say it'll be slower than linear now that we've got limits. An optimist (who knows about nanoscale, about quantum computing, about our history of breakthrus especially when trapped) would say it'll be faster than linear, and likely introduce a new order of speed, even of acceleration.

So eventually it's a good bet that those extra 128 bits will matter. If any data is good for more than 84 years, it already matters. And as we get closer to 2092, that intelligence life hard stop grows shorter, as the "inevitable crack date" grows nearer, even as cracking expertise grows faster.

So the bottom line is that the extra 128 bits is worth more than none extra. The only question, as always in security, is whether that extra security is worth the cost.

Re:128 vs 256 Bit AES

[sjames]

The notion that "everything will eventually be broken" is one I do not share. If by "broken" you mean the technical cryptological definition of "finding a weakness", then I would agree. But flat-out broken, as in, "I can read all your encrypted messages", then no, I do not agree. Most breaks, certainly the more celebrated ones, have more to do with flawed implementation of the security system as a whole, rather than the vulnerability of the underlying crypto algos.

Broken is a relative term. Even assuming that nobody ever finds even the slightest mathematical weakness in AES, we're still left with brute force. Brute force always comes down to what is the plaintext worth and how soon is it needed. That includes a need to anticipate how much faster or cheaper raw computing power will get over time. The objective is to make sure that the encryption will remain too expensive or time consuming to be worth the effort by the time it's complete.

The above is true even if the crypto is implemented PERFECTLY. All that means is that in the 24th century, people will look back and say "those guys REALLY knew what they were doing considering what they had to work with!", then they'll run the encrypted historical documents through their 2^128 way quantum computer and have the answer before their slow optic nerves even let them know that the button was pressed.

A big uncertainty in the mix is if a mathematical weakness IS found. Those weaknesses are multiplicative with hardware improvements.

In some areas of security, the value of 'rubber hose' cryptography must also be considered. That is, if you beat the owner of the key up badly enough, will he give it up? Unlike the sort of fishing for intelligence being perpitrated by the U.S. today, rubber hose crypto can work because the 'interrogator' can know right away if the key is genuine.

So, yes, everything can and will be broken. Mathematical weaknesses or 'rubber hose' can sometimes make that happen sooner, but are not necessary to make it happen eventually. The real question is can it be broken for a practical amount of money in a practical amount of time given the value of the plaintext. Sometimes, THAT answer is no.

not as secure as it could be

[v1]

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.

Re:not as secure as it could be

[solafide]

Was that the Ciphershield?

Re:not as secure as it could be

[rant64]

Good write-up, but afaic it only shows that it's difficult to secure new, unformatted drives because you can tell them apart from the rest. If the drive had been wiped by even a single pass and quickformatted, that would probably make things more difficult.

I agree that salts should apply and keys should be different for every sector, like Truecrypt does. But secure drives should be fully overwritten before use, even then. If the cracker has access to your encrypted data over a period of time, you should also use free space cleaning stuff (alcohol works best) because the same scenario applies.

Re:not as secure as it could be

[v1]

Whether or not you zero the drive before use is meaningless. Most drives ship from the manufacturer zero'd. Finding zero blocks is trivial under this system.

Even if we assume the drive was used for quite awhile before I got my hands on it, and thus had what will appear as random information in each block, I can do all sorts of analysis of it. I can still determine what filesystem is on it, and I can even scan the drive for more interesting things like count the number of (potential) files on the drive by searching for blocklists etc which are easy to find since I can determine which bytes are zeros.

Given a little time, I can start to build a translation table, since if I know the format I can start knowing combinations of bytes. In this particular system, bytes were encrypted in blocks of 16, but each 512 byte block was encrypted the same. Not using the block number for a salt was a disastrous mistake.

Formatting with random write to every block before use would be a good start, but who's going to do that? And it still does not prevent me from starting analysis based on the known parts of the partition table and partitions.

I'm no cryptographer, (though my grandfather was) but I'm certain that this provides someone with cryptographic breaking skills more than enough information to make a crack practical. Look at what they did with enigma before they even got their hands on an enigma machine. The japanese Purple machine was reconstructed almost 100% accurately based purely on cryptoanalysis, which really stunned them when they recovered a Purple machine after the war was over. And they had far less to go on than what this gave me.

All trust the OS, except... Root only to install.

[Futurepower(R)]

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

FIPS 140-2 compliance?

[jank1887]

Hmmm... are any of these FIPS 140-2 compliant? I think last I checked some were going through the cert process, but only one flash drive I know of has the certification. (Kanguru offers the only one I've found, making it the only one people will approve for use in the building.) Not sure if that cert is even worth the paper its written on, though.

Ironkey

[ramk13]

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.

Dammit...

[jrothwell97]

I'm still waiting for the drive you can embed under your skin to store super-secret data. If Jason Bourne can have one, then why not me!? That'd be way more secure than these poxy little things, cause you actually have to perform a surgical operation to access the data.

Re:Dammit...

[reynols]

Well, it's not under the skin, but this USB Watch from ThinkGeek, http://www.thinkgeek.com/gadgets/watches/9771/, is the next best thing. 2G encrypted with TrueCrypt on your wrist with you all the time. And it even tells you what time it is! What more could you want?

Re:All trust the OS, except... Root only to instal

[Phisbut]

Root is required only to install TrueCrypt, not run it.

What if you want to read the data on a computer that doesn't have TrueCrypt installed?

Stupid garbage products

[Omnifarious]

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.

Re:Stupid garbage products

[Arapahoe Moe]

Security isn't that hard to do right.

Correct. The problem is that unless corporations get burned by inattention to proper security, then there is no incentive for corporations to take security REALLY seriously. I don't even think that the average individual can be expected to take computer security much more seriously than trying to keep their AV updated ....

Format a Flash drive as NTFS

[Futurepower(R)]

Interesting: Format a Flash drive as NTFS.

I wonder if that would make the flash drive more reliable, since NTFS is more reliable than FAT?

Don't use Windows OS encryption. According to Microsoft technical support, it is not reliable.

Re:Format a Flash drive as NTFS

[hairyfeet]

Wouldn't that cause the flash to wear out quicker do to NTFS overhead? But flash is so cheap ATM that I guess it wouldn't really matter.But I would be worried about doing that if I had one of those expensive 16 or 32Gb flash drives.But as always my 02c,YMMV

Re:Format a Flash drive as NTFS

[mrsteveman1]

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.

Re:Format a Flash drive as NTFS

[X0563511]

ntfs on removable media doesn't work well. Even the "everyone" permission will show as a hash on a third-party PC, so essentially all permissions information will be unusable (but not lost - it still works on the host PC). As such, the encryption will not work on any other PC but host.

Re:Format a Flash drive as NTFS

[jridley]

I just went through this last night with my first > 4GB thumb drive. If anything, it'll make it LESS reliable.
The FAT drivers are geared for quick flush to the drive, so you can yank the drive quickly. NTFS doesn't guarantee everything's flushed unless you use the eject dialog.

So if you yank the drive, or lose power, or hibernate your machine, use the drive on another machine, then go back and plug it in and unhibernate the machine, if you're using NTFS, you're probably going to corrupt the filesystem.

With FAT, if the light has stopped blinking, it's safe to pull the drive or lose power.

I went with NTFS anyway so that I could format the whole 8GB as a truecrypt volume.

Easy but inconvenient.

[SharpFang]

The drive would be quite easy to make. Two sub-critical pieces of plutonium plus a small charge to bind them. The recognition mechanism sounds tricky but nothing a sub-skin RFID can't solve (you authorize people to use the drive by implanting them with authorized RFIDs). OTOH people from stuff like airport security may get nervous if you try to bring it with you on a plane.

Re:Easy but inconvenient.

[blincoln]

The drive would be quite easy to make. Two sub-critical pieces of plutonium plus a small charge to bind them.

Plus you could use it as an emergency radioactive boat anchor in a pinch.

Re:Easy but inconvenient.

[novakyu]

The recognition mechanism sounds tricky but nothing a sub-skin RFID can't solve (you authorize people to use the drive by implanting them with authorized RFIDs). Except, of course, RFIDs are notoriously insecure—no physical contact needed to glean all the information one could want, unless it's protected again with a reasonable challenge/response system, but is there even one in existence? I suppose you could try biometric information such as full DNA scan, but then, do you really trust your evil twin?

It really comes down to the fact that for a truly good security, a man really needs his own island. With electrified shores.

Re:Easy but inconvenient.

[SharpFang]

and remote 'dead hand trigger' nukes located under all the capitals of all the countries of any significance.

Ultimate Boot CD for Windows

[Futurepower(R)]

More secure: Boot internet cafe computers from the Ultimate Boot CD for Windows, which is free. That way you are not dependent on the cafe OS.

Ease of Use

[darthservo]

I suppose they may be easier to use for people who don't know much about computers or encryption.

That's what did it for us. I've been touting True Crypt as an encryption solution for our organization. At least we've put it on our laptops, but flash drives are a different story. Too many users are going offsite to other trusted computers they regularly access, and they would freeze in headlights if something just didn't automatically work (read - varying mount point configurations).

It's a training issue, but unfortunately some users are fairly stubborn. I would love to see it implemented on our flash drives because it's awesome at what it does - but for non-tech people, it's too intimidating. We ended up settling on Kingston's model because it was the most user-friendly.

Even with off-site backup?

[tepples]

Seems pretty easy for someone to destroy the drive/data if they wanted to. Even accidentally destroy the drive/data. The point is that the data is backed up elsewhere daily, and you are using the USB drive only to carry information between computers.

No BioStik review?

[fialar]

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.

Re:No BioStik review?

[pedestrian crossing]

Just make sure you don't leave your fingerprints anywhere on or near the drive and you're good to go!

Boot from CD? Use UBCD4Win

[Futurepower(R)]

Most internet cafes will not allow booting from a CD, I'm guessing. However, if you can boot from a CD, you can boot from the free Ultimate Boot CD for Windows with TrueCrypt already installed.

Re:All trust the OS, except... Root only to instal

[PitaBred]

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.

Truecrypt

[Vlijmen Fileer]

Can anybody give arguments against using Truecrypt on one partition on a stick and a Truecrypt encrypted volume on a second partition which takes up the rest of the stick?
Then you have portable, open source encryption. What more is necessary?

Re:Product development cycle

[bluefoxlucid]

Engineer: That's theoretically infeasable, AES requires a certain number of machine instructions

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.

Ahem, Iron Key reliability?

[imstanny]

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

Completely worthless review....

[gweihir]

These people did review the performance, of all things. The first thing that needs review in a supposedly secure storage device is ITS SECURITY! Not reviewing that only shows that the reviewers are utterly clueless and do not know that most of these things are easily broken. An easily broken "secure storage device" is not a secure storage device and no performance figure can fix that.

Incompetents.

Experts ?

[Anonymous Coward]

"If a user chooses a password with fewer characters than would make a 128-bit or 256-bit key (one character = 8 bits, so we're talking about passwords of 16 or 32 characters, respectively), the remaining characters often automatically become zeros. That means that the password can more easily be guessed, according to Charles Kolodgy, research director for secure content and threat management products at IDC"

Really ? What kind of "expert" is this ? Ever heard of a good key setup routine ? Who would be crazy to directly use the password (mostly ASCII bytes) as an encryption key ?

Re: Insecure ECB Mode?

[Migraineman]

This is a random-access device. The codebook encryption method is pretty much your only option unless you intend to re-crypt the entire downstream content because a one-byte write altered the chaining dependencies. In telecom apps, most of the data is streaming, and chaining cyphers are very appropriate. For static storage with an arbitrary data-order access opportunity, chaining cyphers would cause dramatic reductions in throughput, to the point of making the device unusable.

AES in ECB mode is less secure than (ECB + salt) or CBC mode. However CBC mode is inappropriate for this device. That doesn't make ECB suddenly "insecure."

Re: Insecure ECB Mode?

[wfberg]

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.

Re: Insecure ECB Mode?

[Agripa]

Since CBC mode is sequential, why not use CTR mode to allow both random access and resistance to replay or even better, use ESSIV?

Or, instead of relying on software encryption...

[Dasuraga]

You could just keep your USB drive physically "secure" i.e. keep it with you and don't lose it. If the data on the drive is so important that you need encryption, you should probably keep it with you anyways.

Re: Insecure ECB Mode?

[Cheesey]

I don't think that's true. Other filesystem encryption does use CBC: it is used at the (hard disk) block level. For example, aes-loop works in this fashion. I think what you are missing is that it isn't completely random access. Nothing smaller than a hard disk block is read or written in one go, so you can encrypt entire blocks using a chain. You have to break the chain at each hard disk block boundary (>= 512 bytes), but this is still better than breaking it at every encryption block boundary (= 32 bytes) which is effectively what you get with ECB.

An ECB implementation is potentially simpler, though, which is presumably why it is used :).

NTFS higher disk overhead than FAT?

[Futurepower(R)]

My understanding is that TrueCrypt keeps a lot in memory, and minimizes actual access to the drive.

I don't know whether NTFS would have a higher access overhead. I hope someone who reads this can tell us.

What a surprise...

[damn_registrars]

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.

Hardware Encryption Re:Stupid garbage products

[IronKey Dave]

IronKey does encryption in hardware on the device. All keys are generated on the device and are not-exportable from the device. No software or drivers need to be installed on your computer.

Re:Hardware Encryption Re:Stupid garbage products

[Omnifarious]

The review article doesn't make that really clear. Hmmm... I'll have to check it out. I'm actually in the market for storage like that that's much, much tinier than IronKey is, but I'll take bigger if that's all I can get. :-)

What I want to use it for is to store hard-drive encryption keys. I can just plug the IronKey into the system and configure LUKS to go look there for the password on bootup.

I apologize if I unfairly painted your product with a broad brush that I felt applied to all of them. The reviewer clearly didn't know how to separate good from bad or at least explain how to his audience.

One security flaw with the IronKey discovered

[overlook77]

We ship our clients 4GB IronKey flash drives along with postmarked return envelopes so they can securely send my company sensitive financial data. We did discover one security flaw with our IronKey process however. The drive ships to the client blank with a piece of paper with basic instructions, including the password for the drive. The first drive I received from UPS arrived on my desk with the IronKey drive with the client's private data, encrypted and safe from prying eyes. Along with the drive was the damn sheet of paper with the password on it. That prompted me to add a comment to the instructions at the bottom in boldface: "DO NOT RETURN THIS PAPER WITH THE IRONKEY". I have since received two more IronKey drives, with the instructions (and password) included in the package. Lesson: Never underestimate the stupidity of a client. The IronKey works great however.

Confusion between permissions and encryption.

[Futurepower(R)]

Is there confusion between permissions and Microsoft encryption?

I can move NTFS-formatted hard drives in removable USB enclosures to any computer, and read them there. It seems that it should be the same for any NTFS-formatted drive.

Microsoft drive encryption is not reliable, according to MS tech. support people. It should not be used.

Re:Confusion between permissions and encryption.

[X0563511]

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.

NTFS encryption tied to OS user name and password!

[Futurepower(R)]

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.

recent addons --

[LordMyren]

now includes battery backed heater!

Meet your 7, raise you 5 more

[Shamanarchy]

This must be annual "Review Secure USB Flashdrives" day.

Check out this review of 12 Secure USB Flashdrive products from InformationWeek (via http://news.yahoo.com/s/cmp/20080302/tc_cmp/206900256/).

Re: Insecure ECB Mode?

[Migraineman]

That's a nice link. Thanks. I was approaching from my telecom-centric point of view, where the item to be encrypted is the data, not the medium on which it is stored. There's a fundamental difference between the two, and I think there's a place for both. In a transport environment, it is assumed that the attacker has access to the data stream as well as the encryption algorithm. The strength of the encryption is based exclusively on the math.

The block-based CBC structures will enhance encryption strength within the block, but if the sector ID information is used as part of the initial vector calculation, the resultant data will be tethered to the medium on which it is stored. Relocating the data (i.e. in an off-line backup process) will trash the encrypted information if it's not an exact duplicate. That may be desirable, or it may not be. I can see an IT staff getting hosed because the backups can't be restored (or worse, they were tested on specific hardware which works, but because Seagate/Maxtor/WD et al doesn't make a particular hard drive anymore, future restorations aren't viable.)

My choice: Security through Obscurity

[r_jensen11]

I figure XFS, Reiser4, Ext4, or the like should buy me some time. Figuring that Windows has 90%+ of the market share, I should be safe from most mischevious people that would break in to my home to steal my stuff.

Re:All trust the OS, except... Root only to instal

[TheLink]

An external keypad is irrelevant, unless the password is more confidential and important than the data you are unlocking with it.

If you can't trust the computer you are exposing ALL your files to, you shouldn't make those files accessible to it.

Any malicious program in the computer can read the rest of the files once you unlock the entire encrypted partition for the entire computer to read.

Use a trusted computer to move the files to a different USB drive first.

In the old floppy days, sticking a floppy into an infected system could cause files in it to be corrupted.

How sure are you that malware writers aren't going to be doing that sort of thing.

Review lacking

[TheLink]

The review isn't so good on examining performance.

1) Inconsistent tests for the various file copies mentioned - so you can't really compare.
2) No write speeds listed for all.

Write speeds are significant if you are talking about copying GBs of data to the drive.

And for the write tests you have to ensure that it's all copied and written to the usb drive and not just cached somewhere.

Re:NTFS encryption tied to OS user name and passwo

[Richard_at_work]

You can backup the certificates involved in NTFS encryption.

Data tied to the SID hash of a user.

[Futurepower(R)]

No, the point is that having a backup of the certificates does NOT allow you access to your data, which is tied to the SID hash of a user, on one particular computer. A domain server can back up the information, apparently, but if the domain server crashes, the data is lost. Also, the data is not independent of the domain server in any way.

Sync. TrueCrypt file.

[Futurepower(R)]

I use Sync. I've seen a lot of problems with FAT file system corruption.

My understanding is that it is better to use a TrueCrypt file rather than a TrueCrypt volume. That makes it easier to make encrypted backups; just copy the file. For some reason, using a file does not seem noticeably slower.