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."
Why go through all the trouble of attaching a debugger to the process when you can bribe the user to tell you the password with a chocolate bar! Best of all, this trick will still work long after Lexar fixes their security issue.
Doesn't that violate DMCA?
ELOI, ELOI, LAMA SABACHTHANI!?
Three years to get .01% of the way done cracking this before someone realized it was ROT13. ;)
The password is in XOR'd form? Yeah. That's encryption.
Couldn't the software or driver have stored the password in a MD5 or SHA1 form, and still present a valid authentication mechanism for end users?
From the article:
Vendor Response:
08-05-2004 Vendor contacted via email to support@lexarmedia.com
No response.
08-12-2004 Vendor contacted again via email to support, sales
Public Relations, Investor Relations, and general
inquiry email addresses.
08-12-2004 Automated response from support received
09-13-2004 No further response from vendor, advisory released
Vendor has not acknowledged issue or produced a fix.
This is a pretty embarassing non-response.
The product is only about 5 or 6 months old, and the password was just sitting there. AES is a perfectly fine standard for encryption, but this is an embarassing implementation. Thankfully, I don't know anyone who owns this.
EVERYTHING violates the DMCA. Everything. Even talking about violating the DMCA violates the DMCA.
"I'm just here to regulate funkiness."
That's what happens when you get your security developers from the Cue::Cat Development team. Wasnt' their 'encryption' just XOR or something similar?
It allows those who forget their passwords to quickly access the 'lostpaswd?' file, saving on support calls.
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
You will be legally liable for the legal consequences of any attempt to break through this advanced encryption technology.
"It is a greater offense to steal men's labor, than their clothes"
The number one rule of talking about the DMCA and archiving the results, encrypted, on a Lexar JumpDrive.
You do NOT talk about DMCA and archive the results, encrypted, on a Lexar Jumpdrive!
That's why I use DriveCrypt. I got my version years ago and it's pretty antiquated but it supports up to 1024 bit encryption (granted it makes things relatively slow).
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?
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.
Why does the password need to be 'stored' anyway? Isn't that kinda the point?
Is this some sort of 'encrypted session key' thing where one long, secure password decrypts another shorted one that's used to do the dirty work? Is it stored for key recovery by tech support droids?
Why store the password? Is this just the worst implementation in the whole world or am I missing something?
I was always forgetting important things, like the meaning of the word "redundant." But thanks to the Joe Johnson memory system, I can now remember things like the meaning of the word "redundant." Thanks, Jack!
Copyright 2004, Jake Johannson Memory systems.
"I'm just here to regulate funkiness."
That's why I use ROT-13 for my encryption needs
Pshaw...That's real secure! You really should be using double, or better yet, quadruple Rot-13...
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
...that the best encryption algorithm is worth nothing if you fuck up the implementation...
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...
Re-check that ip address.
[The password] is stored in an XOR encrypted form and can be read directly from the device without any authentication.
That's not much of a punchline when you realize that XORing something to something unknon (and presumibly unknowable) is unbreakable excryption.
I use ROT-26.
-
That's why I store and transmit all my data as plain text.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Sure, ROT13 is secure. But why not give potential crackers something to cry about: encrypt it twice!
This sig is only here so people stop skipping the last lines of my posts.
a DOS floppy disk, as straight text in a file, called COMMAND.COM. I have a a big red label on the disk, "BOOT".
Noone ever stole any of my passwords.
I use MD5. Not one collision ever found in the wild.
On the off chance that this isn't a joke, and you're one of the genii on /. who thinks that MD5 has anything to do with cryptography, let's reiterate:
MD5 is a hashing algorithm. All hashing algorithms are guaranteed to collide, since hashing is the process of reducing an N-fold dataset to an M-fold one, where M<N.
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
Tubal-Cain smokes the white owl.
There we go.........my little brother won't keep his porn on one of these anymore. haha
-Randy
ROT13 ... oooohhhh! 13!!! Shit, I was using 11! No wonder it wasn't working.
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.
XOR means "exclusive or". A regular "or": if one of the inputs is 1, return 1. An "exclusive or": if one of the inputs is 1, but not both, return 1.
OR:
0101
0011
----
0111
XOR:
0101
0011
----
0110
AND:
0101
0011
----
0001
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
MD5 *does* have something to do with cryptography (why else would Schneier devote the whole 14th chapter of Applied Cryptography to "One-way hash functions"), and the reason is simple: it is used to encrypt your *password*, not your data (Lexar was claiming that they use 256-bit AES encryption for the data itself).
For authentication you do not store the password in plaintext, only its MD5 hash, when user enters the password, MD5 of that is computed and compared to the stored MD5 string, if they match -- your user is authenticated. Of course XOR with a "magic number" could be used for the same purposes, but it would be much weaker. Thus, I think that the GP was not a troll and made a valid point: use MD5 to hash your passwords, and preferrable add some salt value to prevent against dictionary attack.
The other questiuon is why did Lexar had to store passwords on the drive at all, one does not need to authenticate users in their scenario (the drive itself is not a self-cointained computer to which a user needs to gain access) -- they could've just asked for the password, convert it to the key used in AES algorithm, decode the data and give the result: if password is incorrect, the decoded data is garbage.
Paul B.
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.
I've seen a number of posts stating the XOR is unbreakable. Hopefully they're just joking and didn't get modded as such, because I've read in several places that XOR sucks. A quick Google revealed the following.
Hack-FAQ
And I quote: XOR encryption is trivially simply to implement and equally trivial to break. XOR encryption should not be utilized for any data which you would want to protect.
I could go grab my Applied Cryptography book and make sure, but it's out of arms reach right now.
After being put on hold for over twenty minutes, I finally spoke with a man named Henry who said that he has never heard that JumpDrive had a security problem (even after I confronted him with the advisory from @Stake), and did not know that @Stake was trying to contact them for over a month. He was quite shocked but promised to check out /. and @Stake to verify the claim.
The ostrich finally wakes up.
Not if the key was exactly as long as the message. In that case, we'd have a system equivalent to a one-time pad (i.e., unbreakable) so long as the key was kept secure.
In this case, it might be feasible to XOR an 8-character password with 8 random bytes (those 8 random bytes would be the key). The problem isn't the XOR operation. The problem is maintaining the security of the key itself.
Statistical attacks can only work when there is a lot of ciphertext, AND the key is significantly shorter than the message.
I needed a way to make a "secure zone" similar to what Lexar was advertising - a place where I could drop files and have them automatically protected. After doing a fair amount of research, I decided to use PGPDisk. It allows you to create a PGP-encrypted file on any device (hard drive, CD, USB key, etc) which "expands" into a virtual drive (e.g. "C:\Private\SecretStuff.dsk" becomes a new "Removable drive G:" in Windows once you enter the password). Anything you drop into the virtual drive becomes encrypted. It uses 128-bit symmetric CAST algorithm, which is plenty strong enough for anything I'd need. (I believe the newest versions may also have a Twofish algorithm option). PGPdisk virtual drives can be up to 4Gig on a FAT32 machine, or unlimited size under NTFS.
You can check out the commercial version at http://www.pgp.com/, but I would also seriously consider PGPckt 6.58, a forked and free version that works just fine under WinXP (and previous versions of Windows). That's the version I've been using.
This kind of thing just burns me up. Clueless companies hire clueless developers who think they can make software or hardware relatively secure by mearly applying encryption in whatever way they think is convenient. Never mind the plain-text password behind the curtain. Never mind that xor is equivalent to plain text (Lexor). Never mind that supporting multiple decription keys reduces the effective key length (DVD). Never mind that if you somehow store the decryption keys in a way that the software retreive (DVD again) that anyone can extract them. Never mind that storing a strongly-encoded password along with a weakly-encoded one buys you nothing (Microsoft). Never mind that encryption can't prevent copying (DRM). Never mind that this list can go on forever...
I own a JumpDrive Secure. Don't laugh; I only got it because Wally World didn't have the regular 256MB one. I plugged it in and the first thing it did was install their security software *without asking me*. Yes, Windows XP. Yes, I had turned AutoRun off on my CD. No, I have no idea how to disable AutoRun on a device that has never been plugged in before. Grrrr.
What did I do? I used Linux to reformat the JumpDrive then uninstalled the software it added without my permission. Now I have a perfectly usable device. (This was 4 months ago)
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.
For some bizarre reason, this reminded me of a story I once heard somewhere (no longer rememeber where).
Some guy was living with a bunch of others and always had a problem with them drinking up his milk. So one day he simply wrote "Milk Experiment" in big letters on the carton and never had another issue.
Oh really?
------------------
#!/usr/bin/perl -w
use strict;
use Digest::MD5 qw(md5_hex);
# Create a stream of bytes from hex.
my $bytes1 = map {chr(hex($_))} qw(
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70
);
# Create a second stream of bytes from hex.
my $bytes2 = map {chr(hex($_))} qw(
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70
);
# Print MD5 hashes
print md5_hex($bytes1), "\n";
print md5_hex($bytes2), "\n";
------------------
What do I win?
How's this for ROT-13?
Bu abrf! Yrkne = shknerq!
did you know you can open a bicycle lock with a bick pen?
But the key cannot be kept secure, as I need only enter a known password on a known device, get the "encrypted" text and XOR it against my original password. Since XOR is symetrical, A^B = B^A, then we are guaranteed that (A^B)^A = B, and *poof* we derive the magic password.
A single XOR when I can generate more than one "encrypted" text is no security at all.
One-Time pad means ONE-TIME ! If you use it twice, the security becomes exactly Zero.
Jeff Naujok
Life, the Universe, and Everything... in my image.
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.
Yes, but the problem is using the pad again. Nothing to do with XOR. Notice that any key-combining operation must be a bijective operation (i.e., "one to one, and onto"). Thus, at least theoretically, you can determine the key by comparing various plain/ciphertext pairs, regardless of which key-combining operation was chosen. Yes, XOR makes this slightly easier. So?
XOR is not the problem. The fact that the key is reused, and is most likely much shorter than the plaintext, is the problem.
- Format your pen drive to MS-DOS
- Create an encrypted, password protected disk image roughly the size of your pen drive (also in MS-DOS format)
- Store the disk image on your pen drive
The reason I recommend using MS-DOS format for both the disk and disk image is two-fold. First off, you can use the extra space not taken up by the disk image to grab files from a PC (since both the Mac and PC can read the MS-DOS file system), and because if you use HFS+, the Mac will store all sorts of file extras on the disk, giving you much less usable space (same reason you can't get the full 654 or 700 MB when you burn an HFS+ CD).I would also recommend storing a fake
Ack!
Truecrypt (mirror 1 [freewebtown.com], mirror 2) does the same as PGPdisk but is open-source and seems to still be actively developed, unlike PGP658ckt. It also doesn't have the drive size limitations of some competing commercial products.
Damien
... but I found that the decryption key was inconveniently large, being the same size as the original data.
"Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption"
... repeat until you get to Xn (n being the length of your message)
Count me an idiot then. I should mention why:
(a) take your key. MD5 it. Store this as X1
(b) Take X1. MD5 it. Store this as X2
(c)
(d) For each 64-byte segment of your message, XOR it with one of the numbers in the sequence you just generated
To decrypt the message, do exactly the same thing.
I bought it for the following reasons:
- Good cost per MB
- Fast
- Great rebate offer at the time
- DURABLE! This thing looks a little bulky, but it's rock solid. Thick plastic, really solid. Unlike any other I've seen so far.
I never used the security stuff. IMHO not worth it. But having such a durable, fast, cheap device was more than worth it to me.
I don't regret my purchase. It's a solid product. I'd still recommend it.
"me" is too short for a decent password :)
karma capped
Since no one else is stupid enough to use that pad, it's a one time pad.
Another milestone in encryption technology - One time Pad CRACKED!
Emergency patch: Now they use the Pad "000000000...."
I think you just killed Schrodinger's Cat.
would be jetico's bestcrypt.
http://www.jetico.com/
supports twofish and blowfish too and even GOST too, all the way up to 446bit of keylength.
a must have for any paranoid nut
Online backup with Mozy, sounds like Ozzie, but more!
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
I know this is a troll, but interesting point. Make it so Winboxes (except those with Ext2 for Windows (or whatever it's called)) can't read it... But there's a couple problems. You might NEED it on Windows eventually (I use Linux on my main computer, but I interact with Windows computers EVERY DAY), and that Ext2 for Windows. The second cancels out the first, but then how do you get it on the box? Carry TWO JumpDrives, or a CD with it burned on?
Also, if you only work with Win2K/XP boxes, there might be a way to use NTFS encryption, and format it like that. You could also use some Linux filesystem's encryption, and have a FAT12 partition with a driver for that filesystem (AFAIK, you can partition JumpDrives with Linux).