Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Roblimo on 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.

110 of 154 comments (clear)

  1. NEAT by masternerdguy · · Score: 5, Funny

    Shut up and take my money!

    --
    To offset political mods, replace Flamebait with Insightful.
    1. Re:NEAT by pushing-robot · · Score: 2

      Mod This Plaid.

      --
      How can I believe you when you tell me what I don't want to hear?
    2. Re:NEAT by camperdave · · Score: 3, Insightful

      Mod This Up.

      Mod This Down.

      Sigh! You win some, you lose some.

      --
      When our name is on the back of your car, we're behind you all the way!
    3. Re:NEAT by SeattleGameboy · · Score: 1
      Sigh!???

      You are an awfully loud sigh-er...

  2. Not new? by Kenja · · Score: 3, Interesting

    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.

    --

    "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    1. Re:Not new? by elucido · · Score: 1

      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.

    2. Re:Not new? by MichaelBall · · Score: 1

      I've also used the Apricorn Aegis Padlock for quite some time now to securely transfer media between my Windows 7, Ubuntu, and OSX machines... No drivers required... Just a nice little keypad...

    3. Re:Not new? by shutdown+-p+now · · Score: 1

      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.

    4. Re:Not new? by Lord+Byron+II · · Score: 1

      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.

    5. Re:Not new? by blakelarson · · Score: 1

      Because it would take a really long time to physically enter the 15-digit passcode enough times to crack. However, if you just take the drive out, you could try to crack the encryption must faster. Therefore, the encryption should be at a higher level than the passcode.

  3. Requires no drivers by tepples · · Score: 4, Informative

    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.

    1. Re:Requires no drivers by Kenja · · Score: 2

      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.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    2. Re:Requires no drivers by bws111 · · Score: 1

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

    3. Re:Requires no drivers by tlhIngan · · Score: 5, Informative

      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.

    4. Re:Requires no drivers by Kenja · · Score: 2

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

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    5. Re:Requires no drivers by the_B0fh · · Score: 1

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

    6. Re:Requires no drivers by mlts · · 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.

    7. Re:Requires no drivers by AliasMarlowe · · Score: 3, Interesting

      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.

      --
      Those who can make you believe absurdities can make you commit atrocities. - Voltaire
    8. Re:Requires no drivers by LordLimecat · · Score: 1

      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.

    9. Re:Requires no drivers by godel_56 · · Score: 1

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

    10. Re:Requires no drivers by smallfries · · Score: 1

      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.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    11. Re:Requires no drivers by Y-Crate · · Score: 3, 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.

    12. Re:Requires no drivers by GWRedDragon · · Score: 1

      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.

      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 device is extremely dangerous!

    13. Re:Requires no drivers by smallfries · · Score: 1

      Thanks for the reply - that's a really interesting use for them.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    14. Re:Requires no drivers by rew · · Score: 1

      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.

    15. Re:Requires no drivers by cryptizard · · Score: 1

      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 will be significantly smaller than the difference between images of two different fingers, and the entropy you get from this is enough that you can do some cryptographic error correction magic to extract good, deterministic keys.

  4. No. by bill_mcgonigle · · 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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:No. by Anonymous Coward · · 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 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.

    2. Re:No. by Anonymous Coward · · Score: 1

      Use TrueCrypt [truecrypt.org] to create an encrypted volume within the USB drive.

      The advantage to a system like the parent mentions is that you don't have to install TrueCrypt on the machine you're plugging the USB drive into.

    3. Re:No. by hawguy · · Score: 2

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

    4. Re:No. by Githaron · · Score: 1

      Now if we only had a open filesystem specification that is implemented by all operating systems natively ...

    5. Re:No. by hawguy · · Score: 2

      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 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 open source software because even though I'm not a security expert and can't validate the software myself, I trust that there's no global coalition of open source security software experts that are are all conspiring to steal my data - if there's a vulnerability in the code, it will be found and can't be kept secret.

    6. Re:No. by LordLimecat · · Score: 1

      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.

    7. Re:No. by LordLimecat · · Score: 1

      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.

    8. Re:No. by mlts · · Score: 1

      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.

    9. Re:No. by LordLimecat · · Score: 2

      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.

    10. Re: No. by Urza9814 · · Score: 1

      "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

    11. Re: No. by Urza9814 · · Score: 2

      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

    12. Re:No. by fa2k · · Score: 1

      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?

    13. Re: No. by LordLimecat · · Score: 1

      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.

    14. Re: No. by LordLimecat · · Score: 1

      I stand corrected, Im not sure where I got the idea it was closed source.

    15. Re: No. by Threni · · Score: 1

      Some Linux distros don't include it because they're not happy with its license.

      http://lists.freedesktop.org/archives/distributions/2008-October/000276.html

    16. Re:No. by Bing+Tsher+E · · Score: 1

      The fact that it's on an embedded processor means it's hardware partitioned completely away from any third-party software. Why are you worrying about what type of processor is in use? The embedded processor in question might even be an x86 processor for all we know.

  5. does it have a FBI unlock code? by Joe_Dragon · · Score: 5, Interesting

    does it have a FBI unlock code?

    1. Re:does it have a FBI unlock code? by Kenja · · Score: 1

      They dont need an unlock code, they have prisons, guns and court orders to turn over the key code.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    2. Re:does it have a FBI unlock code? by glittermage · · Score: 1

      Court orders won't work in the USA as you can always plead the fifth in the United States.

    3. Re:does it have a FBI unlock code? by CSMoran · · Score: 1

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

      --
      Every end has half a stick.
    4. Re:does it have a FBI unlock code? by Midnight_Falcon · · 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.

    5. Re:does it have a FBI unlock code? by ArhcAngel · · Score: 4, Insightful

      Obligitory

      --
      "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    6. Re:does it have a FBI unlock code? by Stavr0 · · Score: 1

      Failing that, drugs and a $5 wrench. [xkcd #538]

    7. Re:does it have a FBI unlock code? by elucido · · Score: 1

      Court orders won't work in the USA as you can always plead the fifth in the United States.

      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.

    8. Re:does it have a FBI unlock code? by elucido · · Score: 1

      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.

    9. Re:does it have a FBI unlock code? by elucido · · Score: 1

      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?

    10. Re:does it have a FBI unlock code? by Sloppy · · Score: 1

      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.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    11. Re:does it have a FBI unlock code? by Antipater · · Score: 1

      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.

      --
      Everything is better with chainsaws.
    12. Re:does it have a FBI unlock code? by Jeremi · · Score: 1

      Go ahead, try to sneak-and-peek interrogate someone.

      Hmm. Might be possible using rohypnol?

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    13. Re:does it have a FBI unlock code? by Golddess · · Score: 1

      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.

      --
      "I'm not sure I like the fugnutish tone you used in your post!" -RogL (608926)-
    14. Re: does it have a FBI unlock code? by Urza9814 · · Score: 1

      Or scopolamine, although I hear that's somewhat exaggerated...

    15. Re:does it have a FBI unlock code? by godel_56 · · Score: 1

      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.

    16. Re:does it have a FBI unlock code? by CSMoran · · Score: 1

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

      By looking at the entropy of the result.

      --
      Every end has half a stick.
    17. Re:does it have a FBI unlock code? by CSMoran · · Score: 1

      The system for destroying anything cannot be provably secure. Nevermind cloning the device and working on a copy.

      --
      Every end has half a stick.
    18. Re:does it have a FBI unlock code? by Anonymous Coward · · Score: 1

      Randall Munroe should publish a list of the top 10 to 20 referrers to xkcd; it would be interesting to see where Slashdot is in the list.

    19. Re:does it have a FBI unlock code? by DFurno2003 · · Score: 1

      a what?

    20. Re:does it have a FBI unlock code? by Fnord666 · · Score: 1

      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.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    21. Re:does it have a FBI unlock code? by Midnight_Falcon · · Score: 1
      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.

  6. Flash drive with finger print reader? by Dwedit · · Score: 1

    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?

    1. Re:Flash drive with finger print reader? by archshade · · 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 prints can change over a matter of hours. - I don't want to give myself a paper cut and find that I cant access my data until it's fully healed (if it fully heals and I get an identicle finger print).

      The second just smacks of being a bad idea it seems to suggest that there is no possible way to access infomation on the flash chip than to use the pre-packaged connector. - This is just plain false if the NAND flash chip is seperate (as most are) then it is a reletivley simple matter for some one skilled in the art of soldering to remove it and put it on a new carrier board, possible the same model as it came from. There are things you can do (wipe on case open, SiP, SoC) but these can usually be circumvented with a little thought. OK this solution will stop your wife/girlfriend mother finding thos file you don't want them to see but not any determind attacker. Which makes it little more than a toy solution.

      I have not watched the video but judging by other comments this product seems sensible in that it encrypts the data passed on a keyed entry key. I'm sure I have seen this tech before though just not sure where, maybe I dreemed it, it seems obviouse now someone says it.

      --
      Most Damage is done by people who are AWAKE
    2. Re:Flash drive with finger print reader? by ArhcAngel · · Score: 2

      you mean like this or this?

      --
      "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    3. Re:Flash drive with finger print reader? by Anachragnome · · Score: 1

      "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

      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 used to harvest fingerprints.

  7. Ironkey by zaax · · Score: 1

    So that's Ironkey then.

    1. Re:Ironkey by arth1 · · Score: 1

      So that's Ironkey then.

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

  8. Re:High-tech entrepreneur in Kansas by CanHasDIY · · Score: 1

    I wonder what sort of advantages there are to being a high-tech anything in Kansas.

    Ask Google.

    --
    An enigma, wrapped in a riddle, shrouded in bacon and cheese
  9. Oh Dear by ios+and+web+coder · · Score: 1

    The DataLocker site seems to have slashdotted.

    Looks pretty interesting, though...

    --

    "For every complex problem there is an answer that is clear, simple, and wrong."

    -H. L. Mencken

  10. Slashdot is offering covert ads now? by elucido · · Score: 1

    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

    1. Re:Slashdot is offering covert ads now? by jones_supa · · Score: 1

      Then why are you meta-advertising the Aegis Padlock Pro?

  11. Universal FBI unlock code = LIFE IN PRISON by elucido · · Score: 1

    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?

  12. Re:High-tech entrepreneur in Kansas by gaudior · · Score: 1

    No, you just weren't funny. /not from Kansas //really

  13. Hell no by elucido · · Score: 1

    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.

    1. Re:Hell no by ultrasawblade · · Score: 1

      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.

    2. Re:Hell no by hawguy · · Score: 1

      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 entropy as a big weakness of software, but there's no evidence that this device has a hardware random number generator (and why would it for an event that takes place maybe once in its lifetime), so it gets entropy the same way your computer does. By combining data from a number of "random" sources (hardware clock, timing hardware interrupts, etc).

    3. Re:Hell no by n7ytd · · Score: 3, 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.

    4. Re:Hell no by LordLimecat · · Score: 1

      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.

    5. Re:Hell no by elucido · · Score: 1

      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 design of Truecrypt is secure. You also don't know your compiler is any good. And no, the soundcard is not a good enough source of entropy.

    6. Re:Hell no by elucido · · Score: 1

      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.

    7. Re:Hell no by elucido · · Score: 1

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

    8. Re:Hell no by elucido · · Score: 1

      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?

    9. Re:Hell no by elucido · · Score: 1

      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

    10. Re:Hell no by ultrasawblade · · Score: 1

      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 hardware implementation that I can never see.

      You are correct, to really trust your own compiler you do have to compile your compiler from source.

      Well, it'd be better if they could integrate quantum randomness into all encryption devices (http://qrbg.irb.hr/) but my understanding was that the least significant bits of most cheap ADCs are really noisy and effectively random.

    11. Re:Hell no by n7ytd · · Score: 1

      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.

    12. Re:Hell no by elucido · · Score: 1

      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.

  14. Re:High-tech entrepreneur in Kansas by Darkness404 · · Score: 1

    Eastern KS/Western MO are actually pretty good places for high-tech companies. You've got pretty good infrastructure (Google Fiber anyone?) , a good base of educated workers and a much, much friendlier business environment when compared to silicon valley.

    --
    Taxation is legalized theft, no more, no less.
  15. Not revolutionary by carvell · · Score: 2

    I've been using one of these 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!

  16. Re:Fail: crackable in just two days w desktop PC by carvell · · Score: 1

    Not really...

    I have something similar and as you would expect, the encryption key is wiped after 10 PIN attempts, rendering the data useless.

  17. UDF by DrYak · · Score: 3, Interesting

    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.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:UDF by blueg3 · · Score: 2

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

    2. Re:UDF by shutdown+-p+now · · Score: 1

      Is UDF really worse for traditional hard drives or SSDs than FAT32?

  18. SSD for speed, with USB? by cpghost · · Score: 1

    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?

    --
    cpghost at Cordula's Web.
    1. Re: SSD for speed, with USB? by Urza9814 · · Score: 1

      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.

    2. Re:SSD for speed, with USB? by ckthorp · · Score: 1

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

    3. Re:SSD for speed, with USB? by fa2k · · Score: 1

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

  19. Re:Fail: crackable in just two days w desktop PC by dgatwood · · Score: 1

    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.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  20. Re:Fail: crackable in just two days w desktop PC by carvell · · Score: 1

    I think you may have misinterpreted how the device works.

    Certainly with the FIPS device I use, there are 6 factory programmed 256 bit encryption keys stored in the device. All the pin code does is unlock the factory code that is currently in use in the encryption hardware. The encryption keys are not derived in any way from the pin code.

    If you get the pin wrong 10 times then one of the encryption keys is erased and you move onto the next one. Once 6 have been erased, the device is permanently useless. This all happens well before any attempt to access the data via sata or any other means.

  21. Re:Fail: crackable in just two days w desktop PC by dgatwood · · Score: 1

    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:

    • You have no assurance that the manufacturer doesn't have a copy of the keys (zero security from a subpoena, for example).
    • Even if they don't have a copy, depending on how the key is stored, a skilled attacker might be able to trivially read the crypto key right out of the chip in minutes with appropriate microscopy techniques, with no computation necessary.
    • The data is effectively gone if the case fails in any way, assuming there is no way for the user to make a backup copy of the key.
    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  22. Not secure. by gmarsh · · Score: 3, 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"?

    1. Re:Not secure. by Anonymous Coward · · Score: 1

      It's called stealing the key. And it doesn't break anything. When you have the key, you don't HAVE to break in. You just unlock the door. A trojan horse keylogger is cute, but not easy to deploy, and it does NOT break TrueCrypt any more than me giving you my car keys breaks my car's security.

  23. Zalman ZM-VE400 by Trubadur · · Score: 1

    http://www.zalman.com/eng/product/Product_Read.php?Idx=750
    Virtual Drive + External HDD Case
    Real Time 256-Bit AES Hardware Encryption

    Dimensions: 146(L) x 80.8(W) x 14(H)mm
    Weight: 91g (except hard disk)
    Materials: Aluminum alloy, Acryl, Poly Carbonate (PC)
    External Interface: USB1.1 Max. 12Mbps
    USB2.0 Max.:480Mbps
    USB3.0 Max.:5Gbps
    Internal Interface: S-ATA I/II
    Compatible HDD Size: 2.5'
    Power: Input : DC +5V (USB Powered)
    Supported OS: Window 98 / ME / 2000 / XP / VISTA / 7, Mac OS, Linux
    Color: Black/Silver

    --
    :. Smith & Wesson: The original point and click interface.
  24. Nice, but... by fragMasterFlash · · Score: 1

    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.

  25. Higher capacity but otherwise similar to by mark_reh · · Score: 1

    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.

  26. Developers easy to find in Kansas City? Nossir. by pancho+flaco · · Score: 1

    There are lots of employers looking for talent here in KC, and having trouble finding it. I code .NET and constantly have folks banging on my door. The Midwest vibe here is pretty laid-back, and KC has a long tradition of arts and philanthropy for a mid-size city. If you're looking for a change, come check us out - I could use some co-workers!

  27. Several UDF builds, Plain is for harddisk+flash by DrYak · · Score: 1

    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 writing). There's also the "Spared build" which is optimized for R/W optical media (similar to ISO with packet writing on CD-RW). Although this one is tailored for optical media, it isn't as widely available. Most computer can use it, every single recording appliance (DVD-R / -RW based video recorders or cam-coders) can use it. BUT NOT ALL media reading appliance. Most DVD players, for example, don't. That's why you have to "finish" a DVD you've recorded before it becomes available on a regular living room DVD player.

    for references, see here.

    So the suitability of UDF for a flash device depends on the choosen build.

    If one use one of the optical-media-optimised builds, as you suggest, that would be a very bad choice:
    - It's indeed not designed for flash.
    - It's not widely supported. (You in-car entertainment, or your living room DVD player might lack software support for it. Though your computer should be able to read it).

    I was referring to using the "plain build".
    - This one is designed with for fully random read/write devices.
    - It's supported nearly everywhere (read-only optical media happen to use the same, for simplicity, to avoid excessive headache with the "writeable optical media" optimisations), so even a DVD player is one simple firmware upgrade away from using it on its USB port too. (Unlike ExFAT which isn't currently available on lots of devices). And given how UDF has been embeded almost everywhere, it's not difficult to imagine embeding it into photo cameras and other appliances without optical media.
    - It supports some more advanced features as FAT, like POSIX file attribs.
    - It is not based around stupid outdated design like allocation tables (it did make sence in the 70ies: it was optimised for the limitation of computers then. Now we're in 2013, but exFAT is still using some variation of it).
    - So basically UDF is less awful than keeping FAT and ExFAT.

    Apple makes it pretty easy to implement HFS+ if you want to.

    Yes (unlike the patent mine field of FAT/ExFAT). Nevertheless, beside Apple devices and Linux PC with the corresponding driver compiled in, machines with HFS support aren't widespread. Unlike UDF.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]