Key chain-sized storage devices are
becoming increasingly popular, for both individual and business uses such as backing up data and storing sales presentations. I’ve been able to test and use the
Allwell Palm Key flash drive, a nice key chain storage device with a
reasonable price tag. Below, I describe ways to configure and
use the Palm Key storage device.
Requirements: For the basics of this document, all you will need
is an Allwell Palm Key (or some other similar device) and a working
Linux 2.4.x system (I’m using 2.4.18) on which you have root permissions. Most of the
steps in this document must be done as root. For encryption, you will
also need loobpack filesystem support in your kernel, and it is
recommended that you use the Cryptographic API for Linux as well.
If all you want to do is mount a Palm Key and use it as a DOS
filesystem, the first section, “the short instructions,” is all
you need. The second section thoroughly describes the process of setting up
the Palm Key. It is useful for those wishing to learn more about the
Palm Key. It is also useful for getting other devices like
the Palm Key working. The final section deals with creating an encrypted
filesystem on a Palm Key. Though it is more complicated than simply
using the Palm Key out of the box, it is a good way to make your data
safe, and setting it up is fun.
The short instructions
On newer kernels (2.4.18+) with
USB support, the USB drivers will automatically detect a Palm Key. Assuming the device is the first SCSI
storage device, getting the Palm Key online is as simple as this:
mkdir /mnt/pk mount -t msdos /dev/sda1 /mnt/pk cd /mnt/pk
Because the Palm Key comes with a DOS
filesystem, mounting it will permit reading and writing of files in DOS
format.
The longer version
This section goes through setting up the Palm Key step-by-step. If you
are having problems getting your Palm Key working, or have a
key chain storage device like the Palm Key, these steps should be enough
to at least help you isolate any problems.
Preparing USB
Before plugging in the Palm Key, you should make sure your system has
the USB kernel modules inserted (or built in, if you don’t want them to
run as modules). Specifically, we need the usb-uhci (or usb-ohci) and
usb-storage modules loaded. use “lsmod” to see if they are there. If not,
use modprobe:
modprobe usb-uhci usb-storage
Note: the usb-uhci is a driver for one type of USB bridge. If it doesn’t
work, you probably have an OHCI bridge, in which case you should modprobe usb-ohci.
Running “lsmod” now should show the usbcore, usb-ohci or uhci driver, and the
usb-storage driver, among others.
Plugging in the device
Once the modules are loaded, you can plug in the device. Wait a few seconds, and
then change directories to /proc/bus/usb.
/proc/bus/usb is home to information about USB devices. The directory should have a file
for devices, a file for drivers, and a directory for the root USB hub.
$ ls -l total 0 dr-xr-xr-x 1 root root 0 Mar 25 11:09 001 -r--r--r-- 1 root root 0 Mar 25 16:01 devices -r--r--r-- 1 root root 0 Mar 25 16:01 drivers
The drivers file contains a list of available USB drivers. It should have an entry for
usb-storage, the module we inserted above. The more important file, though, is the
devices file. It lists all of the USB devices connected to the system (the program “usbview”
takes this information and formats it in a way that is easier to read). It should
contain an entry for our Palm Key. My devices file is below. It has two entries — one
for the root hub, and one for the Palm Key. The second line beginning with a “T:” marks
the beginning of the information about my Palm Key.
# cat devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=ff80 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0c76 ProdID=0003 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
Most devices contain some text information about themselves. If present,
it is displayed on lines beginning with “S:”.
Some versions of the Palm Key, though, do not contain any text identifiers.
However, all USB devices are required to have version info, which is on the line
beginning with “P:”. Yours should look somewhat similar to mine, where the
vendor code identifies the vendor, the prodID identifies the product, and the
rev indicates the version of the product.
P: Vendor=0c76 ProdID=0003 Rev= 1.00
As long as you see an entry for the Palm Key in this file, we are ready to go on.
If there is no entry, check the physical connections, and make sure that the
right modules are loaded in the kernel.
The mass storage driver
The job of the mass storage USB driver (usb-storage) is to map USB mass storage
devices to SCSI device handles. This allows the USB device to be treated like a large
removable storage device.
If things went well above, then the Palm Key should have been assigned to a
SCSI device. In /proc/scsi, you should see a directory named something like
“usb-storage-0.” (The number at the end will be different if you have other USB
mass storage devices.) The file /proc/scsi/scsi contains details on what devices
are registered as SCSI devices. Mine looks like this:
Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: GENERIC Model: USB Mass Storage Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02
Because I don’t have any other SCSI devices, the only entry in this file is for
my Palm Key. Note that in the absence of vendor identification from the device itself
(and subsequently from the /proc/bus/usb/devices file), the device
is just tagged as a generic USB mass storage device. The first line, “host,”
provides information on the location of the device. It is the first SCSI device,
which will be mapped to /dev/sda.
I am using DevFS, so looking in /dev, I see entries for /sda and /sda1. /dev/sda1
contains the filesystem for the Palm key. Note: Many USB mass storage
devices use the fourth partition (which would have been /dev/sda4 in our case) for
the filesystem. This is done because old Mac systems always used the forth partition
for data. It appears the Palm Key was not designed to be used with old Macs.
If you are not using DevFS and have a lot of entries for /dev/sda, you can
run ‘file -s sda*’ to see which partition(s) contain filesystems.
Mounting the device
At this point, we have identified which SCSI device the Palm Key is mapped to. As a
SCSI device, it should act exactly the same as any other hard drive, and mounting
is no exception.
$ mkdir /mnt/pk $ mount -t msdos /dev/sda1 /mnt/pk
At this point, you should be able to cd /mnt/pk and write to the Palm Key. When
a write occurs, the red light on the device should flash. Since data may be buffered
before a write, don’t panic if it doesn’t flash each time you write.
Remember to unmount the filesystem before you unplug the device. You may make an
entry in /etc/fstab to make this easier. Mine looks like this:
/dev/sda1 /mnt/pk msdos user,noauto 0 0
With an entry in fstab, mounting and unmounting is a little easier. The “user”
flag allows a non-root user to mount and unmount the Palm Key, too.
$ mount /mnt/pk #mounts the device $ umount /mnt/pk #unmounts the device
Replacing the DOS filesystem
If you are not concerned about sharing the data on the Palm Key with a
DOS-capable box, then it is nice to put a Linux filesystem on the Palm
Key. Because ReiserFS is supposedly good at dealing with small files, it
might be a good choice for use on the Palm Key if you want a journaled
filesystem. However, I’m just going to put a plain old ext2fs on mine.
Really, there is no reason why you shouldn’t be able to put any
Linux-supported filesystem on the Palm Key.
Remember, before you write a new filesystem,
you need to unmount the Palm Key.
$ umount /dev/sda1 $ mke2fs /dev/sda1
Putting an encrypted filesystem on the Palm Key
The advantage of a Palm Key is that it
allows you to keep personal data close at hand. However, the data
that I keep on my Palm Key, being personal, is not data that I want
someone else to be able to access should I lose it. For that reason,
I replaced the standard filesystem on the device with an encrypted
filesystem. Though this can be done to some extent with the standard
loopback drivers, I found that the International Crypto API provided
more secure (and more flexible) ways of storing my data.
Patching the kernel and Util-Linux
The first step, and probably the hardest, is taking the Crypto API
patches (available in the kernel mirror or at http://cryptoapi.sourceforge.net)
and applying them to the 2.4.18 kernel, and then doing the same for the util-linux
patches. All of these steps are well documented, though, and I won’t cover them
again. If you are using a well-known distribution, it is possible that
the patched kernel and util-linux packages are available in binary form. If you can
find a trusted source distributing binaries, you can install those and skip this
section.
Once patched, I went through kernel configuration, selecting most of the crypto-api
options under “cryptographic options” to be built as modules (generic loop filter is a
must, and I selected all the ciphers that were not deprecated).
I also selected “loopback device support” under “block devices,” making it a
module as well. After configuring the kernel, I rebuilt it and installed it. (If you
have never compiled a kernel before, read the documentation on it in the source code,
usually in /usr/src/linux-[version]/README. Compiling is not hard, and gives you
a lot more power over how you configure your system.)
Once the kernel was installed, I compiled the patched util-linux package (available at
the same place as the crypto-api). Under Gentoo Linux, this was very easy, but I would
imagine that under distributions like Red Hat, you might have to find the right source RPMs and do a little tinkering. On the other hand, if you are using a large distro, you might be able to find prebuilt binaries. 😉
Setting up an encrypted loopback filesystem
Okay, if you made it this far (and your system still boots), you have made it through
the worst. Following the steps highlighted in the last section, you should be able to
modprobe the necessary USB kernel modules and then plug the Palm Key in again. If you have any
data on the Palm Key already, I advise moving it somewhere else, because we are going to wipe out the filesystem.
We want to create a loopback filesystem on the device. Rather than create a
filesystem and then a large file into which we put the loopback filesystem, we’ll just write
the file directly onto the device. First things first, though — load the modules for
cryptographic loopback filesystems. I am going to use Serpent, but feel free to use
whatever cipher you want. Note that if you are not using the crypto API, you can
still set up an encrypted filesystem, but your only cipher choices are “none,” “des,” and
“xor,” none of which are very strong. Also, if you are not using the crypto API, you will
modprobe loop, not cryptoloop.
modprobe cryptoloop cipher-serpent
That should load all of the necessary modules, including loop.o. Now we need to setup
the loopback filesystem. Before you setup the loopback filesystem, you should know which
cipher you are going to use and how big the key is going to be (I always go for the larger
ones because I prefer strength to speed). You should also have a good long password in mind,
because you will only get one chance to enter it.
$ losetup -e serpent /dev/loop0 /dev/sda1 Available keysizes (bits): 128 192 256 Keysize: 256 Password : $
Now you have a loop device set up with encryption. The next step is to create a
filesystem on it. I’m just going to create an ext2 filesystem. I am not sure if there
are any complications to journaled filesystems on encrypted filesystems, but feel free
to try and email me with the results.
mke2fs /dev/loop0
All that is left now is mounting the filesystem.
$ mkdir /mnt/crypt $ mount /dev/loop0 /mnt/crypt $ cd /mnt/crypt $ touch test $ ls lost+found test
Turning a loopback filesystem off
Loop devices take a few more steps to shut them down without compromising security or
corrupting the filesystem. Make sure you do these steps when you are done with the Palm
Key.
$ cd #if you are in /mnt/crypt, you can't unmount it! $ umount /dev/loop0 $ losetup -d /dev/loop0
The last step, “losetup -d /dev/loop0,” deactivates the loop device, ensuring that someone
can’t come along later and remount the filesystem without entering a password.
The next time you want to use the Palm Key loopback filesystem, start it up like this:
$ modprobe cryptoloop cipher-serpent $ losetup -e serpent /dev/loop0 /dev/sda1 $ mount /dev/loop0 /mnt/crypt
And that is it — you now have a loopback encrypted filesystem on your Palm Key. The following section
has a useful script for making remounting and unmounting the loopback filesystem a little bit easier.
Sample automation scripts
Mounting an encrypted loopback device can get a little tedious, not to mention error prone. This
script simplifies it a little. Note that the script is pretty basic — no fancy features yet. It will also require a little bit of modification — you will have to set the CIPHER variables to match
your choices.
#!/bin/bash ########################################################### # Shell script to mount and unmount loopback on Palm Key. # # Author: Matt Butcher# ########################################################### CIPHER=serpent # Set this to the desired cipher CIPHER_MODULE=cipher-serpent # In most cases, this is 'cipher-$CIPHER' CIPHER_KEYSIZE=256 # Size of key, depends on the size CIPHER supports MOUNT_DIR=/mnt/crypt # If you want to mount the PK somewhere else... USAGE="Usage: $0 start|stop|status" case $1 in start) # To start: add modules, setup loop device, mount loop # Note: you will be prompted for password. modprobe cryptoloop $CIPHER_MODULE # If you remove "-k $CIPHER_KEYSIZE" you will be # prompted to enter the keysize. losetup -e $CIPHER -k $CIPHER_KEYSIZE /dev/loop0 /dev/sda1 mount -t ext2 /dev/loop0 $MOUNT_DIR ;; status) # Just tell if the fs is mounted and if the loop device # is working. echo Mount: `mount | grep loop0` echo Loop: `losetup /dev/loop0` ;; stop) # unmount loop, remove loop, rmmod modules. # modules are not the _only_ mods that might # be inserted. umount /dev/loop0 losetup -d /dev/loop0 rmmod cryptoloop $CIPHER_MODULE ;; *) echo $USAGE ;; esac
Using the script is pretty simple. It should work like this:
$ ./pk-ctl.sh start Password : $ ./pk-ctl.sh status Mount: /dev/loop0 on /mnt/crypt type ext2 (rw) Loop: /dev/loop0: [0008]:927 (serpent-cbc) offset 0, undefined encryption $ ./pk-ctl.sh stop
This should give you a good start for using key chain storage devices with Linux. Good luck.
