Forgot your password?
typodupeerror
Security Hardware

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

Posted by Roblimo
from the the-mysteries-of-the-crypt-on-a-portable-hard-drive dept.
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.



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.

This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • NEAT (Score:5, Funny)

    by masternerdguy (2468142) on Wednesday February 27, 2013 @03:47PM (#43027435)
    Shut up and take my money!
  • Not new? (Score:4, Interesting)

    by Kenja (541830) on Wednesday February 27, 2013 @03:48PM (#43027447)
    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 (Score:5, Informative)

      by tepples (727027) <tepples@gmaiBLUEl.com minus berry> on Wednesday February 27, 2013 @03:52PM (#43027467) Homepage Journal
      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.
      • by Kenja (541830)
        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.
        • by tlhIngan (30335) <.slashdot. .at. .worf.net.> on Wednesday February 27, 2013 @04:37PM (#43027881)

          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.

          • by Kenja (541830)

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

            • by the_B0fh (208483)

              Most people can't read. Sounds like he just slapped a keypad on an OPAL drive.

              • by AliasMarlowe (1042386) on Wednesday February 27, 2013 @05:07PM (#43028177) Journal

                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.

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

                  • by Y-Crate (540566) on Wednesday February 27, 2013 @07:49PM (#43029387)

                    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.

                • 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

          • by rew (6140)

            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.

      • by bws111 (1216812)

        I've had a Lenovo drive that does that for quite a while now.

      • by mlts (1038732) * on Wednesday February 27, 2013 @04:54PM (#43028051)

        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.

      • 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

        • by godel_56 (1287256)

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

        • 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

    • by elucido (870205)

      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.

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

    • 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)

    by bill_mcgonigle (4333) * on Wednesday February 27, 2013 @03:53PM (#43027479) Homepage Journal

    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)

      by Anonymous Coward

      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.

      • 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

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

          • by elucido (870205)

            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

            • 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

        • by hawguy (1600213)

          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)

          by n7ytd (230708) on Wednesday February 27, 2013 @05:11PM (#43028213)

          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.

          • by elucido (870205)

            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.

            • by elucido (870205)

              Less human beings to trust with hardware. Less points of failure. Human beings are the problem.

              • by n7ytd (230708)

                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.

                • by elucido (870205)

                  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.

        • 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

          • by elucido (870205)

            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?

          • by elucido (870205)

            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]

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

    • by TeknoHog (164938)
      Sounds like a job for an FPGA. Then you'll only need to trust the bitstream compiler...
    • 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.

      • 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

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

  • by Joe_Dragon (2206452) on Wednesday February 27, 2013 @03:58PM (#43027531)

    does it have a FBI unlock code?

    • by Kenja (541830)
      They dont need an unlock code, they have prisons, guns and court orders to turn over the key code.
      • Court orders won't work in the USA as you can always plead the fifth in the United States. [cybercrimereview.com]
        • 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.
          • by elucido (870205)

            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.

          • by Golddess (1361003)

            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.

            • Type "jailed for refusing to testify united states" into google....

              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.

        • by ArhcAngel (247594) on Wednesday February 27, 2013 @04:32PM (#43027845)
          Obligitory [xkcd.com]
        • by elucido (870205)

          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.

      • by CSMoran (1577071)
        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...
        • by elucido (870205)

          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?

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

          • by CSMoran (1577071)

            What about fake back doors? How do you determine which back door is the real door?

            By looking at the entropy of the result.

      • by Sloppy (14984)

        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.

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

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

    • 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

    • by ArhcAngel (247594)
      you mean like this [imation.com] or this? [amazon.com]
    • "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

  • So that's Ironkey then.
    • by arth1 (260657)

      So that's Ironkey then.

      Well, except that the backdoor goes to NSA/CIA/FBI/DHL/BHO/ICE instead of Mossad.

  • Or I should say, Let's hope the product is more reliable than their MySQL server, which has given up and gone home.

  • The DataLocker site seems to have slashdotted.

    Looks pretty interesting, though...

  • 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]

  • I've been using one of these [lok-it.co.uk] at work for a while, which looks to be pretty much the same thing as the article, except the storage is smaller. The article reads like the new drive is revolutionary!
  • Pardon my ignorance, but does it really matter if it is SSD or HDD, when used via USB (3.0)? Isn't the USB bus itself the bottleneck in this case?
    • 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.

    • by ckthorp (1255134)
      With a spinning disk, the non-sequential access pattern will make the moving heads (and rotation rate) the limiting factor in throughput.
    • by fa2k (881632)

      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)

    by gmarsh (839707) on Wednesday February 27, 2013 @09:05PM (#43030039)

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

  • How long until someone reverse engineers the firmware to allow brute force cracking of the pincode without triggering an automatic data wipe? This isn't a matter of "if" but rather a matter of "when", IMHO.
  • 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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (8) I'm on the committee and I *still* don't know what the hell #pragma is for.

Working...