PPDD How-to Introduction Ppdd lets you use encrypted files systems under Linux. It uses high quality encryption techniques suitable for the large volumes and the long lifetimes of data involved. It is easy to install and use and with just a little care on the users part is very difficult to misuse. Protection is at a "whole machine" level; as soon as root activates the driver then the whole file system becomes usable by all users subject only to the usual Linux file access permissions. This makes it ideal for stand-alone machines or as a component of enhanced security on genuine multi-user systems. Not surprisingly performanceis slower than an unencrypted file system but on a 100MHz Pentium with 32Mb main memory using IDE discs it reduces disc throughput by about 50%; this shouldbe considered acceptable for software cryptography. Please read the whole of this document. The security of the data you are trying to protect is much more at risk from "human error" than it is from a failure in the cryptography or the programming. Requirements You need a recent Linux, including kernel sources plus a recent gcc and glibc revision (I never did get to find the minimum revs, but any later than 1997 should be OK - my gcc is 2.7.2.3). My installation was based on Red Hat 5.0. If you have compilation problems you may well want to install a recent version of Red Hat. RH 5.1 works too. (As an aside: if you are so concerned about your privacy that you want an encrypted file system then you should be equally concerned what you run on your machine. A pristine installation from a trusted source is a good starting point - validate the pgp signatures too.) If you want your encrypted file system(s) to use whole partitions (e.g /dev/hda3 as /home) then you should plan this into your installation from the start. See later. Source As of February 1999 the source is at "http://linux01.gwdg.de/~alatham" the old url will become obsolete soon. Direct access to the source can be had from "ftp://ftp.gwdg.de/pub/linux/misc/ppdd". Go to the directory where you keep your sources and "tar -xzf file" the source tgz file. This will create a directory ppdd-n.m (n.m is the version number). Go into this directory. You will find the kernel patch files in "patches". They are named simple by the Linux version they are made for. If there is a patch for your version of the kernel then you're in luck. If not then see below for ways out of this! Check the makefile The file "Makefile.config" contains user changeable variables. Most of the defaults are usually OK but you may want to change the Linux version. Kernel patches You should install the kernel source in /usr/src in the normal way. You should then configure the kernel for your computer (make menuconfig) and compile and install it. Please see the appropriate "How-to". You should also setup lilo or whatever you use to boot to allow you to access at least 3 versions of the kernel: the one that came with the installation, the one you just compiled and the one with ppdd that we're going to make next. Again please read the appropriate "How-to" if you are not sure about using lilo. Make sure that the unpatched kernel you have just compiled does in fact work! Go to the ppdd source directory and do "make trial_patch". If this is clean do "make apply_patch". If there is no patch available for your Linux rev you have some choices - you can obtain a Linux rev for which a patch is available or you can select the "nearest available patch" from the patches directory. To select a different patch simply make a copy of it in the patches directory - naming it after the revision you want to patch. Go into directory /usr/src/linux and run memuconfig. In the "Floppy and other block devices" sub-menu select ppdd to be part of the kernel (not a module at this stage). Save the configuration file, "make dep", "make clean", "make bzImage" etc as you did for the unpatched kernel. (Don't forget "make modules" and "make modules_install" - you will need "make modules" if ANY part of the kernel has been selected with an "M" even though ppdd is part of the fixed kernel). (ppdd can be compiled as a module later if that's what you want). Make sure you configure and run lilo. Reboot the machine and select the newly compiled and patched kernel. Check that you see the message as ppdd installs itself at major device 63. Do a "make check_linux" from the ppdd source directory - it should tell you that ppdd is in the running kernel. Source compilation Do not attempt to compile the sources until you have patched and compiled the kernel and are running on it. In particular /usr/src/linux must contain the ppdd kernel source. Logon as root and go to the ppdd source directory and compile the utility programs with the command "make". Make the devices with "make devices". Install the programs "make install". Initial testing Logon as root. Go to the source directory. Do "make test" and watch that each step is OK. If all this works then you can be confident that you have installed ppdd correctly. Live installation You need to plan your disk partitions before you install Linux. Normally you will have a partition for root, one for /usr and one for /home. You may well want to reserve a partition for /crypt or you could encrypt the entire /home partition. I will assume: /dev/hda1 is root /dev/hda2 is swap /dev/hda3 is usr /dev/hda4 is home /dev/hdc1 is crypt In the boot and init sequence you will not be able to mount /crypt until root enters the pass phrase. An automatic "up" cannot mount /crypt (unless you put the pass phrase in the script - and if you do that you can save yourself all the trouble by not using an encrypted file system at all!) Make sure that /etc/fstab does not auto mount /crypt. You can put the entry in /etc/fstab relating /crypt to /dev/ppdd0 but it must not be auto mount. Live installation - Method one Create the encrytped files system: ppddinit /dev/ppdd0 /dev/hdc1 Note that you will need to enter key strokes to generate enough "randomness" for the keys. It's boring but you only do it once. Be very careful that you have specified the correct real device e.g. hdc1. If you put the wrong device in here you will destroy the data on that device. If you are really paranoid you can write random initial data to the device by using -r on the ppddinit command - if you do it then you will need a little patience too. I now advise you to do this for any serious use of ppdd whether you are paranoid or not. Setup the device: ppddsetup -s /dev/ppdd0 /dev/hdc1 Make the ext2 file system: mkfs /dev/ppdd0 Mount it: mount /dev/ppdd0 /crypt You can now start loading data into it. When you have finished: umount /crypt ppddsetup -d /dev/ppdd0 Live installation - Method two Create an ext2 file system on the raw device: mkfs /dev/hdc1 Mount it and load your data into it, then umount it. (You may already have done these two steps at sometime in the past - that is the reason for having "method two" i.e. to turn an existing partition into an encrypted one). Create the encrytped files system: ppddinit -x /dev/ppdd0 /dev/hdc1 Again you will need to enter keystrokes. Please note that the encryption process is not interruptible. If you break it or if the power goes off you will need to restore the whole partition from a backup. When the encryption is finished you can run "ppddsetup -s" and mount it using /dev/ppdd0 instead of /dev/hdc1. Do not encrypt the root partition (see later) or the partition containing the ppdd utilities (they should be in /bin or /sbin because they are needed before /usr is mounted). As of rev 0.8 there is an alternative to using ppddinit. You can use ppdncrypt instead - it does not require kernel support. To encrypt a filesystem as above you can do: ppdncrypt -o /dev/hdc1 Live installation - Swap Swap files are a particular problem as far as the use of encrypted data is concerned. They contain images of main memory and that means plaintext! There are two solutions. Don't use swap at all! Or swap to a file on an encrypted file system. You should try to ensure that you have enough main memory so that swapping is not necessary. If you ever do get into serious swapping to an encrypted file system then you can expect a severe drop in performance and there is every possibility that the system will crash. (System needs memory - so swaps pages to disc - sends these to ppdd which itself needs buffers in main memory!). Just buy some extra RAM. Live installation - Module You can compile ppdd into the fixed kernel or as a module. If it is a module you will need to install it with a command e.g.: insmod /lib/modules/2.0.33/block/ppdd.o Alternatively you can "autoload" it as required by editing /etc/conf.modules and adding the line: alias block-major-63 ppdd Live installation - Boot, init and shutdown At some point in the boot process root must intervene to enter the pass phrase. Assuming that you have just a single file system (e.g./crypt) then the easiest way is to logon as root after the normal boot sequence and then: ppddsetup -s /dev/ppdd0 /dev/hdc1 mount /dev/ppdd0 /crypt The /crypt file system is then available for use. Ideally before running shutdown you should umount the file system and disconnect the driver with "ppddsetup -d /dev/ppdd0" but this is not essential as the shutdown script will umount it anyway and the disconnect is there only for added security. If you have encrypted everything except the root file system then you may well want to run ppddsetup from within the rc.d/init.d scripts depending on run level. Live running - Tuning memory You need to look at tuning the values of /proc/sys/vm/freepages. If these are too low (especially the last one of these) then you can get very jerky response. Main memory fills with dirty buffers which are only sent to ppdd for encryption (and writing to disc) when memory is needed; then ppdd has a lot of work to do while you wait for the screen to echo your keystrokes! Intensive activity on the encrypted file systems will result in some hesitation but this is usually tollerable in comparison to long pauses with no response. It's rather like working over a network! Be aware that each device you activate with "ppddsetup -s" needs about 150K of memory (kernel buffers). This is released with "ppddsetup -d". Live running - Caution The encrypted file system is much more likely to suffer serious damage if buffers are not written to the disc than is a normal file system. If at all possible use a UPS (or laptop!) and make backups. Live running - Pass phrase management When you created the encrypted file system the pass phrase you entered was the "master" pass phrase. At the first opportunity you should create a "working" pass phrase: ppddpassw /dev/ppdd0 /dev/hdc1 As far as all access operations are concerned both of these pass phrases are equally valid. You should always use the "working" pass phrase. The reason for this is to avoid compromising the master pass phrase. The less often you type this in then the less likely is it that someone will discover it using "spying" technologies - hidden cameras, rf scanners etc etc. You should change the working pass phrase at irregular intervals and as soon as possible if you believe it may have been compromised. To change the working pass phrase you can enter the existing working pass phrase to access the change function - you do not need to enter the master pass phrase. Before making a backup you should erase the working pass phrase: ppddpassw -e /dev/ppdd0 /dev/hdc1 Again you should enter the current working pass phrase to gain access. You can then backup the entire partition. After the backup is complete and verified you should set a new working pass phrase (or set it back to as it was before the backup if you so wish): ppddpassw /dev/ppdd0 /dev/hdc1 You will need the master pass phrase (because the working pass has been erased) to access the change function. Why all this circus with erasing the working pass phrase before backing up? The reason is that you should assume that at some point in the future an attacker will somehow get hold of one or more backup tapes. The only pass phrase which can decrypt these is the master. He must break this one pass phrase to get at the data (assuming this is how he chooses to attack it). If he had several backups all with different pass phrases he needs to break only the weakest of these to access all the data (including that encrypted with other pass phrases). The chances are high that over the course of time one of your working pass phrases will be compromised or that you will choose a phrase that your attacker has in his dictionary of "common" pass phrases. It goes without saying that your master pass phrase must be good. Good means long and complicated enough so that it is unlikely to be in an attacker's dictionary - you also need to be able to remember it! A full sentence from a poem or a song but with a mistake or two is probably a good bet, sprinkle a few special characters into it and you are probably safe. Verbatim quotes from well know texts are definitely unsafe. Attackers have foreign dictionaries too. Another approach is to use five or more words of five or more letters which are totally unrelated (e.g fishes twelve driver morning grown). In order to increase the complexity of the pass phrase this system requires the user to enter two strings - don't confuse this with the "master" and "working" pass phrases. Each of the strings should comply with the rules above. The reason for this is that research indicates that users can more reliably enter the pass phrases as two relatively short strings rather than as one long one. Your choice of master pass phrase and how you use it are the main factors influencing the security of the whole system. You have been warned! Live running - Backups (see also de/encryption without kernel support) Read the section on pass phrase management. Read it again until you understand that backing up the file system with a valid working pass phrase is very very danegerous. Before starting a backup you need to umount the file system and release the device: umount /dev/ppdd0 ppddsetup -d /dev/ppdd0 Erase the working pass phrase: ppddpassw -e /dev/ppdd0 /dev/hdc1 Backup the entire partition e.g: dd if=/dev/hdc1 of=/dev/ftape bs=1k Always verify (check read and compare) the backup. Before you use the file system again you should set the working pass phrase. (see key phrase management). If you are using a file (rather than a disc partion) then this will be backed up in the normal way when you backup the filesystem containing that file. Do remember to erase the working passphrase. Live running - Backups (paranoid) (NB not fully implemented yet - do not use this yet (rev 0.5)) You can make backups so that they are useless to an attacker even if he ever discovers the master pass phrase. The problem is that they are also useless to you unless you carefully manage the backup and recover process. When you create an encrypted file system you can ask for a backup of the control block to be written to a file (not on the encrypted system itself). This file is 1024 bytes long and in fact is a copy of the first 1024 bytes of the encrypted file system. You can keep it on one or more floppies and put them in secure storage. You will need one of these too during the backup process. Before the backup you destroy all the encryption keys on the file system: ppddpassw -z /dev/ppdd0 /dev/hdc1 Backup and verify as usual. Now to enable the encrypted file system you need to restore the control block from the floppy: dd if=control_block_on_floppy of=/dev/hdc1 bs=1024 count=1 conv=notrunc You should then set up a working pass phrase (using the original master pass phrase) as described above. If this procedure is not too much trouble then it does give you a little extra security. To be effective however you need to ensure that the attacker never gains access to the working floppy or the secure copies. Similarly if he ever makes his own copy of the first 1024 bytes of the encrypted data you have lost the advantage of this scheme. A corollary is that if you keep all the floppies under your personal control then you can destroy all access to the data and all the backups by destroying the floppies and destroying the encryption keys as above. Live running - Reversion If you decide that you no longer want an encrypted file system then you have two choices. You can backup the data (via the mounted file system) in cleartext form, create a new ext2 file system on the real device and then load the data back. You can also decrypt in place; this process is not interruptible - if you break it or if the power goes off you will need to restore the whole partition from a backup. ppddpassw -d /dev/ppdd0 /dev/hdc1 You can also use ppdecrypt - which does not require kernel support. ppdecrypt -o /dev/hdc1 Read-only media As of Rev 0.5 ppdd supports read-only media. Clearly to create an encrypted filesytem you must be able to write to it. However if you copy the filesystem to read-only media e.g. cdrom it should be possible to mount it read-only via ppdd. This support is transparent - no special procedures are needed for ppdd, but you must mount the /dev/ppddx read-only. Encryption and decryption without kernel support As of Rev 0.8 it is possible to encrypt a file used as a backing file for a loop device and then use it as a backing file to ppdd. No kernel support is required (until you want to actually use it with ppdd). ppdncrypt input-file output-file Similarly you can decrypt a ppdd backing file and it will be acceptable as a backing file for loop. ppdecrypt input-file output-file Clearly these two utilities could be used for conventional encryption of a file - but remember that the first 1024 bytes will be destroyed. If you don't want to loose the first 1024 bytes the use the -c switch in both the encryption and decryption phases. You can also use this as a neat way of making backups. However you must ensure that you have a secure backup of the first 1024 bytes of the backing file (or device). Keep this on at least two floppies and store these very securely. You must also make sure that the device is not in use - umount it and run ppddsetup -d on it. dd if=encrypted_file_or_device of=keep_this_safe bs=1k count=1 e.g. dd if=/dev/hda1 of=/floppy/secure.hda1 bs=1k count=1 To make a backup do (using this example): ppdncrypt -w /dev/hda1 /backup/bu.hda1 Don't choose the same passphrase you use normally with this device. /backup is a normal filesystem and bu.hda1 is a file. To restore the backup: ppdecrypt /backup/bu.hda1 /dev/hda1 You will need the passphrase from the ppdncrypt step. dd of=/dev/hda1 if=/floppy/secure.hda1 bs=1k count=1 conv=notrunc A big advantage of this is that if an attacker gets hold of any of the backups they contain no control information or keys in the first 1024 bytes. They have also been encrypted with random keys. This means that even if he has all your backups he cannot even work out which parts of the disc have changed over the course of time. Recovery of the plaintext is even more difficult. Further tricks with these two utilities are possible Conventional file en/decryption for example: ppdncrypt -c plaintextfile cyphertextfile will create an encrypted version of the original file. The size is 1024 bytes larger due to the key data. Pass phrase entry is the same as ppdd itself. The -w switch is also available. ppdecrypt -c cyphertextfile plaintextfile is the reverse. Pgp support ppdncrypt and ppdecrypt also provide an interface to pgp. You must install pgp in the normal way first. The security of anything you encrypt with the combined system is only as good as the weakest link. If pgp turns out to be flawed then a combined ppdd/pgp encryption will also be useless. To encrypt a file: ppdncrypt -pc plaintextfile cyphertextfile The system expects to find a public key for "backup" on the public keyring. To decrypt a file: ppdecrypt -pc cyphertextfile plaintextfile The system expects to find the private key for "backup" on the private keyring. You will also have to enter the pass phrase for that key. This is many times faster than using pgp alone. If you are using it to backup a ppdd filesystem (and you already have the 1024 byte control block somewhere under lock and key) then you can omit the -c from the commands. ppdncrypt -p plaintextfile cyphertextfile ppdecrypt -p cyphertextfile plaintextfile This is an easy way to do backups. Even if pgp is flawed it just means that your backups are revealed which although undesirable is not a disaster as the underlying data is encrypted with ppdd. e.g. ppdncrypt -p /dev/hdc1 /backup/hdc1.pgp However - please make sure the ppdd device corresponding to hdc1 is umounted and that you have run ppddsetup -d on it - otherwise data in memory will not have been flushed to disc and your backup will be useless. Data Integrity and ppdd There are some built in data integrity features in ppdd. They are designed to detect if someone has manipulated your data. In most cases that would result in meaningless data being decrypted. This is clearly not desirable. An attacker may try to put a block on your disc which he has obtained from a backup. Even though he can't decrypt it he may be able to find out more by watching your reaction to it. If he places the old block correctly it will probably decrypt to something meaningful. The integrity of backups is assured by having ppdncrypt write an md5 hash of both the plaintext and the ciphertext in the control block. To prevent a known plaintext attack the ciphertext hash is XORed with the plaintext hash. (An attacker can regenerate the ciphertext hash without knowing any keys). The decryption program ppdecrypt checks these hashes and reports any problems. There is a program ppddcsum which will check an existing file. In the case of a ppdd device (whether on a file or device) the situation is more complex. Perhaps it is better to illustrate how a reasonable degree of intergrity can be maintained. The file/device must be in an idle state (i.e after "ppddsetup -d"). ppddcsum -g /dev/hda1 (assuming /dev/hda1 contains a ppdd filesystem). this will ask you for the pass phrase and will then scan the device and write the ciphertext hash in the control block. ppddcsum /dev/hda1 will check it. ppddcsum -gp /dev/hda1 will generate the plaintext hash too - this is a much slower process. ppddcsum -p /dev/hda1 will check the plaintext hash as well as the ciphertext hash - again this is a slow process. Generally speaking the ciphertext hash is enough. So a workable procedure would be to check the ciphertext hash immediately before doing a "ppddsetup -s". At the end of a session of using the encrypted filesystem you would run "ppddcsum -g" to generate a new hash. One point to note is that if you use ppdecrypt to decrypt a real ppdd filesystem it may well report checksum errors if you did not generate a hash on it. Troubleshooting If you have had any problems please tell me so I can document them here. Encrypted root file system - Available as of ppdd rev 0.5 Before you consider doing this please make sure that you are happy with the way ppdd works. You should be familiar with all the routine operations before setting up an encrypted root file system. The advantage of having everything stored on disc encrypted are obvious - there is no chance to accidently leave unwanted plaintext for an enemy to find. The disadvantages are that the setup and installation are more complex and there is a small performance hit. The theory During the boot process the system must have access to an unencrypted filesystem until the point where the user enters the passphrase for the root filesystem. This means that a boot record, a bootstrap loader, a kernel and a temporary filesystem must be available in unencrypted form. You therefore need a disc partition which contains these items. In reality for convenience you will arrange that you can boot this partition directly and you will therefore need a fairly complete minimal Linux installation on this partition. By doing so you will find that kernel maintenance is far easier. The only time you will run using the unencrypted partition is for example to uprev the kernel or even ppdd itself. This is very low risk and there should be no need to use an encrypted filesystem just for this type of work. The boot process goes like this: 1. The bios reads a master boot record which loads lilo. 2. Lilo allows you to select your kernel. 3. You choose the encrypted root filesystem version. 4. Lilo loads an initial ram disc into memory - this contains a temporary filesystem. 5. Lilo loads the kernel. 6. The kernel starts running and at some point passes control to linuxrc on the temporary filesystem. 7. Linuxrc behaves rather like "ppddsetup -s" and asks the user for the root filesystem pass phrase. 8. If the pass phrase is good, linuxrc patches the running kernel in memory to tell it to continue the boot process after switching the root filesystem to the encrypted one. 9. Linux continues with init on the encrypted root filesystem. 10. The first instruction in /etc/rc.d/rc.sysinit is ppddreopen. This will effectively close the real device on the ram disc which is still mounted as /initrd and open it on the encrypted root disc. It then umounts /initrd and frees the ram disk buffers. 11. During the running of /etc/rc.d/rc.sysinit (part of the normal init), ppddsetup will try to setup any ppdd device it knows the pass phrases for. These are contained in /etc/ppddtab on the encrypted root filesystem. 12. If an encrypted swap file system has been defined this is activated. 13. Gettys are started and the user has the normal login prompt. Planning You will need to give some thought to how you are going to partition your discs. As disc space is not as expensive as it once was this should not be a problem! Allow one partition for the unencrypted root + usr; about 500Mb should be more than enough to load evrything you need for general Linux maintenance work. Allow about 100Mb for the encrypted root and about 800Mb for the encrypted /usr. You will usually arrange the rest of your disc space so that you have an encrypted /home partition of suitable size. You may want to keep space on a physically seperate disc for backups of the encrypted partitions. It's entirely up to you, but do plan it in advance and write down a partion plan. For example purposes I will assume: /dev/hda1 unencrypted root+usr /dev/hda2 encrypted root /dev/hda3 encrypted usr /dev/hda4 swap /dev/hdc1 encrypted home /dev/hdc2 encrypted swap Install Linux into /dev/hda1 from a reliable distribution. Define all the partions all ext2 except for /dev/hda4 which must be a conventional swap file. Load the source for the kernel. Patch it to the latest level. Configure it and compile it. Install ppdd as above and test it thoroughly. Allow for 3 kernels in the lilo; the issued kernel which came with the distribution, the normal ppdd kernel and the root encryption version. N.B.1 At this stage please use a monolithic kernel i.e. no modules. It is possible to switch to using modules at a later stage but it safer to avoid this added complexity just now. N.B.2 You MUST select ram disc as a fixed part of the kernel and you MUST enable initial ram disc support. Prepare /dev/hdc1 and /dev/hdc2 as encrypted file systems; run ppddinit and mkfs. Do this thoroughly i.e writing random data and strongly random keys. Now mount the encrypted /dev/hdc2 and create a swap file: ppddinit -r /dev/ppdd7 /dev/hdc2 ppddsetup -s /dev/ppdd7 /dev/hdc2 mkfs /dev/ppdd7 mount /dev/ppdd7 /mnt cd /mnt dd if=/dev/zero of=file bs=1k mkswap file cd / umount /mnt Make a mount point for the initial ram disk. mkdir /initrd Now install Linux again onto /dev/hda2 and /dev/hda3. Load the whole range of software you want. Take care not to overwrite any partitions other than these two plus the conventional swap (/dev/hda4). If the install asks about mounting any other partitions do not attempt to mount any other partions. Do not let this install change anything to do with the boot process. If it asks about installing lilo - say no. You should now be able to reboot your machine and run the original Linux from /dev/hda1. Edit the lilo.conf so that you can choose: 1. The original issued kernel with /dev/hda1 as root. 2. The compiled kernel with /dev/hda1 as root. 3. The compiled kernel with /dev/hda2 as root. Run lilo and reboot. Choose option 3. You should now have /dev/hda2 as root and /dev/hda3 as /usr. Nothing as yet is encrypted. Mount the original root+usr (/dev/hda1) on /mnt. Copy the entire linux source tree from hda1 to hda2. e.g. cd /mnt/usr/src tar -cf /usr/tmp.tar linux cd /usr/src tar -xf /usr/tmp.tar rm -f /usr/tmp.tar A more efficient way of doing this is to pipe the output of the one tar command into the next one e.g. ( cd /mnt/usr/src ; tar -cf - linux ) | ( cd /usr/src ; tar -xf - ) Make the devices and the initrd file: cd /mnt/-directory-containing-ppdd-sources edit Makefile.config to make /dev/hda2 the real root device make install make devices make initrd Make the mount points: cd / mkdir home mkdir swap mkdir initrd Edit /etc/rc.d/rc.sysinit (some distributions use a different script) e.g. compare the example with your version. You will need to stop your init process turning on swap until after the filesystem (/swap) has been mounted. It will then need to swap to a file and not a partition. You will need to run ppddsetup -a to enable all the other ppdd disc partions you want mounting. Edit /etc/fstab by adding the lines /dev/ppdd7 /swap ext2 defaults 1 2 /dev/ppdd1 /usr ext2 defaults 1 2 /dev/ppdd2 /home ext2 defaults 1 2 and removing any existing lines related to swap or usr. Create /etc/ppddtab containing /dev/ppdd1 /dev/hda3 "first pass phrase" "second pass phrase" /dev/ppdd2 /dev/hdc1 "first pass phrase" "second pass phrase" /dev/ppdd7 /dev/hdc2 "first pass phrase" "second pass phrase" (Replace the pass phrases as appropriate) Note this is not a security risk. Very soon we will encrypt /dev/hda2 and these pass phrases will not be visible until the root filesystem passphrase is entered. Double check all the above - it's easier to mend now rather than later. Reboot and choose option 2. Run ppddinit -x /dev/ppdd0 /dev/hda2 Run ppddinit -x /dev/ppdd1 /dev/hda3 Edit /etc/lilo.conf by adding the initrd line to option 3 - also change the root disc to /dev/hda1 (Yes /dev/hda1 - in most cases if the boot fails to go to the encrypted filesystem it will revert to the one on /dev/hda1 which may give you a chance to mend things). Run lilo and reboot. Choose option 3. Enter the root filesystem pass phrase and watch the results........ If you insist on a modular kernel then do get the monolithic version working first. You will need to copy the modules to /lib/modules/2.0.xx/.... on the encrypted root filesystem. This must be identical to what you have on the unencrypted filesystem where you compiled the kernel. Every time you compile the kernel you must not only run lilo but also copy all the modules from the unencrypted to the encrytpted system before you reboot and use the encrypted filesystem (this is a real pain and it's very easy to forget). The ppdd driver MUST NOT be a module if you are using an encrypted root filesystem. During shutdown you may see a warning about /swap being in use. This is not serious but you can fix this by turning swap off in the "halt" script located in /etc/rc.d/init.d. See the example provided. Using a bootable floppy disc. If you are really paranoid you can use a bootable floppy disc to access your system. This means that absolutely everything on the hard discs can be encrypted and checksummed. The floppy disc contains the kernel and the initial ram disc. If you keep the floppy disc under good physical security you can have a very high degree of confidence that your computer has not been tampered with - at least softwarewise. It does not protect you from a hardware data collection device hidden in your keyboard! To make a bootable floppy use the "make bootdisk" option after having adjusted Makefile.config to your requirements. Obviously you should get root filesystem encryption working smoothly before taking this last step. Bugs etc. The whole of ppdd is beta status. At this stage it would be wise not to use it for super sensitive material. There is also a residual risk that a bug will destroy all the data on the encrypted filesystem. All known bugs at the time of writing have been fixed. There is a chance that bugs have been introduced while adding the features needed for root filesystem encryption. Please report any bugs you find. Parsing and validation of command line options and the ppddtab file are probably not foolproof. Valid ppddtab files and command line options are processed correctly - I cannot yet be certain that all invalid ones are trapped and dealt with properly. Only Intel x86 architecture is supported, mainly because the encryption routine is in assembler. Early versions encountered a variety of problems with filesytems larger than 2Gb. As far as I know all residual size problems have been fixed but please take extra care with large filesystems (e.g. check with fsck each time until you are fully confident that all is well). Always create the filesystem on the ppdd device with "mke2fs -b1024" for a block size of 1024 bytes. There are problems with larger block sizes. Do not use any other filesystem other then ext2 on a ppdd device. DOS for example is known to overwrite the keys. Allan Latham Revision 0.9 - June 1999