RSA: Self-Encrypting USB Hard Drives for all Operating Systems (Video)

Tim Lord met Jay Kim at the RSA Conference in an Francisco. Kim's background is in manufacturing, but he's got an interest in security that has manifested itself in hardware with an emphasis on ease of use. His company, DataLocker, has come up with a fully cross-platform, driver independent portable system that mates a touch-pad input device with an AES-encrypted drive. It doesn't look much different from typical external USB drives, except for being a little beefier and bulkier than the current average, to account for both a touchpad and the additional electronics for performing encryption and decryption in hardware. Because authentication is done on the face of the drive itself, it can be used with any USB-equipped computer available to the user, and works fine as a bootable device, so you can -- for instance -- run a complete Linux system from it. (For that, though, you might want one of the smaller-capacity, solid-state versions of this drive, for speed.) Kim talked about the drive, and painted a rosy picture of what it's like to be a high-tech entrepreneur in Kansas.

Comments

NEAT

[masternerdguy]

Shut up and take my money!

Re:NEAT

[camperdave]

Mod This Up.

Mod This Down.

Sigh! You win some, you lose some.

Not new?

[Kenja]

How is this different then all the simular systems on the market right now? I use Apricorn drives myself, but there are others using keypads, fingerprint scanners, RFID tokens, etc.

Requires no drivers

[tepples]

I didn't watch the video, but I did read the transcript. It's a USB hard drive enclosure that handles all the password entry and encryption in the enclosure. It requires no specialized drivers at all, other than the ubiquitous class drivers for USB hard drives and USB CD drives.

Re:Requires no drivers

[tlhIngan]

Yes, just like all the other products on the market including the ones I mentioned. No drivers needed. So what does this do that the others do not? I'm truly interested as I use these products and am always open to alternatives or better options.

No, most of the other drives do not do that. Most are simply an HID device coupled with a hard drive. On some, you enter the code and the USB port gets activated (rip out the drive to bypass). Actually, an alarming number of these are this kind.

On others, the drive is encrypted, and the keypad or fingerprint reader is used in conjunction with software running on the host PC to decrypt it.

This one looks to do all the encryption and decryption on the device - enter the code to unlock, and it decrypts the drive. Rip the drive out and you can't bypass it as it's still encrypted. OS agnostic and everything.

Re:Requires no drivers

[mlts]

I have an Apricorn drive that handles the USB password entry with a keypad, and uses the PIN to unlock a 128 bit AES key that is randomly generated.

Should I want to erase all contents, I plug the device in with the "cancel" button in, watch for the flashing lights, then hold down "cancel" + "2" + "unlock" for ten seconds... and it will generate a new key, render all data inaccessible on it, and use the password 123456 until that gets changed.

Zero software needed in Windows whatsoever to unlock it.

Just like the parent, I like the idea of a drive performing its own authentication separate from the computer, but this isn't new territory.

Re:Requires no drivers

[AliasMarlowe]

Yep. I'll also give a nod to the Apricorn devices, which we use quite a bit. They are OS-independent (we're Linux-only at home) and require no drivers beyond basic USB, with all of the AES encryption and authorization being internal to the device[*]. They have SSD and spinning disk and USB stick devices, with fingerprint or passcode authorization.

[*] Unlike the crappy Buffalo "encrypted" drives which need OSX or Windows drivers to decrypt. Hence they might be vulnerable to simpler attacks than the Apricorn devices (e.g. getting passwords via IEEE1394). And their encryption won't work on Linux or BSD.

Re:Requires no drivers

[Y-Crate]

What do you use it for? If you are plugging secure data into an untrusted box it seems that you have no defense against something on the box simply reading all of the data. For example if Spotlight indexes the drive then it has leaked data immediately.

Moving confidential footage in post production.

It's not about untrusted boxes, it's about the untrusted sneakernet between two trusted boxes. I could spend all day uploading / downloading huge files from servers, or I could have an Apricorn drive couriered from one production facility to another in a fraction of the time.

If someone intercepts it and rips the drive out of the enclosure - congrats to them - they have a bunch of useless encrypted data and useless plastic.

If the end user is on a computer that indexes it, well, recording just the existence of the extraordinarily undescriptive file name made up of digits, letters and dashes won't hurt anybody or the company.

If the end user actually copies the confidential files onto an insecure drive, then there would be a problem. But that's not remotely related to the method used to get the data to them.

This is the sort of thing I take very seriously as data breaches = end of your TV / film career. You get blackballed instantly.

No.

[bill_mcgonigle]

Encryption software needs to be inspectable and verifiable in order to be trusted with anything worth protecting. Closed-source software burned into the firmware of a USB drive does not meet that requirement.

That said, somebody make a programmable USB drive with open source encryption that can be flashed to it (probably with a fused write protect) and *that* would be a compelling product.

does it have a FBI unlock code?

[Joe_Dragon]

does it have a FBI unlock code?

Re:does it have a FBI unlock code?

[ArhcAngel]

Obligitory

Re:Hell no

[n7ytd]

Hardware encryption is superior to software encryption because at least with hardware encryption there is less room for error. Software usually has bugs, one bug in any implementation and its broken.

I'm not sure what you're saying here... hardware encryption has less room for error because you can implicitly trust the company baking the algorithm into the hardware? Hardware can have all of the implementation errors that a software approach might have.

Unless you compiled it yourself you can't trust the person who compiled it or the compiler itself not to have a bug or backdoor.

But at least someone versed in the art can inspect the software to look for these bugs. With hardware, it's just a black box that you have to trust or reverse engineer at a much higher cost.

UDF

[DrYak]

UDF - Universal Disk Format

Is widely supported, but unlike FAT, it was not designed half a century ago.
So it supports long file name (including UTF8) without the need of extensions.
It supports files with size which don't fit in 32-bits integers.
It supports all POSIX attribs.
Isn't organised around a brain-fucking stupid file allocation table.
etc.

It's the same format as DVDs and Bluerays, so virtually any device able to read them can at least read (or is only a firmware update away from being able to read) USB devices using UDF.

It's of course supported on Linux, on Mac OS-X (sarting from 10.4) and Windows (though on XP it requires 3rd party software for writing, only Windows Vista and up support read/write out of the box).

But of course, because UDF is a strong concurrent to all the proprietary and/or heavily patented alternative that current OS maker push forward (Apple's HFS+ or the worst contender Microsoft's exFAT), everybody is silent about this.
So strangely, you won't see it frequently in the wild *EVEN IF* nothing prevents it now already.

Not secure.

[gmarsh]

Here's how you crack this.

- Buy another one of these drives and gut it. Replace or reprogram the touchscreen controller, and stuff a GSM modem in there.
- Program the controller to act like an ordinary drive, but send the entered password as a text message via the GSM modem. Make it act like the password was entered wrong so the user enters it a few times.
- Swap the modified "drive" for the users' original drive.
- Wait for the password to arrive at your prepaid cellphone.

You can break Truecrypt the same way - copy a users' encrypted data, and replace the Truecrypt executable with one that broadcasts the password when the user types it.

Not sure what this attack is called - "false keypad attack"?