Lexar Secure Jumpdrives
Brian Kelsay
Brian.Kelsay at kcc.usda.gov
Tue Dec 14 11:14:49 CST 2004
That, my friend, was an awesome post. This may sound like a simple thing to you, since you have been dealing with encryption for a while, but have you thought of doing a detailed write-up and sample scripts to get a person new to encryption started? That would be a cool thing to post to http://www.gnupg.org/(en)/documentation/howtos.html or as a small project on freshmeat. (e.g. Encrypted Jumpdrive/Pendrive Howto)
Just a thought.
Yes, the attempt to be cross-platform is usually the wrench in the works.
I have seen some real small USB fobs that I think only carry an encryption key. They are only about a half inch long or just a bit more. Have you seen those and do they work in Linux? If they work, they might be just the thing. I imagine that if you look at them in Linux, you will find that they only contain a fat16 filesystem with 1-8 MB of flash, maybe less. A private key takes up how much space if it is in a text file or compressed? Not much, maybe a few kb.
Brian Kelsay
>>> Jason Clinton <me at jasonclinton.com> 12/14/04 10:55AM >>>
Well, I put all the questions here together because my suggestion encompasses
all of them. The Lexar encryption hardware is not compatible with Linux; it's
done in hardware and, IIRC, it's extremely simple (easy to crack) but no
device driver exists. Rather than worry about having enough size on either
the encrypted partition or the non-encrypted partition, I suggest that you
partition and format the whole thing in VFAT32 and place a copy of gnupg on
the device. There's a number of ways that you can do it but here's one
scenario that can vary in size and is compatible with Windows unlike the
loopback file system method:
On your Linux systems, you have a /usr/local/bin/mount script that you
manually invoke that mounts the /dev/sd? device to /mnt/cf0. It then looks
for /mnt/cf0/encrypted_archive.tar.gz and executes gnupg with your private
key from your home directory and decompresses the archive to some place
in /tmp or /home/~. You have another /usr/local/bin/umount script that
reverses all of those steps: wrap up the changes in the directory, encrypt
_against_your_public key_ on the device, unmount.
On your Windows systems, the exact same process takes place but it's all
automatic via the autorun.inf file using MING32 compiled gnupg.exe, tar.exe
and gzip.exe on the device. If you take your device to another person's
system, you will need to explore some of the many ways that you can securely
access your private key from remote locations (perhaps even a separate, 8MB
pen drive to store your private key -- they make watches that do that that
have USB connectors). That way, if you lose the device, the person would need
both the private key and the password to access the data.
Regarding the existing software on the device, there's no danger in losing any
of it unless you want the Windows-only, weak encryption to work with Windows.
This all sounds rather complicated but in practice, good encryption is hard
work and the cross-platform nature makes it even more complicated. Good
encryption is not yet a commodity.
More information about the Kclug
mailing list