1 October 1999
Date: Thu, 30 Sep 1999 03:09:06 -0700
To: cypherpunks@algebra.com
From: "Doobee R.Tzeck" <doobee@ccc.de> (by way of Bill Stewart
<bill.stewart@pobox.com>)
Subject: Encrypting your Disks with Linux
Forwarded from "Doobee R.Tzeck" <doobee@ccc.de>'s posting to
Coderpunks
--------------------------
Getting a Notebook Computer seemed to be a good reason to me to start
encrypting my disks. I new there was disk encryption code for Linux
out there so I just had to patch it into the kernel.
Surfing the web for this Linux disk encryption code I found out there
is - unknown to the wide public - a LOT of code for this purpose out
there.
So I decided to write a small overview of the different aproaches for
disk encryption. For myself I decided to use ppdd but I like ehd with
kernel loopback encryption too, because it makes using disk encription
on a system used by multiple persons very easy. Perhaps I should fiddle
with ehd to work with ppdd.
If somebody likes to comment on the different tools/patches I would be
glad.
drt
----- cut here -----
http://drt.ailis.de/crypto/linux-disk.html
[1]
Encrypting your Disks with Linux
There are many reasons to encrypt your disks. Encryption can
be much
more secure than physical security. By using an encrypted disk
you can
defeat the attacks done by power-cycling your machine, booting
from
another volume and mounting your partitions. Encryption can
keep the
person which stole your Laptop form poking around in your
files.
There are more than half a dozen approaches towards encrypting
your
disks with Linux:
1. [2]Loopback Encryption
2. [3]Encrypted Home Directorys
3. [4]CFS - Cryptographic File System
4. [5]TCFS - Transparent Cryptographic Filesystem
5. [6]ppdd - Practical Privacy Disc Driver
6. [7]sfs - Steganographic File System for Linux
7. [8]StegFS - A Steganographic File System for Linux
8. [9]BestCrypt
The Kernel Loopback Encrypting Block device
The Kernel loopback encryption is the classic method of
encrypting
partitions with Linux. The loopback patch is based on the BSD
loopback
encryption and was ported by some prominent cypherpunks if I
remember
correctly. There used to be some steganographic patches to it
which
allowed you to mount an audio file as a filesystem and your
Data in
the lower bits of that audio file. Cool stuff, but this
steganographic
part somehow got lost in the 2.2 upgrade.
To use the encrypting loopback device you have to patch the
code into
the kernel and then build a patched losetup. Patching the kernel
is
straight forward because you can use the international kernel
patch at
[10]http://www.kerneli.org
but when building the new losetup you must
be careful not to mess with the other tools of util-linux since
it can
screw up your system badly.
The new loopback encryption patches can use a wide choice of
ciphers
(DFC, MARS, RC6, Serpent, CAST 128, IDEA, Twofish, Blowfish,
but not
all ciphers work).
Encrypted Home Directorys Patch
Id Est has patched login so that it enables the user to have
multiple
encrypted home directorys using the loopback encryption without
too
much hazzle. From his [11]README:
HOW DOES IT WORK?
If your home directory begins with "/crypt/", the
following happens
when you log in:
* a free loop device is found.
* you're asked for the size of your home directory
(4/8/16/32/64/128/256/512/1024 MB).
* once you've selected a size, a nMB-sized file
named
"/crypt/(your-id)" is created (ie.
/crypt/101).
* you are asked for a passphrase and given your
choice of encryption
algorithm.
* if this is the first time you've logged in, the
password you gave
is one-way hashed and put into the file
"/crypt/(your uid).x", or
compared against the contents of that
file otherwise. if the given
passphrase(s) don't match, you get bounced
out at this point.
* the loop device is set up using the previously
created file and
the passphrase you supplied.
* if this is the first time through, a ext2 filesystem
is created on
the loop device, otherwise the filesystem
is checked for errors.
if no errors are found, the filesystem
is mounted on the loop
device and you can proceed normally.
* if you're logged in and you log in again from
another VT, you're
asked for the passphrase, which is compared
against the stored
passphrase, and if they match, you can
proceed. this is to stop
somebody who knows your login password,
but not your EHD
passphrase from piggybacking into your
directory.
* when you log out the last time, the filesystem
is unmounted and
the loop device is freed.
If you use the loopback encryption ehd is a very nice to make
encryption easy to use even on a multiuser machine. But you
should
keep in mind that disk encryption doesn't help if you are using
the
machine at the same time with different users. So ehd practically
only
adds security if you use a stand alone machine. Besides
security
considerations you can't use ehd on a machine with
remote-login
enabled since ehd doesn't support ssh and su.
You can find ehd at
[12]http://members.home.net/id-est/.
CFS - Cryptographic File System
CFS is the first free UNIX disk encryption program hacked by
Matt
Blaze. It hooks into nfs so one feature of cfs is the fact that
you
don't have to fiddle with the kernel to get it running and cfs
is more
portable among UNIXes than the other solutions. Another nice
thing is
that you can use cfs over nfs so that your files won't be
transmitted
in clear text over the wire.You can find more about the working
of cfs
by reading the [13]Cryptographic File System under Linux HOW-TO
or
[14]"A Cryptographic File System for Unix" by Matt Blaze.
CFS supports DES which is insecure because the key is to short,
3DES
which can be considered secure but is painfully slow, MacGuffin
which
is broken and SAFER-SK128 which has a unusual design and is
designed
by some NSA buddys at Cylink - enough reason not to fully trust
this
algorithm. But darkstar@frop.org was kind enough to hack Blowfish
into
cfs. Blowfish seems reasonably secure and fast to use it but
darkstar
forgot to put the blowfish P-box and S-box tables into the tar
archive
so I repackaged the whole thing with the missing items.
The main problem of cfs even with blowfish is the lack of speed.
This
results in the cfs being an user space daemon forcing the data
to be
copied several times between kernel- and user space. If you
want to
encrypt large amounts of data expect a significant performance
penalty
when using cfs.
* [15]cfs source code
* [16]cfs with blowfish source code and bf_tab.h
TCFS - Transparent Cryptographic Filesystem
TCFS which is developed at the University of Salerno, Italy
claims to
improve Matt Blaze's CFS by providing deeper integration between
the
encryption service and the file system which results in a
complete
transparency of use to the user applications. But the developers
seem
to focus much more than Matt Blaze on substituting nfs.
A nice feature of TCFS is that it will allow you to securely
share
files among the members of a group. On big misfeatures of TCFS
is the
Fact that it needs kernel patches and that the patches are still
made
for the now obsolete 2.0.x Kernel. Nevertheless TCFS is under
active
Development. Another problem with TCFS is that it only
supports
minimal (read: no) key management. There is some Placebo-key
management delivered with TCFS but this is next to nothing using
only
the login passwort to decrypt the key.
To learn more about TCFS, read the [17]TCFS-FAQ. Since it is
from
Italy which is part of the free world, you can download it without
any
problems, go to the [18]TCFS Homepage.
ppdd - Practical Privacy Disc Driver
ppdd is a well thought through system for encrypting your disks.
Its
author Allan Latham describes it like this:
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 l 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 performance is slower than an un encrypted
file system
but on a 100MHz Pentium with 32Mb main memory using
IDE discs it
reduces disc throughput by about 50%; this should
be considered
accept able for software cryptography.
You can read more about the design of ppdd in the [19]specification
or
in the [20]ppdd man page. On of the very nice features of ppdd
is that
you can decrypt devices without kernel-support if needed. And
the
author has thought extensively about ways to backup encrypted
media
and shows several solutions to solve this problem. He even made
it
possible to have an encrypted root partition.
One of the drawbacks of ppdd is that it doesn't use the now
evolving
Linux crypto-API. But you can use it together with the
kerneli.org
patch without big hassle. Perhaps you get e few rejections
while
patching the two together but these are easy to resolve by
hand.
You can find ppdd at
[21]http://linux01.gwdg.de/~alatham
and
[22]ftp://ftp.gwdg.de/pub/linux/misc/ppdd.
If you want to know how to
install ppdd check out [23]ppddhow.txt
I have done some performance testing on a dual PII/266 MHz/256
MB
using bonnie. Writing on a encrypted volume takes about twice
the time
as writing to a plain volume would. But reading from an
encrypted
volume takes 4 times as long as reading from an unencrypted
one.
-------Sequential Output-------- ---Sequential Input--
--Random--
-----Time------
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
-user- -system-
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
K/sec %CPU /sec
%CPU
sec sec
plain 100 4022 95.0 13628 28.7 4036
17.8 3782 84.7 11663 20.4 286.3
7.0
42.98 13.82
encrypted 100 2609 75.5 5719 17.2 808 23.8
968 44.9 1165 28.1 18.2
5.1
43.40 103.28
While doing this tests my ps/2 mouse reacted like I was using
windows
:-( but this should be tweakable by skewing with the
buffer-cache.
sfs - steganographic file system for Linux
The theoretical background of sfs was laid by Ross Anderson,
Roger
Needham and Adi Shamir in thair paper "The Steganographic File
System". You can grab it [24]"here.
The first Implementation was done by Carl van Schaik and Paul
Smeddle.
They describe the code they have hacked this way:
Ok, firstly we would like to note that this project
evolved from a
computer science project that had specific goals
and deadlines and
thus the code may not be complete in specific areas
and still has
many bugs to be stomped out.
Briefly, a steganographic filesystem aims to be
more than just your
every day encrypted file system. It tries to hide
the information
in such a way as to discredit its very existence.
This has been a
very difficult task to perform given such a short
development time,
but we have succeeded in attaining this goal despite
a few
alternative methods of doing things (read: kludges
:).
We present this filesystem as is. We take no
responsibility for any
damage to disks or data while using this program.
I repeat.. this
is still VERY experimental and you will probably
lose data stored
on steganographic partitions. We also hope that
some of you will be
able to work out some of our problems and perhaps
try to modify the
structure to be more flexible and to provide better
security. After
all... thats the beauty of open source :)
We must also note that we use encryption methods
that may be
stronger than those allowed in your country. We
will accept no
responsibility for your actions involving your
country's
regulations.
They had a homepage at
[25]http://leg.uct.ac.za/~carl/vs3fs/
with
patches for Linux 2.0 and 2.1 but this page is now defunct.
Seems they
have left university and also left sfs alone.
[26]Peter Schneider-Kamp updated the stuff to 2.2. This stuff
can be
found at
[27]http://www.linux-security.org/sfs/.
But since his pages
seem to be down to you can get it [28]here.
sfs still has a lot of rough edges and Peter doesn't seem to
maintain
it actively.
StegFS - A Steganographic File System for Linux
Andrew McDonald and Markus Kuhn did another implementation of
the
ideas outlaid in the paper of Anderson, Needham and Shamir.
They claim
that sfs is flawed and this claim seem reasonable.
StegFS seems to be really elaborate and looks to me much more
usable
than sfs. Since McDonald and Kuhn come the same University
than
Anderson it seems obvious they tried hard too meet the criterias
of
the Steganographic Filesystem paper.
StegFS has a homepage at
[29]http://ban.joh.cam.ac.uk/~adm36/StegFS/
BestCrypt
There is some commercial disk encryption program for Linux
called
BestCrypt. It comes with source and is available for MS Windows
and
MacOS too. I haven't tried it yet, check it out at
[30]http://www.jetico.com/.
Missing here
* Speed testing
* Security overview
* Review of BestCrypt and TCFS
* Cleand up loopback encryption history
* a small command summary / man pages for the different
tools
_________________________________________________________________
[31]Doobee. R. Tzeck
Created: Tue Sep 14 17:08:06 CEST 1999
Last modified: Wed Sep 29 22:22:20 CEST 1999
References
1. drt.aililis.de/
2. drt.ailis.de/crypto/linux-disk.html#loopback
3. drt.ailis.de/crypto/linux-disk.html#ehd
4. drt.ailis.de/crypto/linux-disk.html#cfs
5. drt.ailis.de/crypto/linux-disk.html#tcfs
6. drt.ailis.de/crypto/linux-disk.html#ppdd
7. drt.ailis.de/crypto/linux-disk.html#sfs
8. drt.ailis.de/crypto/linux-disk.html#stegfs
9. drt.ailis.de/crypto/linux-disk.html#bestcrypt
10.
http://www.kerneli.org/
11. drt.ailis.de/crypto/ehd.README
12.
http://members.home.net/id-est/
13. drt.ailis.de/crypto/cfs-linux-HOWTO.txt
14.
ftp://research.att.com/dist/mab/
15. drt.ailis.de/crypto/cfs-1.3.3.tar.gz
16. drt.ailis.de/crypto/cfs-1.3.3bf.1.tar.gz
17.
http://tcfs.dia.unisa.it/tcfs-faq.html
18.
http://tcfs.dia.unisa.it/
19. drt.ailis.de/crypto/Specification.txt
20. drt.ailis.de/crypto/ppdd.man.html
21.
http://linux01.gwdg.de/~alatham/ppdd.html
22.
ftp://ftp.gwdg.de/pub/linux/misc/ppdd
23. drt.ailis.de/crypto/ppddhow.txt
24. drt.ailis.de/crypto/sfs3.ps.gz
25.
http://leg.uct.ac.za/~carl/vs3fs/
26.
mailto:peter@schneider-kamp.de
27.
http://www.linux-security.org/sfs/
28. drt.ailis.de/public_html/crypto/sfspatch-2.2.10.tar.gz
29.
http://ban.joh.cam.ac.uk/~adm36/StegFS/
30.
http://www.jetico.com/
31.
mailto:drt@ccc.de
--
D. R. Tzeck, Datenreisender