Slashdot Mirror
Lexar JumpDrive Password Scheme Cracked
Saint Aardvark writes "Lexar describes the
JumpDrive Secure as "loaded with software that lets you password-protect
your data. If lost or stolen, you can rest assured that what you've
saved there remains there with 256-bit AES encryption." @stake
has a different take: The password can be observed in memory or
read directly from the device, without evidence of tampering." And
best of all, the punch line: "[The password] is stored in an XOR
encrypted form and can be read directly from the device without any
authentication." That's why I use ROT-13 for my encryption needs."
Doesn't that violate DMCA?
ELOI, ELOI, LAMA SABACHTHANI!?
XOR'ed with what? XOR is just a method of encryption, not a cypher or anything... it's the basis for the one-time-pad, the strongest encryption method next to quantum encryption.
If ever there was an example of why we need product liability laws, this is it. Unlease the attack lawyers on these bums.
Democrat delenda est
I had one of those things. I'm glad that I always manually encrypted sensitive information instead of relying on their tool. That is until the drive mysteriously stopped working at all after about 6 months.
No way am I buying anything they make again.
Check out this enigma machine for sale. How cool is this.
& ca tegory=4721&item=2269717995&rd=1&ssPageName=WD VW
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem
Geeze... This is probably the first /. story I've read that ACTUALLY applies to me...
But seriously, I own one of these... In fact, they're pretty popular in my area just because their cheap and sold at Wal-Mart... I don't personally use the password protection because I always felt it was just an extra step and I didn't really need that much security on my Flash Drive anyways...
(It's not like I was storing all of my server's passwords on it or anything..... Honest...)
Thank you @stake and people like you for making sure products are as secure as they say they are...
I tried both calling them and trying their live chat feature from their website, but so far no response. The company is in California, and I am calling them about 3:30 PM EDT. So far, no responses from either the phone call (I am still on hold) or the live webchat.
Sounds awfully like a head-in-the-sand approach to security to me.
"No machine[usually meaning computer, but in this case a jumpdrive] is secure if the physical box is in the hands of the hacker/criminal."
That's not true. If my harddrive contains an encrypted filesystem, it does a "hacker" no good to steal my PC. He's mathmatically less likely to brute force that encryption than if he sniffed encypted email or SSL sessions.
If the hacker installs a keylogger, and I don't detect the intrusion when I return, then a second trip to physical access could break the security... but getting his hands on it once won't help.
That famous saying only applies if the machine gets some ongoing use after the hacker has physical access. (Thus it demonstrates a core flaw of DRM, etc)
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
No. There is no reason a device like this needs to store the password at all.
Properly, it shouldn't be a "password" at all, but a decryption-key you type before accessing the files. Type in the wrong key, and the files appear scrambled.
Isn't this in line with the whole "No machine[usually meaning computer, but in this case a jumpdrive] is secure if the physical box is in the hands of the hacker/criminal."
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
Nope. The jumpdrive is just a data storage device and if it only contains encrypted data, an attacker can only read the (probably useless) encrypted data it stores. You can't decrypt it unless you have the decryption key, or you can break the encryption algorithm.
The problem here is that the password necessary to decrypt the data is stored inside the drive itself. An ideal secure portable data storage device would only store the encrypted data and a program to decrypt the data with a user-supplied passphrase. Lexar made a stupid mistake--that's all.
However, the whole "No machine [usually meaning computer, but in this case a jumpdrive] is secure if the physical box is in the hands of the hacker/criminal." rule still applies. In this case, it means that there's no way the owner of a jumpdrive can prevent a thief from erasing the drive or reading any of its memory.
I mean, if you have the jumprdrive in your possession it's only a matter of time before you find a weakness to exploit, right?
No. It is absolutely possible to implement a symmetric encryption scheme that does not expose any details of the password and requires the password to be correct in order to decrypt the data.
For instance, instead of saving an xored version of the password (I'm assuming you need the cleartext of the password to run through your decryption algorithm), you can save a hash of the password. Then when the user enters their password, you compare hashes for correctness, and if there's a match, you use the cleartext they just entered.
Assuming all your math is done right and you're using strong crypto, there's nothing anyone could do to decrypt that data without a) knowing the password or b) having more computing power at their disposal than is currently available to any private citizen or group.
I am disrespectful to dirt! Can you see that I am serious?!
That's why I use the 256 bit blowfish on my encrypted drives. Not only is it sufficiently secure but it runs at a decent speed on all my systems (even the 400mhz Cellery I keep in my car). It scales all the way down to 4bit if I remember correctly.
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
Try telling that to Daniel Bernstein. His "Snuffle" code converts any hash into a cipher. To put it shorter: sampling the output of a well-designed hashing algorithm after every n bytes produces a suitably random bitstream; XORing that against the message produces a stream cipher.
> Thankfully, I don't know anyone who owns this.
I do, and I keep fairly sensitive information on it (in fact, I bought it in order to keep that information handy but secure). But I don't use Lexar's software--never even occured to me to try to use it, as I want to access it in Solaris and Linux. I use GPG; downloaded a GPG for Windows and put it right on the key so that I can use it in any Windows machine as well.
Chris Mattern
I suppose that the engineers who did this knew how to properly encrypt the passwords, but some product manager told them that they absolutely had to make the password retrievable.
Okay, boss, you got it.
-
The right way to do this would be to use the password to generate an encryption key and encrypt the data with it. Then, the only possible vulnerabilities are the password itself and various known-plaintext attacks.
No, there's one more... the user forgetting that password. Not exactly a compromise situation, but a support nightmare.
There are only 10 kinds of people in this world... those who understand binary and those who don't
dad once bought.
It had no keyhole, just a bunch of magnectic "reeds" that would line up when a special magnetic key was put along side of it. My dad had just purchased it that day and was explaining to me how it worked. I asked, "couldn't you just shake it until the reeds lined up?". He tosses the lock to me and says, "here...try it then". I shook the lock for a couple of seconds and, sure enough, it popped right open.
my dad was pretty grumpy for the rest of the day...
A goal is a dream with a deadline
Not completely true. If you look at the techniques of hash functions you'll understand why. They are very much like symetric encryption. You can even encrypt something by starting off with a "key", hash that, then hash the result of that, etc. etc. Now you have basically a stream cipher.
It also works for small data units, like e.g. keys. Hash a (sufficiently difficult) password and xor the result of the hash with the (symetric) key and presto.
I use gpg on everything I put on my jump drive. It's not like the software to "secure" the data runs on linux anyway.
irc.enterthegame.com #linux
I sent an email to Lexar support demanding a refund for my "Secure" Jumpdrive. While I never used the "security" feature that they offer (I bought this because it was cheep at Sam's Club), this is still deceptive advertising. I don't think you can claim a product as "secure" when it is trivial for someone to bypass security.
As one poster commented, "Why not just use ROT-13 to hide the password?"
If Lexar replies, I'll post a follow up. If they don't, then it is off to the BBB to get things fixed.
Bestcrypt http://www.jetico.com/ encrypts swap files too, so all you can get with your grepping is just @(#*)$#)$*)#*(#*^0
Online backup with Mozy, sounds like Ozzie, but more!
I spent a little while analyzing the "CruzerLock" software that came with my Cruzer Mini USB drive. It appears to be using a 64 bit block cypher (perhaps DES) which pretty much rules out any of the more modern encryption algorithms.
Its biggest readily apparent weakness is that the encryption algorithm is running in ECB mode. If you have a file containing AAAAAAAAAAAAAAAAAAAAAAAA it will encrypt to an 8-byte repeating block on the drive, like this: 123456781234567812345678 When I changed that to AAAAAAAAbbbbbbbbAAAAAAAA I saw the following encoding: 12345678abcdefgh12345678. That indicates Electronic Code Book. If I learn what your first block means, I know the third block means exactly the same data. (Please note that these are just example values with nice visual properties, and not the exact values I saw!)
Also, the encryption is the same from file to file. AAAAAAAA encoded in one file produces exactly the same results as AAAAAAAA encoded in another. So the IV for the encryption routine is fixed as well.
At least XORing blocks of encrypted binary nulls with two different keys didn't quickly reveal any obvious common bits, nor did encrypting two successive blocks that differed only by a single bit of plaintext. That means it's at least more than a plain old 8-byte XOR cypher using a folded password.
I figure if I can find all those holes in an hour of poking around with a hex tool, I know they didn't actually hire any cryptographers to produce the software. All the alarm bells have already gone off, and I never even stepped into it with a debugger to learn how they fold your password into a key, or what the IV was, or what the encryption algorithm itself was.
John