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