|
This is a short description on how you can set up encrypted directories on a linux file system. The idea is not to encrypt a whole file system, and not to use an encrypted container file, but to encrypt on a file by file basis.
The procedure should be totally transparent. Obviously, if someone "steals" your laptop, the machine should be worth nothing more than its amount of plastic, glass and metal. Particularly, if someone takes out the disk and puts it into his computer, he should not find any usable data.
The public key file is kept on a memory stick. Even if that stick is stolen, too, you still need your private key (which is in your head only), and it would mean to break the Geneva Convention to try to get at that private key...
The first thing that you need is encfs: encfs.sourceforge.net. You need the filesystem in user space option (CONFIG_FUSE_FS=m) enabled in your kernel, too.
Once you have installed encfs, imagine you have a directory /data/myuser which contains user data. First, create a backup of your data! Then you create a directory /data/... (that is, three ".") which is not so terribly visible and won't make too many people as curious on superficially seeing an "ls" compared to /data/secretstuff. You also create /data/.../data and /data/.../data/myuser. You then move /data/myuser to /data/myuser.old and create /data/myuser as an empty directory.
You are going to mount the encrypted content, which will reside in /data/.../data/myuser to the new mountpoint /data/myuser. You initiate that by saying
linux:/data # encfs /data/.../data/myuser /data/myuser Creating new encrypted volume. Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ?> p Paranoia configuration selected. Configuration finished. The filesystem to be created has the following properties: Filesystem cipher: "ssl/aes", version 2:1:1 Filename encoding: "nameio/block", version 3:0:1 Key Size: 256 bits Block Size: 512 bytes, including 8 byte MAC header Each file contains 8 byte header with unique IV data. Filenames encoded using IV chaining mode. File data IV is chained to filename IV. -------------------------- WARNING -------------------------- The external initialization-vector chaining option has been enabled. This option disables the use of hard links on the filesystem. Without hard links, some programs may not work. The programs 'mutt' and 'procmail' are known to fail. For more information, please see the encfs mailing list. If you would like to choose another configuration setting, please press CTRL-C now to abort and start over. Now you will need to enter a password for your filesystem. You will need to remember this password, as there is absolutely no recovery mechanism. However, the password can be changed later using encfsctl. New Encfs Password: Verify Encfs Password: linux:/data # ls -la /data/.../data/myuser total 4 drwxr-xr-x 2 root root 72 Feb 24 10:53 . drwxr-xr-x 5 root root 120 Feb 24 10:52 .. -rw-r----- 1 root root 239 Feb 24 10:53 .encfs5
You can see that a file .encfs5 has been created in /data/.../data/myuser. Now assume you have a memory stick and usually mount that to /mnt/memorystick. Create a directory .key on that memory stick (i.e., /mnt/memorystick/.key) and, in addition, create /mnt/memorystick/.key/data and /mnt/memorystick/.key/data/myuser. Then move /data/.../data/myuser/.encfs5 to /mnt/memorystick/.key/data/myuser/.
Keep a copy of .encfs5 in a safe location! This is your public key, so you will not be able to access your files anymore once you have lost that key file.
Finally, create a file /etc/crypto.conf with a content like
# # Configuration of mount points for the crypted directories # # Resources can be encrypted using # # encfs "Encrypted Content Location" "Mountpoint" # # The format of this file is # # Resource Name Encrypted Content Location Mountpoint Keyfile # myuser /data/.../data/myuser /data/myuser data/myuser/.encfs5 java /data/.../pgm/java /pgm/java pgm/java/.encfs5
You see that I've created another entry in the config file to show how it works. Finally, use the following perl script like "crypto mount myuser" to mount the directory for "myuser", or "crypto" or "crypto all" to mount all definitions or "crypto umount myuser" to unmount the directory for "myuser" or "crypto umount all" to unmount all definitions:
#!/usr/bin/perl -w # # This is a script that mounts crypted file systems based # on public keys that have to be available on a memory stick. # # (c) 2006, Matthias Nott, MN Soft Branchensoftware use strict; use warnings; use File::Listing; use Term::ReadKey; my $memorystick = "SanDisk"; # Vendor String of Memory Stick my $mountpoint = "/mnt/memorystick"; # Mount point my $keyfiledir = "$mountpoint/.key"; # Key Files Location my $configfile = "/etc/crypto.conf"; # Configuration of Crypted File Systems my $task = "mount"; my $target = "all"; my $memstickmounted = 0; # Will be set to 1 if memory stick was mounted # specifically for this application ($task, $target) = @ARGV if(scalar @ARGV> 0); if(! defined($target)) { $target = "all"; } # # Test for availability of memory stick # if($task eq "mount" && !-d "$keyfiledir") { my %vendors; file: for (parse_dir(`find /sys/block -follow -iname "vendor" | xargs ls -l`)) { # # Get the file information # my ($name, $type, $size, $mtime, $mode) = @$_; next if not $name =~ m!/sys/block/sd./device/vendor!; my $devid = $name; my $devname = ""; $devid =~ s!/sys/block/ ([^/ ]+? )/.*!$ 1!; open(VENDOR, "$name") || die "Cannot open: $!\n"; while(<VENDOR>) { $vendors{$_} = $devid; $devname = $_; } last if $devname eq $memorystick; } die "Unable to find the $memorystick memory stick!" if(! defined($vendors{$memorystick})); if(length(`mount | grep "$vendors{$memorystick}"` ) == 0) { print "Mounting: $mountpoint\n"; system("mount \"/dev/$vendors{$memorystick}1\" \"$mountpoint\""); $memstickmounted = 1; } die "Unable to load keys from memory stick!" if (!-d "$keyfiledir"); } open (CRYPTO, "<$configfile") || die "Cannot open: $!\n"; my $pass = ""; if($task eq "mount") { # # Ask for password # ReadMode('noecho'); print "Enter Crypto Key: "; $| = 1; $pass = ReadLine(0); ReadMode('normal'); } my $helped = 0; while(<CRYPTO>) { if(!/^#.*$/) { if(/^ ([^\ s]+? )\ s+? ([^\ s]+? )\ s+? ([^\ s]+? )\ s+? ([^\ s]+? )$/ ) { # # Resource name | Encrypted Content Location | Mountpoint | Keyfile # if($task eq "mount") { if(($target eq "all") || $target eq $1) { if(!-d $3) { } print "Mounting: $1 -> $3\n"; system("echo $pass | ENCFS5_CONFIG=\"$keyfiledir/$4\" encfs -S --public \"$2\" \"$3\""); } } } elsif($task eq "umount") { if($target eq "all" || $target eq $1) { print "Unmounting: $1 -> $3\n"; } } } elsif(!$helped++) { print "Options: mount|umount all|resource name\n"; } } } } if($task eq "umount" || $memstickmounted) { print "Unmounting: $mountpoint\n"; system("umount \"$mountpoint\""); } }
The above Perl script assumes you are using the same password for all mounts; if this is not the case, you'll have to rewrite it accordingly. When you backup your file system, simply exclude /data/myuser from the backup process, as it will be covered by /data/.../data/myuser. If you now wonder what is in /data/.../data/myuser: move all your content of /data/myuser.old to /data/myuser while the crypted directory is mounted. Then hava a look at /data/.../data/myuser: You see only garbled directory entries and garbled file contents, whereas in /data/myuser you see everything just as before. When you "crypto umount", you get an empty directory /data/myuser.
Performance wise, I encrypt all my data using that mechanism. Behind the scenes, a 256 bit encryption is used, so for the time being, the data can be regarded as safe (provided you keep /tmp/ in a ramdisk, etc.). I am pretty happy with that system. It is even normally not necessary to "umount" the file systems while you go on a coffee break: simply lock your screen. Unmounting the file systems would require closing all files on them which may be inconvenient. If you lock the screen, people would have shut down your computer and put your disk into another computer, in which case the file systems would have been unmounted automatically.
Safety wise, it is a good idea to use a file by file method, as you do not risk to loose all your data because of a loss of a container file. In addition, loopback mounting a container file seems elegant, yet you're going to be limited to the size of the container file as you initially created it.
|
