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 2.4 series Linux, including kernel sources plus a recent
gcc and glibc revision (I never did get to find the minimum revs, my gcc is
2.95.3 from the SuSE 7.3 distribution).
My installation was based on SuSE 7.3. If you have compilation problems you 
may well want to install a recent version of your chosen Linux distribution.

(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.

You need the sources for util-linux. As of January 2002 these were at:

"ftp://ftp.kernel.org/pub/linux/utils/util-linux"

You also need the patches for these. As of January 2002 these were at:

"ftp://ftp.kernel.org/pub/linux/kernel/people/hvr/util-linux-cryptoapi"

You need the international patches for the Linux kernel. As of January 2002
these were available at:

"ftp://ftp.kernel.org/pub/linux/kernel/people/hvr/testing"

in this directory are:

patch-int-2.4.xx.y.gz     - the kernel patches for cryptography
loop-jari-2.4.xx.y.patch  - the patches for the loop device driver

For convenience the patches for 2.4.17 and util-linux-2.11n are included in
the ppdd source release. For later revs you will need to get the patches from
the original locations.

If you use ext2 labels and you want to continue doing so on ppdd you need
to get the latest e2fsprogs sources. I found mine on sourceforge.


PPDD Source

The source is at 

"http://linux01.gwdg.de/~alatham"

 and

"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. This
is where you identify where all the patches are on your computer.


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!

PPDD makes use of the new crypto api and this needs a patch applied before the
ppdd patch.

Go to the ppdd source directory and do "make trial_patch_intl".
If this is clean do "make apply_patch_intl".

The loop device driver in Linux has many problems and these must be fixed by a
patch before the ppdd patch is applied before the ppdd patch is applied

Do "make trial_patch_jari".
If this is clean do "make apply_patch_jari".

Then do "make trial_patch_ppdd".
If this is clean do "make apply_patch_ppdd".

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 menuconfig.

In the "Block devices" sub-menu select loop to be part of 
the kernel (not a module at this stage).

In the "Crypto" sub-menu select cyptoloop and 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 cryptoloop cipher-ppdd install themselves.

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".

Install the programs "make install".


Util-linux compilation

This is needed to provide "losetup" and the "mount" and "umount" commands
modified for ppdd.

Build it as standard as it was downloaded to make sure it is OK.

DO NOT INSTALL it. It contains system critical programs and could cause
you to loose all access to you computer.

Save copies of your original programs "losetup", "mount" and "umount".
In the SuSE distribution losetup is in /sbin and the others are in /bin.

Now copy those three programs from the mount directory under the util-linux
source to wherever your original versions were. You should test them and
restore your originals if there any problems. Do this before rebooting as
mount and umount are essential to the health of the system!

Go to the ppdd source directory and do "make trial_patch_util".
If this is clean do "make apply_patch_util".

Then do "make trial_patch_mount".
If this is clean do "make apply_patch_mount".

Now rebuild the util-linux programs and again just install "losetup",
"mount" and "umount" and no others.


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


NB - Important Note.

Partition sizes should be a multiple of 4096 bytes. For live production use
I strongly advise you to do this. There is a bug in Linux which can cause
problems if the size is not a multiple of 4096. It is very unlikely that you
will ever encounter the problem but to be on the safe side please stick to
this rule. When you run fdisk the size of the partitions is shown in units of
1024 bytes - so the number shown should be divisible by 4. If a plus sign
appears next to the size it indicates that there is a 512 byte sector on
top of the indicated number of 1024 byte blocks - avoid this for ppdd. If
necessary create a dummy partition that you don't use so that subsequent
partitions are OK.


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:
	ppdncrypt -i /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. For testing purposes you
can use the "-w" switch - the randomness is not quite so good but it will
suffice for testing.

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. 
You can write random initial data to the device by using "-r" on the ppdncrypt
command - if you do it then you will need a little patience too. I advise you
to do this for any serious use of ppdd.

Setup the device:
	losetup -e ppdd /dev/loop0 /dev/hdc1

Make the file system - ext2, ext3 and Reiserfs are know to work:
	mke2fs /dev/loop0

Mount it:
	mount /dev/loop0 /crypt

You can now start loading data into it.

When you have finished:
	umount /crypt
	losetup -d /dev/loop0

Note that you can mount the filesystem directly with the mount command:

	mount /dev/hdc1 /crypt -o loop,encryption=ppdd


Live installation - Method two

Create a file system on the raw device (ext2, ext3 or Reiserfs):
	mke2fs /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:
	ppdncrypt -o /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.
For testing you can add the "-w" switch to avoid having to enter keystrokes
to generate the random keys.

When the encryption is finished you can run mount it using as above. e.g.

	mount /dev/hdc1 /crypt -o loop,encryption=ppdd

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 use an encrypted device. 

Do this to create the swap file:

	ppdncrypt -i /dev/hda2
	losetup -e ppdd /dev/loop1 /dev/hda2
	mkswap /dev/loop1
	losetup -d /dev/loop0
	
You will need to avoid switching on swap in the startup script then manually
activate swap:

	losetup -e ppdd /dev/loop1 /dev/hda2
	swapon /dev/loop1

At shutdown you should do:

	swapoff /dev/loop1
	losetup -d /dev/loop0

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.
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.:

modprobe cryptoloop



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:

losetup -e ppdd /dev/loop0 /dev/hdc1
mount /dev/loop0 /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 
"losetup -d /dev/loop0" 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 losetup 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.

Note: ppdd-2.0 and Linux 2.4 series kernels seem to be much better.

Be aware that each device you activate with "losetup" needs about 150K 
of memory (kernel buffers). This is released with "losetup -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/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/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/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/loop0
losetup -d /dev/loop0

Erase the working pass phrase:

ppddpassw -e /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)

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/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.

ppdecrypt -o /dev/hdc1


Read-only media

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/loop device read-only.


Encryption and decryption without kernel support

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 losetup -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 losetup -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 "losetup -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 and
adds little or no extra security.

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 "losetup" to activate the device.

At the end of a session of using the encrypted filesystem you would run
"ppddcsum -g" to generate a new hash after the "losetup -d".

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

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 losetup 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 in read-only mode.
9. If there is any verifying of checksums to do linuxrc asks the user if he
   wants to do - it can take a long time. If so all ppdd devices flagged for
   verifying are checked.
10. Linuxrc then creates the necessary ppdd/loop devices. 
11. Linux continues with init on the encrypted root filesystem.
12. 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 1Gb
should be more than enough to load evrything you need for general Linux
maintenance work. Allow about 400Mb for the encrypted root and about 3Gb
for the encrypted /usr. I prefer to keep /var, /opt and /tmp on their own
filesystems and sizes of 2Gb, 1Gb and 1Gb have been OK for me. You will
usually want the rest of your disc space as /home. Don't forget about swap
space!  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.

The normal build allows 8 loop devices /dev/loop0 to /dev/loop7. Do not
use more than this. (/dev/loop0 will be "/", you need one for swap, that
only leaves you 6).

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. A full system
with X and helpfiles etc is not needed but you must have compilers etc.
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.

N.B.3 You MUST select "Virtual memory file system support (former shm fs)"
as a fixed part of the kernel.

Prepare /dev/hdc1 as an encrypted file systems; run ppdncrypt and mkfs.
Prepare /dev/hdc1 as an encrypted swap file; run ppdncrypt and mkswap.
Do this thoroughly i.e writing random data and strongly random keys.

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 partitions.
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 initrd file:

cd /mnt/-directory-containing-ppdd-sources
edit Makefile.config to make /dev/hda2 the real root device
make
make initrd
make install

Make the mount points:
cd /
mkdir home
mkdir initrd

Make sure "chroot" is in /bin - a link will not work!

Edit /etc/fstab by adding the lines:

/dev/loop1 /usr  ext2 defaults 1 2
/dev/loop2 /home ext2 defaults 1 2
/dev/loop7 swap  swap pri=42 0 0
amd remove any existing lines refering to /usr /home and swap

Create /etc/ppddtab containing:

n /dev/loop1 /dev/hda3 "first pass phrase" "second pass phrase"
n /dev/loop2 /dev/hdc1 "first pass phrase" "second pass phrase"
n /dev/loop7 /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.

ppdncrypt -o /dev/hda2
ppdncrypt -o /dev/hda3

Edit /etc/lilo.conf by adding the appaned and initrd line to option 3.
The root must be set to /dev/ram0.

  image  = /boot/vmlinuz-2.4.17
  label  = ppdd-2.4.17
  root   = /dev/ram0
  append = "init=/linuxrc"
  initrd = /boot/initrd.rd

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.4.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.

As CPU speeds have increased I have in fact kept the "live" kernel source
on the encrypted /usr. Only /boot needs to be unencrypted.

During shutdown you may see warnings but it generally works safely.
However to do the job properly and to make use of checksums you need to
modify your "halt" script - generally in /etc/rc.d/init.d. At the end - after
the root disc is remounted read-only but before the actual "halt" or "reboot"
you need to add:

if [ -f /etc/ppddtab ]; then
  if [ -x /initrd/ppdddown ]; then
    exec /initrd/ppdddown $command "$message"
  fi
fi
 
(taken from SuSE $command will be either "halt" or "reboot", $message will be
a user friendly "Please wait for reboot" or whatever)

During the ppdd boot sequence the root filesystem pass phrase is written to
the file /initrd/etc/ppddtab. It used later if you choose to checksum the root
disc during the halt/reboot sequence. This is a minimal risk. /initrd is in a
shared memory filesystem and only root has access to it. If you know you don't
need this then delete this file early in your normal boot sequence.


Modifying the initrd

If you need to modify the initrd used by ppdd root encryption then do this:

in the ppdd source directory you will find the "base" for the initrd - it is
called initrd.init. You should mount it on /mnt:

mount initrd.init /mnt -o loop

cd /mnt

You can then work on modifying this as required.

When you've finished just umount it and do a "make initrd", "make install" and
"lilo" as usual.


Using a bootable floppy disc.

The latest version will not fit onto a normal 1.44Mb floppy. You will need
to format to a higher number of sectors per track. This may of course not
boot with your bios!

I found that 1680Kb was OK.

fdformat /dev/fd0u1680

before you run the "make bootdisk".

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.

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.

Ppdd works with ext2, ext3 and Reiserfs. Do not use any other filesystem
on a ppdd device. DOS for example is known to overwrite the keys.

Ppdd has been tested on software raid (/dev/md) and works OK. It has not
been tested on logical volumes but it should be OK. Please let me know.

Allan Latham <alatham@flexsys-group.com> Revision 2.0 - January 2002 


