Video RSA: Self-Encrypting USB Hard Drives for all Operating Systems (Video) 154
Jay Kim: Hi. My name is Jay Kim. I am the president of DataLocker, based in Overland Park, Kansas.
Tim Lord: Okay. And what is DataLocker?
Jay Kim: Data Locker manufactures and develops encryption solutions for storage, for systems and for media.
Tim Lord: So solutions is a broad term. What do you mean by solutions in this case?
Jay Kim: Well, we specialize in hardware-based AES encryption. We develop devices that can be managed and used very simply by any consumer or client.
Tim Lord: Okay. And what is that you are holding in your hand there?
Jay Kim: This is one of our flagship products. It is called the DataLocker DL3. It comes in up to 1.5 terabyte of storage. It is hardware encrypted. Everything is done at the device level. You authenticate on this touch screen panel; you manage the device. And all the security features are done locally here on the device. Again, there is no software, no driver, so it could be used on any type of system, Mac, PC, Linux, any type of work station.
Tim Lord: Is there the possibility that this could be used as a bootable drive? Could you run an OS from it?
Jay Kim: Yes. Linux supports USB booting. Microsoft 8 supports it as well. All the versions of Windows do not support booting up a USB device, but this device also supports what they call a virtual CD. The user can take an ISO image and create a working bootable CD partition on this device itself.
Tim Lord: Okay. Now could you distinguish this, it is a little bit bigger than say using a USB key, but there are companies right here at the show that are selling smaller things that have some similarities? How do you distinguish this from those?
Jay Kim: The big difference is capacity. This comes in up to 1.5 terabyte of capacity in the same 2.5 inch form factor. It is USB powered, so everything is done at the device. In terms of performance, the speed of a hard drive is probably about six times faster than traditional flash drive or encrypted flash drive. Encryption is done through specialized hardware, so there is no latency in the actual data transfer speeds.
Tim Lord: And so this is a spinning disk hard drive? Is that correct? It is not a solid state.
Jay Kim: Yeah. The higher capacity models are spinning disk. We also have SSD models as well in 128bit AES and 512 gigabytes.
Tim Lord: Okay. A lot of the products at this show start out in prices that only pretty big businesses are able to pay. Is this priced at a level that household users might use or is it aimed at businesses? What do these cost?
Jay Kim: MSRP starts at $399. It is available at discount through retailers for a discount off the MSRP. It is also available on GSA Contracts as well at special contract pricing.
Tim Lord: Okay. Now one thing, if this device is stolen, it is encrypted, so what would someone find if they pried open the device and just popped out the hardware. They would find nothing but AES encrypted trash?
Jay Kim: Everything, every sector is encrypted. It is 256 bit AES encrypted. It also has a host of built in security features such as self-destruct, it prevents brute force attack, if somebody enters in the password, let’s say 10 times, you can set it from 10 to 50 attempts, it will wipe the ____3:13.
Tim Lord: And what if the actual input device itself, if that should ever go bad, I mean hardware fails once in a while, what does someone do? Can your company recover data? Or is it so strongly encrypted that you are?
Jay Kim: Let’s say if the touch screen is broken, you can swap – pull the drive out, and put it in a new enclosure and access it with the same password.
Tim Lord: Okay. Well, that is good to know. It will be a scary situation to find that out. Now you mentioned that you are from Overland Park, Kansas; your company is based there.
Jay Kim: Yes we are.
Tim Lord: Talk about that. Because I had never heard of Overland Park really.
Jay Kim: Overland Park is a suburb of Kansas City. We are host to a lot of major companies, Sprint Telecom is probably one of the bigger companies. Cerner, the healthcare information systems developers, they are based up north from us. It is really – they are going by trying to take that Silicon Prairie title and doing a pretty good job. Actually here at RSA I saw three or four companies based within 5 miles of myself exhibiting here today.
Tim Lord: That is really funny. Do you have any personal experience about what is different about being in business there than say in Silicon Valley or somewhere like that?
Jay Kim: A 10-minute commute is considered long. There is no traffic. It is a great place to live, raise children; the work ethic and workforce is outstanding. We have a lot of talent that came out of some older defense related industries also through the telecom community. Developers are easy to find, and wages are very reasonable compared to probably out east and west.
Tim Lord: And speaking of background, what is your background? How is that you came to be holding a new piece of hardware in your hand? Did you design this or how did it come to be?
Jay Kim: My background is actually manufacturing but what happened was about five years ago, I acquired some IP related to the use of a touch screen panel on a storage device, and we took that IP, commercialized it, developed a business around it, and developed a whole suite of products, using that core IP. It is more of I guess something I really enjoy doing, it is more of a personal endeavor, and it has really turned into a pretty nice business.
Tim Lord: Have you been involved with other startups before?
Jay Kim: Yes, we hit the dotcom boom actually starting in ’98, did e-commerce sites, worked in a variety of family businesses as well. Again, most of us that revolves around e-commerce for manufacturing and so we did steel fabrication overseas, we did some international trading businesses as well.
Tim Lord: How long did this product itself take to develop?
Jay Kim: We spent about two years in R&D. Basically just going from patent on a piece of paper to finished working product, that received – our initial product has FIPS 140-2 validation. That whole process took about a little over two years.
Tim Lord: Okay. And speaking of the development, this is you say, now available at the MSRP that you mentioned.
Jay Kim: Yes, it is available through most major retailers or e-commerce sites. We have a select set of specialty security bars as well. It is available through distribution through Ingram Micro and DNH as well.
Tim Lord: Okay. And what sort of reaction have you found here at RSA so far?
Jay Kim: The key comment we get is how easy our product is to use. If you ask anybody selling hardware, the number one support call they get is related to the software drivers, because we have none, it is very easy to implement, very easy to roll out, it is totally platform independent, again you don’t have to worry about the platform it operates on. So really there is a lot of use cases this can be just literally dropped in, plug-and-play, ready to go to provide an encryption solution.
Tim Lord: And what should we expect next from DataLocker?
Jay Kim: Well, like everybody else we are working on a new product called DataLocker Skycrypt. It is going to be a FIPS validated cloud storage solution. It has got some bells and whistles that you probably haven’t seen before, but we will have a formal announcement in about three months.
NEAT (Score:5, Funny)
Re: (Score:3)
Mod This Plaid.
Re:NEAT (Score:4, Insightful)
Mod This Up.
Mod This Down.
Sigh! You win some, you lose some.
Re: (Score:2)
You are an awfully loud sigh-er...
Not new? (Score:4, Interesting)
Requires no drivers (Score:5, Informative)
Re: (Score:3)
Re:Requires no drivers (Score:5, Informative)
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: (Score:3)
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.
Again, others, including the ones I listed, do the same thing. Go look at the Apricorn products (not an endorsement, just what I currently use).
Re: (Score:2)
Most people can't read. Sounds like he just slapped a keypad on an OPAL drive.
Re:Requires no drivers (Score:4, Interesting)
Yep. I'll also give a nod to the Apricorn devices [apricorn.com], 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: (Score:2)
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.
Re:Requires no drivers (Score:4, Informative)
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.
Re: (Score:2)
Thanks for the reply - that's a really interesting use for them.
Re: (Score:2)
Yep. I'll also give a nod to the Apricorn devices [apricorn.com], 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.
Ack! The 'passcode' on the ones on the website is a mere numeric pin. This essentially guarantees that if someone steals the unit and removes the drive/memory chip(s) etc, brute forcing of the pin will be trivial. I might give them the benefit of the doubt and assume they know this is just a minor obstacle to stop non-technical thieves, except their pages are plastered with the phrase "military grade." They even have pictures of people in camo uniforms using it.
The false sense of security from such a devi
Re: (Score:2)
The problem with having to enter the code on the PC is that malware running on the PC will be able to get the key.
Re: (Score:2)
I've had a Lenovo drive that does that for quite a while now.
Re:Requires no drivers (Score:5, Interesting)
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: (Score:2)
Just an fyi, a system using biometrics, RFID, or tokens is going to be insecure: unless they are using the fingerprint itself as the encryption key (highly inadvisable as you would have to get the same image every time), they are storing the key in the USB device itself, which will be terribly convenient for any attacker.
The only proper way is to have the key derived from the "unlock code", so that the USB device has no knowledge of what the key actually is; "access" is granted merely by providing a decryp
Re: (Score:2)
Just an fyi, a system using biometrics, RFID, or tokens is going to be insecure: unless they are using the fingerprint itself as the encryption key (highly inadvisable as you would have to get the same image every time), they are storing the key in the USB device itself, which will be terribly convenient for any attacker.
The only proper way is to have the key derived from the "unlock code", so that the USB device has no knowledge of what the key actually is; "access" is granted merely by providing a decryption key that actually returns data.
It also adds "meat cleaver decryption" as an alternative to "rubber hose decryption".
Re: (Score:2)
unless they are using the fingerprint itself as the encryption key (highly inadvisable as you would have to get the same image every time)
There are some relatively new cryptographic constructs called fuzzy extractors which allow you to use imprecise data like biometrics to generate deterministic keys. As long as the image is within some threshold of original image, the same key will be extracted. The original image is stored as a secure sketch which essentially means it can be used as a "hint" to extract keys but alone it reveals nothing about the target biometric. The idea is that the difference between two images of the same finger wil
Re: (Score:2)
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.
Let me guess, you have the padlock pro? The cool feature of the Padlock pro is it self destructs if the bad guys get access to it and give 30 wrong password attempts.
Re: (Score:2)
I had a look at Apricon offerings, and one difference that I've immediately noticed is that they all use physical keypads. The product covered in TFA, on the other hand, uses what looks like a touchscreen, and they claim that their keypad is randomized - meaning that you can't guess the code from most worn / most greasy areas.
Re: (Score:2)
Please explain something to me. The Apricorn drives use a ten digit keypad to enter a (maximum) 15-digit key. That gives a key space of approximately 50 bits (log(10^15)/log(2)). They why do they advertise the drive as using 256-bit security? Why not just implement a 64-bit algorithm? That is still a greater level of security considering the passkey.
No. (Score:5, Interesting)
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.
Re: (Score:2, Interesting)
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.
Use TrueCrypt [truecrypt.org] to create an encrypted volume within the USB drive.
Best Case Scenario: USB drive provides an additional layer of cryptographic protection.
Worst Case Scenario: Attackers find out easy-to-break USB drive was only the start of their headaches.
Seems like a win-win to me.
Hell no (Score:2)
Truecrypt is a software encryption implementation. 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. Side channels also can defeat software trivially. Software also isn't usually good at generating entropy so you wont have a good source of that either. Unless you compiled it yourself you can't trust the person who compiled it or the compiler itself not to have
Re: (Score:2)
Your statement "with hardware encryption there is less room for error" doesn't jive. Hardware can have bugs too. I would say the hardware errors are worse as they require device replacement. Hardware implementations cannot be trivially inspected.
If your data is extremely (i.e. NSA level) important, never trust device-side encryption unless indeed you did compile and upload the firmware yourself. I'm not sure about how modern SSDs allow custom firmwares to be uploaded but it'd be really cool if they did.
Re: (Score:2)
Your statement "with hardware encryption there is less room for error" doesn't jive. Hardware can have bugs too. I would say the hardware errors are worse as they require device replacement. Hardware implementations cannot be trivially inspected.
If your data is extremely (i.e. NSA level) important, never trust device-side encryption unless indeed you did compile and upload the firmware yourself. I'm not sure about how modern SSDs allow custom firmwares to be uploaded but it'd be really cool if they did. Could roll your own if you are super paranoid - I can't remember who makes but I did see one time an "SSD development kit" - it was a larger-than-a-2.5-SSD board that had a SATA port on one side and a serial port on the other - this is where you would upload firmware. You also had to purchase and install your own NAND modules which resembled DIMMs from what I could tell. It was really cool.
For 95% for use cases it's likely better than nothing.
Software is not good at generating entropy but there is no reason why software should do that. There's many physical sources of good entropy, your soundcard for one.
Truecrypt at least I can look at and compile myself if I so wanted. That says a lot to me.
If your data is NSA level important then it shouldn't be stored anywhere but at the NSA.
What I mean is hardware implementations are safer from Mallory because very few people are going to know about the flaws in a hardware implementation if there are any. The people who know would be the few people who designed the hardware implementation and they would be restricted under non disclosure agreement most likely. Truecrypt you can compile yourself but chances are you don't know whether or not the functions an
Re: (Score:2)
While it may take many years, seeing how emulator developers figured just about everything regarding obscure, nonstandard, and often undocumented hardware that's in arcade machines and video game systems (even going so far as to dump the NES's lockout chip with an electron microscope and reverse engineer the custom CPU in it) does not convince me that hardware anything, especially if it becomes widespread, is unhackable.
I think I have a better chance of knowing things are secure with Truecrypt than some har
Re: (Score:2)
Truecrypt is a software encryption implementation. 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. Side channels also can defeat software trivially. Software also isn't usually good at generating entropy so you wont have a good source of that either. 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.
Just because it looks like "hardware" doesn't mean that it's not software - I'm certain that this device isn't running on a hardwired FPGA, so it's running software. Why don't you trust software compiled by someone else, but you trust software hidden away in a hardware device that's been compiled by someone else?
The difference between hardware and software is that when the software embedded hardware is broken, it's not always possible to fix it - not all devices allow firmware updates.
You keep mentioning e
Re:Hell no (Score:4, Insightful)
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.
Re: (Score:2)
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.
There are usually less human beings to trust and less points of failure. That is a good thing.
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.
Re: (Score:2)
Less human beings to trust with hardware. Less points of failure. Human beings are the problem.
Re: (Score:2)
Less human beings to trust with hardware. Less points of failure. Human beings are the problem.
The pro-software crowd would view that in itself as a weak point: that the more people who are able to evaluate and hammer away on different implementations, the better. If the small group of people that implement the hardware can be trusted to do a proper job of it, then a small group can get it done.
Re: (Score:2)
Less human beings to trust with hardware. Less points of failure. Human beings are the problem.
The pro-software crowd would view that in itself as a weak point: that the more people who are able to evaluate and hammer away on different implementations, the better. If the small group of people that implement the hardware can be trusted to do a proper job of it, then a small group can get it done.
That also means there are more people who can sneak in a back door or errors.
Re: (Score:2)
Side-channels have historically hit hardware encryption harder than software, as it is easy to do something dumb like storing the encryption key in a rom chip or something. Hey look, we have hardware AES, and you dont even have to provide the password!
The distinction between "software" and "hardware" implementations of an algorithm are irrelevant when looking at the quality of the implementation; all it really indicates is that the hardware one will not use any host resources, and will be easier to port ac
Re: (Score:2)
Side-channels have historically hit hardware encryption harder than software, as it is easy to do something dumb like storing the encryption key in a rom chip or something. Hey look, we have hardware AES, and you dont even have to provide the password!
The distinction between "software" and "hardware" implementations of an algorithm are irrelevant when looking at the quality of the implementation; all it really indicates is that the hardware one will not use any host resources, and will be easier to port across systems. It doesnt tell you whether its faster (will usually be SLOWER), or more secure, or anything else.
With hardware you have less components you have to trust and you know the people who made it. Who made Truecrypt?
Re: (Score:2)
The "Stoned" bootkit
The "Stoned" bootkit, an MBR rootkit presented by Austrian software developer Peter Kleissner at the Black Hat Technical Security Conference USA 2009,[27][28] has been shown capable of tampering TrueCrypt's MBR effectively bypassing TrueCrypt's full volume encryption.[29][30][31][32][33] (but potentially every hard disk encryption software is affected too if it does not rely on hardware-based encryption technologies like TPM, or—even if it does—if this type of attack is made with administrative privileges while the encrypted operating system is running).[34][35]
http://en.wikipedia.org/wiki/TrueCrypt#Security_concerns [wikipedia.org]
Re: (Score:2)
Truecrypt is closed-source, which seems to defeat GP's (incorrect) point.
Why not simply have someone analyze whether the USB drive is, in fact, using AES, and that the key is not stored in a decrypted state anywhere? That can all be done without the manufacturer's help.
Re: No. (Score:2)
"TrueCrypt is open-source and free software. The complete source code of TrueCrypt (written in C, C++, and assembly) is freely available for peer review..."
http://www.truecrypt.org/docs/?s=source-code [truecrypt.org]
Re: (Score:2)
I stand corrected, Im not sure where I got the idea it was closed source.
Re: (Score:2)
UDF (Score:4, Interesting)
UDF - Universal Disk Format [wikipedia.org]
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.
Re: (Score:3)
As far as I know, HFS+ is neither patented nor proprietary. It's documented both as part of the open-source kernel and in TN1150. (Caveat: some newer feature are only documented in the former. A few very new features are not documented at all.)
Re: (Score:2)
Is UDF really worse for traditional hard drives or SSDs than FAT32?
Several UDF builds, Plain is for harddisk+flash (Score:2)
UDF was designed by an optical media industry consortium for use on optical disks, and was carefully tailored for their unique characteristics
(e.g. it can provide the illusion of overwriting files even on optical media types which can only be written to by appending, never by overwriting). Had you never considered the possibility that UDF might not be the best possible choice for other media types?
Depends. There are several sub-types (called "build") of UDF.
- The basic one is called "plain build". It's the most widely available. It's optimized to be written on pure random access device (harddisks, flash, etc.) and thus can only be used in read-only form on optical media.
- The careful tailoring you refer to happens in the other subtypes. The "VAT build" is exactly the type of "append-only" format you refer to (and is similar to how adding files was done on ISO9660 partitions on CD-R with packet writin
Re: (Score:2)
Not just an open filesystem, but a LVM layer that has encryption built in. Of course, the ideal would be everyone moving to ZFS, but it would be nice to at least have a common filesystem and disk level encryption standard across platforms... preferably a FS that was made this century.
Re: (Score:1)
Re: (Score:2)
Encryption software needs to be inspectable and verifiable in order to be trusted with anything worth protecting.
Truecrypt is close-sourced. Its also one of the most popular and trusted encryption solutions.
Your statement is simply not correct, as regardless you can verify the software's output in many cases. Provide test input, provide test key, verify that you can decrypt the output on your own.
All that matters is that the encryption algorithm is open, vetted, and trusted; and that you can confirm that the software is, in fact, using that encryption algorithm.
Re: No. (Score:3)
Where the hell are you getting this information about truecrypt being closed-source? Go look at their website; the code is there.
"TrueCrypt is open-source and free software. The complete source code of TrueCrypt (written in C, C++, and assembly) is freely available for peer review..."
www.truecrypt.org/docs/?s=source-code
Re: (Score:2)
Im not really sure where I got that from, and was honestly surprised to see the source available. Its one of those things you "just know and have known for ages", which apparently was incorrect.
Re: (Score:3)
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.
Hardware encryption offers superior security to software encryption. That said it's not easy to generate entropy so if you do use software encryption you better have a source of entropy.
Hardware encryption is only superior if you (or someone you trust) can inspect the software.
For all you know, they use your passphrase to decrypt an hardcoded decryption key that's the same on all drives, so if you put your hard drive into someone else's enclosure, their passphrase will decrypt your data.
While I don't think they are doing anything so blatantly stupid, unless you can see the software, you don't know. A number of big-name "secure" USB drives had a big security flaw that was almost exactly [theprivacyblog.com] li
Re: (Score:3)
Hardware encryption offers superior security to software encryption. That said it's not easy to generate entropy so if you do use software encryption you better have a source of entropy.
Hardware encryption is only superior if you (or someone you trust) can inspect the software.
For all you know, they use your passphrase to decrypt an hardcoded decryption key that's the same on all drives, so if you put your hard drive into someone else's enclosure, their passphrase will decrypt your data.
While I don't think they are doing anything so blatantly stupid, unless you can see the software, you don't know. A number of big-name "secure" USB drives had a big security flaw that was almost exactly [theprivacyblog.com] like that.
Anologue is better than digital. Hardware is better than software. Also you have to read about and study the hardware fairly well before choosing the product. Those products you list all suck. The Aegis Padlock Pro does not have those problems by design.
But how do you know that? Were you sitting in on the design meetings?
For all you know, Aegis gave a list of back-door decryption keys to the Department of Homeland Security, just in case they need to access a terrorists drive. Maybe next year you'll be saying "Aegis products suck, their drives were full of back doors". Maybe Aegis is just a shell company run by the NSA to make people think that they are buying "secure" drives, but in actuality they are easily read by the government.
I have more faith in ope
Re: (Score:3)
Anologue is better than digital. Hardware is better than software.
Most recent hardware is digital. The reason software tends to be digital is because the underlying hardware is digital.
Re: (Score:2)
Hardware encryption offers superior security to software encryption.
What, so AES magically becomes more secure if it's implemented on an embedded processor instead of an x86 processor? Where do I sign up?
does it have a FBI unlock code? (Score:5, Interesting)
does it have a FBI unlock code?
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
This is not true -- in many circumstances, a judge can hold you in contempt of court for not revealing an encryption key, and you can sit in jail indefinitely until you cooperate. This is especially true if the encrypted information you have the password to gives evidence against someone else, not yourself, which the 5th amendment does not protect against.
That is exactly right. But if you don't give up the key they can call you a terrorist and not have to deal with that.
Re: (Score:2)
This is not true -- in many circumstances, a judge can hold you in contempt of court for not revealing an encryption key, and you can sit in jail indefinitely until you cooperate.
Which is a most unfortunate situation. If I had a physical, paper notebook with a bunch of 1's and 0's written on it, it is perfectly fine for me to shut the hell up regarding saying anything about it. So why should that change just because the 1's and 0's are stored on an HDD?
This is especially true if the encrypted information you have the password to gives evidence against someone else, not yourself, which the 5th amendment does not protect against.
That is an interesting scenario.. but as far as I am aware, it is not illegal for me to refuse to testify against someone.
Re: (Score:2)
In short, if you're testifying against someone else, you will be served with a subpoena. If you plead the 5th, you may be offered immunity. Should you still continue not to testify despite being granted immunity (thus nullifying protections against self-incrimination), you'll be held in contempt of court, again, indefinitely until you cooperate or the judge decides you've had enough.
Re:does it have a FBI unlock code? (Score:5, Insightful)
Re: (Score:2)
Court orders won't work in the USA as you can always plead the fifth in the United States. [cybercrimereview.com]
Where court orders wont work, rogue agents and vigilantes do. With enough pressure on you and your family you'll give them the unlock code eventually.
Re: (Score:2)
Re: (Score:2)
But that's not equivalent to having a backdoor to the device. If I catch a courier, who never knew the key code, no prison, gun or court order will do me any good. With a backdoor, however...
What about fake back doors? How do you determine which back door is the real door?
Re: (Score:2)
But that's not equivalent to having a backdoor to the device. If I catch a courier, who never knew the key code, no prison, gun or court order will do me any good. With a backdoor, however...
What about fake back doors? How do you determine which back door is the real door?
The unsafe ones often have tramp stamps above them.
Re: (Score:2)
What about fake back doors? How do you determine which back door is the real door?
By looking at the entropy of the result.
Re: (Score:2)
The nice thing about prisons, guns and court orders, is that those things never secretly happen to you without your knowledge. Go ahead, try to sneak-and-peek interrogate someone.
Re: (Score:2)
Go ahead, try to sneak-and-peek interrogate someone.
Hmm. Might be possible using rohypnol?
Re: does it have a FBI unlock code? (Score:2)
Or scopolamine, although I hear that's somewhat exaggerated...
Re: (Score:2)
Not even. It's set up as a PIN system. How many people will use a 4-digit pin?
Even if they use a 10-digit pin, there's still only 10 billion combinations.
The answer would be to form a hash from your input key, then feed that back through itself for several million rounds. Only the final result would be used as the decryption key. This is the same sort of setup used by KeePass and other password managers. A device specific salt would also be a help.
Re: (Score:2)
The answer would be to form a hash from your input key, then feed that back through itself for several million rounds. Only the final result would be used as the decryption key. This is the same sort of setup used by KeePass and other password managers.
If there are only 10 billion inputs then there are only 10 billion outputs (encryption keys) and a rainbow table turns the whole thing into a lookup.
A device specific salt would also be a help.
It would be a requirement to prevent rainbow tables but the list of usable keys is still limited to those 10 billion that could be generated using that salt value.
Universal FBI unlock code = LIFE IN PRISON (Score:2)
does it have a FBI unlock code?
When offered the chance to unlock your shit or be charged with something producing a life sentence which would you choose?
Re: (Score:2)
Flash drive with finger print reader? (Score:2)
How about just a flash drive with a capacitive finger print reader, so it needs to be unlocked before it functions as a flash drive?
Re: (Score:1)
I'm not sure what your suggesting here. Are you suggesting having an encrption system in the flash drive using you finger scan as the key or do you mean a flash drive that will not access the memory chip without first having you scan (i.e. the storage is in the clear but you need to swipe to connect the storage chip to the USB bus).
The first is sensible if the scanner can accuratley remake the key from the thumb print. Which may be possible but would require some tricks to get over the fact that thumb prin
Re: (Score:3)
Re: (Score:2)
"How about just a flash drive with a capacitive finger print reader..."
How about we look at the history of fingerprint bio-locks on storage devices...
http://www.pcworld.com/article/136439/article.html [pcworld.com]
As you can see, Sony has, in the past, made the fingerprint scanner a security vulnerability by combining it with another security function that was not so secure. Unless the touchpad on the device under discussion can be manipulated with a stylus, it too can have a similar vulnerability and may actually be use
Ironkey (Score:1)
Re: (Score:2)
So that's Ironkey then.
Well, except that the backdoor goes to NSA/CIA/FBI/DHL/BHO/ICE instead of Mossad.
Let's hope the product is more reliable than MySQL (Score:1)
Or I should say, Let's hope the product is more reliable than their MySQL server, which has given up and gone home.
Oh Dear (Score:2)
The DataLocker site seems to have slashdotted.
Looks pretty interesting, though...
Slashdot is offering covert ads now? (Score:2)
The Aegis Padlock Pro works just fine, it supports over 1TB and it has a SSD version. http://www.newegg.com/Product/Product.aspx?Item=N82E16822161085 [newegg.com]
Re: (Score:2)
Not revolutionary (Score:2)
SSD for speed, with USB? (Score:2)
Re: SSD for speed, with USB? (Score:2)
Primary advantage of SSDs is latency...and that's going to improve no matter how fast the connection is. But USB 3.0 is pretty Damn fast, with a theoretical max around 5 Gbps. SATA couldn't hit that until fairly recently. Of course, neither could USB...but they're nearly on par now.
Re: (Score:2)
Re: (Score:2)
A 7200 RPM drive can only do about 100 read or write operations per second at random locations. In the worst case, where you need to read 100 different files of size 4K scattered across the drive, you only get 400kB/s, which would fit over an USB1.0 connection. For reading long files (sequential reads), HDDs do less than 200 MB/s, but that's not as important for loading the OS and applications. SSDs are much better at random access (IOPS).
Not secure. (Score:4, Insightful)
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"?
Nice, but... (Score:2)
Higher capacity but otherwise similar to (Score:2)
Corsair Padlock II USB drive.
Touch screens provide a point of attack by looking at the smudges left by a finger on the glass. Even if the glass is wiped clean, microscopic analysis might show the common finger path. I think I'd trust mechanical buttons to be more reliable than a touch screen over a long period of time. They are also less likely to get broken during rough handling.
Re: (Score:2)
I wonder what sort of advantages there are to being a high-tech anything in Kansas.
Ask Google. [google.com]
Re: (Score:1)
Wow, I guess Kansas residents got lots of mod points today.
Way not to be able to take a joke. I guess I must have struck too close to home.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Only if the attacker is clueless enough to actually use the hardware to do the decryption without adding a SATA write blocker inline between the device and the drive.
Re: (Score:2)
That's potentially a much worse design than a design where the device generates the key and encrypts a copy of that key with your passcode, for several reasons: