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.
For more information about Allwell Palm Key . |
