Comments

John Ridley • August 27, 2007 11:00 AM

It’ll be interesting to see a crack attempt on this. Many will remember one from a few months back where it turned out that the data was NOT stored encrypted, it was just behind a lock. Pry the thing open, short out the lock, and the data was readable.
ISTR that in that particular case, the thumb drive in question was even one that had been required for use by some EU government agencies.
Hopefully this one is better.

greenup • August 27, 2007 11:01 AM

I guess I don’t understand why this would be any better than other offerings, that do the “locking” in software.

If you are concerned about someone intercepting the unlock PIN between the keyboard and the device, you have more grave concerns… after the PIN is entered, ALL your data is in the clear, and ready to be siphoned off or infected.

Not that the software-only devices are any better in this regard; once you have your data in decrypted form, it doesn’t matter how it was unlocked. When encrypted, I don’t have a way to compare the strength, as the algorithm for the corsair fob is not listed. (much less the number of bits)

One nice thing about some of the software protections is that some of them also provide “token” functionality as well as an encrypted drive.

Personally I’ve been a little baffled by that (software tokens), because I thought the whole point of tokens was to prove that there was an utterly unique individual involved, and with software, you can always copy the bits. (for later cracking by someone who snarfed all the bits off your fob, or giving to a coworker to use in an emergency, even though he isn’t very security conscious, and might change the pin on his copy to 1234…)

I HAVE found a VERY few true hardware token-thumbdrive combos; at least in spec… it seems harder to find someone that actually sells them.

Rick Auricchio • August 27, 2007 11:06 AM

What happens when a button fails and you can’t enter the combination?

I couldn’t find any mention of this situation on the web site, nor in their user manual.

Nyhm • August 27, 2007 11:07 AM

Their white paper claims Two Factor Authentication. However, they are counting the Padlock Drive as the component you must have (and you must know the PIN). I’d argue this is not truly Two Factor Authentication, as the Padlock Drive is the element to which you are authenticating.

Suppose a bank requires a key and PIN (memorized box number) to get your safe deposit box. The box itself is not considered a factor of the authentication. Rather, it’s a prerequisite, just as the Padlock Drive itself.

I eagerly await a flash drive in which the on-board PIN is the key to an on-board symmetric cipher.

Ilya Levin • August 27, 2007 11:35 AM

Rob,

I like this quote from Ironkey: “The IronKey Cryptochip generates strong 128-bit long random keys that are unlocked by the user’s password.” This is just lovely. They are generating “strong 128-bit long random keys” to get rid of weak user passwords but use one to protect their “strong” secret. Huh.

Rob • August 27, 2007 11:46 AM

Ilya Levin,

I noticed that also. But, if you use a strong password, does it make a difference?

I did receive a response from them that Linux support will be announced within 30 days. Makes it easier to use than TrueCrypt (my current process).

Ilya Levin • August 27, 2007 12:02 PM

Rob,
If you use a strong password already then what is the point of generating another one? See, if there is a strong password then the quoted scheme is pointless, otherwise it is not that secure anyway.

Nicko • August 27, 2007 12:09 PM

Rob, yes, proprietary encryption schemes are a cause for concern even if you have a strong password. Unfortunately, as the first post points out, the key space is less than 24 bits, so you can’t have a strong password anyway. Even if you managed to squeeze a hex keypad onto the front you’d still be stuck with 40 bit encryption if you have a 10 character limit.

Having said all that, since the keying is done through the device and not software there is no way to brute-force search for the key without dismantling the device. That seems to me to be a useful security step, irrespective of other vulnerabilities.

Rob • August 27, 2007 12:13 PM

Ilya Levin,

Is it easier to break encrypted data you have easy access to (flash memory), or to take apart a encryption chip, that presumably has the key on that chip?

Is it just an option to appease those who don’t think about it, or does it really add value because of the encryption chip?

Otherwise, I agree with your statement.

Nicko • August 27, 2007 12:16 PM

Oops, sorry Rob. I somehow managed to skip a post and thought you were replying to Ilya’s earlier posting!

Henryk Plötz • August 27, 2007 12:18 PM

Ilya Levin,

Yes, it does. There are two scenarios for password verification: on-line and off-line.

Off-line is when you use encryption and need the password (or better passphrase) to derive the cryptographic key. In this scenario an attacker can get the encrypted contents and will try to break the key with basically unlimited speed. This is where you want something like 128 bits of entropy in the key.

On-line is when you communicate with a device that decides whether it wants to send you the information. In this scenario the device can have a failure counter and block out all accesses after a certain number of incorrect attempts at guessing the password (or a PIN), or at least slow the attacker down. This is where a comparatively weak password (e.g. 4 numeric digits, combined with lock-out after 3 failed attempts) is secure enough. Examples include your ATM card (on-line PIN verification at the bank’s central server) or a proper smart-card.

Judging from the website, the IronKey seems to include both: flash memory, encrypted with a random 128 bit key (needs to withstand off-line attacks); and a smart-card, automatically locking after 10 failed attempts to store the key.

—
Henryk Plötz
Grüße aus Berlin

Nyhm • August 27, 2007 1:02 PM

The security “step forward” offered by the Padlock Drive is the on-board PIN pad, which provides data security without trusting third-party systems to handle your password. The IronKey password has to be entered through a potentially untrusted computer.

Of course, once either is unlocked, there is no stopping the untrusted computer from grabbing all the data from the drive.

This isn’t preventable unless the portable device actually processes data and runs applications, making the “untrusted computer” at most a network and monitor device.

In case of a stolen drive, the IronKey sounds safer. Still, I’m waiting for an IronKey-like on-board cryptochip with Padlock-like on-board key entry.

SumDumGuy • August 27, 2007 2:19 PM

@Mo

–The Bioshock issue is LAST week’s sony rootkit noise, which was really a self-admitted case of ‘search-engine optimization’ by the author of the orignal article

THIS week’s furour is the real deal – secret directories and software hacks installed to keep them secret.

Bill Ricker • August 27, 2007 2:37 PM

The Corsair FlashPadlock website has “register your pin” “retrieve your pin” “change pin” features !?

Bill Ricker • August 27, 2007 2:37 PM

The Corsair FlashPadlock website has “register your pin” “retrieve your pin” “change pin” features !?

Jan • August 27, 2007 3:46 PM

the “change pin” means probably changing the saved PIN, and while I consider it stupid to put passwords online, they will be much safer at the manufacturer than on the yellow post-it note stuck onto the thumb drive…

As long as it is completely voluntary and there are no disadvantages from not using it, why not?

just jon • August 27, 2007 4:33 PM

I’m always off-put by a security device mentioning a “ATM machine.” The security business is all about precision and accuracy, lazy usage like “ATM machine” imply to me the possibility of other “lazy” practices.

Volker • August 27, 2007 5:18 PM

In the appnotes (http://www.corsair.com/_appnotes/AN701_Padlock_USB_Flash_Drive_08212007.pdf and http://www.clevx.com/flashlock.html) they describe the process as if the PIN-pad and -controller just sit between the USB plug and a standard USB flash drive that sits hidden inside.

Only if you enter the correct PIN, the internal USB drive is connected to the external plug. Simple, cheap, no need for processing power due to non-encryption (“FlashLock obsoletes expensive encryption controllers …”).

But then all a determined attacker needs to do is to cut the internal connectors and solder a few wires from the internal USB drive to the external plug, circumventing the Pin-pad and -controller.
Et voila – the stick is permanently de-PINned.

(not tested, though, just deducted from the description in the appnotes)

Eric Norman • August 27, 2007 6:36 PM

It appears to have a usability problem too. From the picture it looks like I couldn’t plug it into one of the USB ports on a computer in my office due to its shape.

Kanly • August 27, 2007 9:52 PM

Ever been locked out of your house only to discover how easy it is to break in? I had a Targus DEFCON1 Notebook lock.

  1. Once the alarm went off, combination had changed. Got a knife, pried open the flimsy 9V battery cover and disconnected it in maybe 10 seconds.
  2. Once had to move a computer with one: no batteries, so only combo lock to worry about. I just yanked it hard, and the security cord came out just like that. No damage even, so when I moved it we plugged it in again. By that stage we didn’t care no one knew the combination. 😉

This is security that makes the consumer feel warm inside, but doesn’t offer any meaningful protection.

Ilya Levin • August 27, 2007 10:38 PM

Sorry, Henryk, but it does not as Ironkey put it. Although thank you for your on-/off-line scenarios description.

Actually their paper has even more issues, including plain false statements. For example, from the demo we can see that some space from 4GB reserved for Ironkey software. User must type his password there to unlock access to his data. And the software does not require admin privileges. From the other hand, their paper claims that Ironkey is not vulnerable to malicious code. well, the Ironkey’s folks are either incompetent or simply lying here.

And, yeah, I could not miss that touchy “military-grade” reference in the demo 🙂

Rob • August 27, 2007 11:44 PM

Ilya Levin,

When I read their site a week ago, it appeared they bundle some applications, like mozilla, for secure browsing. This would be why the full 4Gb is not available.

Without having one in hand though, hard to verify. I’d suspect you could reclaim all 4Gb (minus FS structures) from the way I read it.

Ilya Levin • August 28, 2007 12:36 AM

Rob, there is a clear usage of unlock software in their on-line demo. I suspect reclaimable space too, but the actual point is a vulnerable link between this unlock software and hardware.

Olaf • August 28, 2007 3:18 AM

I actually quite like this. It’s simple enough that a very basic user will be able to grasp the concept and is enforceable wherever they take the key.

It’s got to be easy or they’ll just being in their own drive and you’re back to scratch.

I think this is a “better than nothing” technology which has it’s place.

Henryk Plötz • August 28, 2007 4:12 AM

Ilya,

yes, you are right. There is (and there must be) some sort of password entry application in the unencrypted part of the IronKey. This is because the device itself does not have a keypad, so it must use the computer it’s attached to. This is not a particularly big problem, though: When you enter your password on any untrustworthy computer you have lost, most of the time. IronKey is actually ok in this regard, since you still need the password and the device (where with the corsair padlock you’ll most likely only need the device and two days, maybe a week, of time).

They also claim to have protected the channel from the password entry application to the IronKey against USB sniffers. I’d be curious as to how they did that, especially since they don’t need special USB drivers. Also, apparently, the part where the password entry application is stored can not normally be written. (Their FAQ#17 talks about a ROM area, in other places they talk about secure firmware update. Conclusion: the unencrypted area is kind of emulated by the firmware, therefore can not be written to, and any firmware update must be signed or similar.)

As might be obvious, in general I like the concept “encrypted flash+smartcard with retry counter” much more than “keypad on thumb drive+no encryption”. If the computer you’re using it on is corrupt, you’re hosed either way (the corrupt system simply makes a copy of your information). If you lose the stick, first one is secure, second one is not. Despite what the marketing might want to tell us: don’t do anything security-related on computers you don’t trust. (Or at the very least: use one-time passwords for that.)

However you are right in that the IronKey published information is partly self-contradicting and/or deliberately vague: For example I find their claim of using AES in CBC mode kind of hard to believe, for full-device encryption. Also their talking about self-destruction “in hardware (not in software)” at best is useless (an attacker will simply cut the power supply when the self-destruct starts; instead, the correct way is to use a (properly implemented) retry counter and a secure processor that will not allow any attempts when the counter is expired, combined with storage that is extremely hard to read without cooperation of the secure processor; no self-destruct necessary).

I’d like to attribute these to a sloppy marketing team trying to make things simple for the public to understand, however, a more thorough and correct description of what they do and how they do it would have been really nice.

—
Henryk Plötz
Grüße aus Berlin

Bob • August 28, 2007 5:37 AM

I like the idea of encryption/decryption being done by the USB device. Makes the protection seamless like it should be. I’d love to see this implemented properly though (I’m assuming it isn’t here!) i.e. strengthen the PIN with enough rounds in PBKDF2, use the derived key for on-the-fly AES-CBC.

Dave IronKey • August 28, 2007 1:27 PM

Henryk and Ilya,

IronKey does in fact use AES CBC mode encryption. As you can imagine this is very difficult to implement in NAND flash. Some other products use EBC, which is not designed to encrypt large blocks.

The hardware deletion of encrypted data is something that was requested by certain customers. Obviously an attacker could cut power. But, this is an additional safeguard. What is good about hardware deletion is that we can delete data stored in flash blocks that were marked as bad by the wear levelling. Software cannot do this, thus leaves encrytped data hanging around in flash bad blocks. Some customers care about this.

Regarding using a randomly generated AES key instead of just basing it on a hash of your password. This is primarly to prevent disassembly attacks where the flash is removed and cryptanalysis is attempted. If the AES key is based on a password, then a simple password guessing attack can be performed to generate AES keys and attack. This is much more feasible than trying to randomly generate AES keys themselves.

Also in portions of the FIPS 140 requirements, data encrypted with keys that are based on passwords are considered Plaintext. You need to have randomly generated keys.

Ilya, you make a comment that this doesn’t achieve anything if users use a weak password. That may be true for a software implementation where its impossible to stop password brute force guessing. However the IronKey implements password verification and brute force guessing prevention in hardware. You get 10 tries. Thus its more secure than basing the keys on a password.

Ilya Levin • August 29, 2007 2:27 AM

Thanks for feedback, Dave. Everything ends up at implementation. I hope you guys did well and an actual device is better than it seems from on-line materials.

Gweihir • August 29, 2007 9:49 AM

The advantage of this thing is that it works the same as a regular flash drive from the interface side. You can use it to relpace one. What this thing gets right is its interface. It is not a high-security device, but one could be built using the same or a similar interface.

Also take into account that it is priced similarly to a regular flash key.

Paeniteo • August 30, 2007 3:07 AM

@Dave: “AES CBC”

AFAIK, in CBC mode, a block of data depends on the encryption result of the previous data block by XORing the ciphertext with the plaintext before encrypting.
As a result, this means that if you change a “middle” block in a message / on a drive, all later blocks will have to be re-encrypted.
How do you realize that? I have the impression that plain CBC is rather pointless when used in block devices, where you need random write-access (random reads are no problem).

As for the added resistance against password-guessing by using a random AES-key, there are schemes for password-based-encryption which handle this quite well.
Depending on the integrated RNG, attacking the auto-generated key might even be more feasible than brute-forcing a suitable PBE-protocol.

Dave IronKey • August 30, 2007 3:17 PM

@ Paeniteo “AES CBC”

Yes, we chain blocks together. We generate unique IVs for the AES for each large block. The trick with NAND flash AES encryption is actually where to store the IVs.

The RNG on our device is desgined to be FIPS compliant for RNG.

Dave IronKey • August 30, 2007 3:20 PM

@ Ilya,

I believe that security is 50% design and 50% implementation. You can implement crypto algorithms well, but if there are other attacks that were not modeled, the overall design may be flawed. We’ve tried to do both right. Thanks for the feedback on the marketing materials… we’ll work on them.

Dave

Anonymous • September 1, 2007 1:32 AM

Question for all you hardware hackers:

Assuming someone had PCB making abilities and a strong knowledge of digital eletronics design do you think he could build a good or at least not crappy hardware based ID token or even a storage device?

I’m thinking it would of course need to be bigger then a factory design.

royalblue_tom • September 24, 2007 4:24 PM

One benefit in the US is that there is an expectation of privacy on anything with a lock. There was a case where someone’s elderly father let the police in (their usual “just looking around” without a warrant), and since there was no lock on the PC case, they opened it up, and read the data stright off the hard drive without booting up the machine (and without a warrant). But they would have needed a warrant to access the data off this USB, no matter how poor the lock actually is from a technical security point of view.

Robert • June 25, 2008 9:04 AM

Hi Dave! Your statement that the security will be
better if a random AES key is protected by
a user password, is true only if the AES key is not stored in any way on the flash.

Can you confirm that the AES key is protected (perhaps even encrypted?) in separate specialized hardware other than the flash (perhaps the same hardware that does the encryption/decryption) and that this hardware takes care of erasing the AES key after 10 failed unlocking attempts?

PAH • May 13, 2009 12:41 AM

The thing I like about the the idea of a thumbdrive with a key combo is the ability to unlock it without fear of malware on a PC… and then boot Linux off the thumbdrive. That should keep it completely secure unless someone has hacked the BIOS or installed a mal-Boot Rom… both of which seem beyond what I need to care about.

Re: Ironkey… can I as a user with the password, add/modify stuff in the “read-only” area? i.e. can I install a bootable linux in there that runs the IronKey linux utility on boot to then gain access to the secure area?

Or does it come it with a boot image that asks for the password, unlocks the device, and then bootstraps from the secure area?

Thanks

Daniel • January 18, 2010 6:57 AM

Not only does the Corsair Flash Padlock have a web page that allows you to save the PIN number in case you forget it, but it all seems that the form containing the PIN code is all posted over a plain, unsecured HTTP link to the remote server…

Yuhong Bao • April 14, 2010 7:09 PM

“The good news is that there is the Ironkey 2 now, which actually uses hardware encryption, resolving this.”
Dumb mistake, should have typed “Padlock 2” instead of the “Ironkey 2”.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.