FreeBSD offers excellent online protections against unauthorized data access. File
permissions and Mandatory Access Control (MAC) (see Chapter 16)
help prevent unauthorized third-parties from accessing data while the operating system is
active and the computer is powered up. However, the permissions enforced by the operating
system are irrelevant if an attacker has physical access to a computer and can simply
move the computer's hard drive to another system to copy and analyze the sensitive
data.
Regardless of how an attacker may have come into possession of a hard drive or
powered-down computer, both GEOM Based Disk Encryption (gbde)
and geli cryptographic subsystems in FreeBSD are able to protect
the data on the computer's file systems against even highly-motivated attackers with
significant resources. Unlike cumbersome encryption methods that encrypt only individual
files, gbde and geli transparently
encrypt entire file systems. No cleartext ever touches the hard drive's platter.
The following example assumes that you are adding a new hard drive to your system that
will hold a single encrypted partition. This partition will be mounted as /private. gbde can also be used to
encrypt /home and /var/mail, but this
requires more complex instructions which exceed the scope of this introduction.
Add the New Hard Drive
Install the new drive to the system as explained in Section 18.3. For the purposes of this example, a new hard
drive partition has been added as /dev/ad4s1c. The /dev/ad0s1* devices represent
existing standard FreeBSD partitions on the example system.
The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to
the lock file, gbde will not be able to decrypt the data
contained in the encrypted partition without significant manual intervention which is not
supported by the software. Each encrypted partition uses a separate lock file.
Initialize the gbde Partition
A gbde partition must be initialized before it can be used.
This initialization needs to be performed only once:
gbde(8) will open your
editor, permitting you to set various configuration options in a template. For use with
UFS1 or UFS2, set the sector_size to 2048:
$FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $
#
# Sector size is the smallest unit of data which can be read or written.
# Making it too small decreases performance and decreases available space.
# Making it too large may prevent filesystems from working. 512 is the
# minimum and always safe. For UFS, use the fragment size
#
sector_size = 2048
[...]
gbde(8) will ask you
twice to type the passphrase that should be used to secure the data. The passphrase must
be the same both times. gbde's ability to protect your data
depends entirely on the quality of the passphrase that you choose. [1]
The gbde init command creates a lock file for your gbde partition that in this example is stored as /etc/gbde/ad4s1c.lock. gbde lock files
must end in “.lock” in order to be correctly detected by the /etc/rc.d/gbde start up script.
Caution:gbde lock files must be backed up together with the contents of any encrypted
partitions. While deleting a lock file alone cannot prevent a determined attacker from
decrypting a gbde partition, without the lock file, the
legitimate owner will be unable to access the data on the encrypted partition without a
significant amount of work that is totally unsupported by gbde(8) and its
designer.
Attach the Encrypted Partition to the Kernel
#gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock
You will be asked to provide the passphrase that you selected during the
initialization of the encrypted partition. The new encrypted device will show up in /dev as /dev/device_name.bde:
Once the encrypted device has been attached to the kernel, you can create a file
system on the device. To create a file system on the encrypted device, use newfs(8). Since it is
much faster to initialize a new UFS2 file system than it is to initialize the old UFS1
file system, using newfs(8) with the
-O2 option is recommended.
#newfs -U -O2 /dev/ad4s1c.bde
Note: The newfs(8) command must
be performed on an attached gbde partition which is identified
by a *.bde extension to the
device name.
Mount the Encrypted Partition
Create a mount point for the encrypted file system.
#mkdir /private
Mount the encrypted file system.
#mount /dev/ad4s1c.bde /private
Verify That the Encrypted File System is Available
The encrypted file system should now be visible to df(1) and be available
for use.
After each boot, any encrypted file systems must be re-attached to the kernel, checked
for errors, and mounted, before the file systems can be used. The required commands must
be executed as user root.
Attach the gbde Partition to the Kernel
#gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock
You will be asked to provide the passphrase that you selected during initialization of
the encrypted gbde partition.
Check the File System for Errors
Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked
for errors by running fsck(8) manually
before mounting.
#fsck -p -t ffs /dev/ad4s1c.bde
Mount the Encrypted File System
#mount /dev/ad4s1c.bde /private
The encrypted file system is now available for use.
It is possible to create a script to automatically attach, check, and mount an
encrypted partition, but for security reasons the script should not contain the gbde(8) password.
Instead, it is recommended that such scripts be run manually while providing the password
via the console or ssh(1).
As an alternative, an rc.d script is provided. Arguments for
this script can be passed via rc.conf(5), for
example:
This will require that the gbde passphrase be entered at
boot time. After typing the correct passphrase, the gbde
encrypted partition will be mounted automatically. This can be very useful when using gbde on notebooks.
gbde(8) encrypts the
sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a
different AES key. For more information on gbde's
cryptographic design, including how the sector keys are derived from the user-supplied
passphrase, see gbde(4).
sysinstall(8) is
incompatible with gbde-encrypted devices. All *.bde devices must be
detached from the kernel before starting sysinstall(8) or it
will crash during its initial probing for devices. To detach the encrypted device used in
our example, use the following command:
#gbde detach /dev/ad4s1c
Also note that, as vinum(4) does not use
the geom(4) subsystem, you
cannot use gbde with vinum
volumes.
A new cryptographic GEOM class is available as of FreeBSD 6.0 - geli. It is currently being developed by Pawel Jakub Dawidek <[email protected]>. The
geli utility is different to gbde; it
offers different features and uses a different scheme for doing cryptographic work.
Utilizes the crypto(9) framework --
when cryptographic hardware is available, geli will use it
automatically.
Supports multiple cryptographic algorithms (currently AES, Blowfish, and 3DES).
Allows the root partition to be encrypted. The passphrase used to access the encrypted
root partition will be requested during the system boot.
Allows the use of two independent keys (e.g. a “key” and a “company
key”).
geli is fast - performs simple sector-to-sector
encryption.
Allows backup and restore of Master Keys. When a user has to destroy his keys, it will
be possible to get access to the data again by restoring keys from the backup.
Allows to attach a disk with a random, one-time key -- useful for swap partitions and
temporary file systems.
More geli features can be found in the geli(8) manual
page.
The next steps will describe how to enable support for geli
in the FreeBSD kernel and will explain how to create and use a geli encryption provider.
In order to use geli, you must be running FreeBSD 6.0-RELEASE
or later. Super-user privileges will be required since modifications to the kernel are
necessary.
Adding geli Support to the Kernel
Add the following lines to the kernel configuration file:
The following example will describe how to generate a key file, which will be used as
part of the Master Key for the encrypted provider mounted under /private. The key file will provide some random data used to
encrypt the Master Key. The Master Key will be protected by a passphrase as well.
Provider's sector size will be 4kB big. Furthermore, the discussion will describe how to
attach the geli provider, create a file system on it, how to
mount it, how to work with it, and finally how to detach it.
It is recommended to use a bigger sector size (like 4kB) for better performance.
The Master Key will be protected with a passphrase and the data source for key file
will be /dev/random. The sector size of /dev/da2.eli, which we call provider, will be 4kB.
#dd if=/dev/random of=/root/da2.key bs=64 count=1#geli init -s 4096 -K /root/da2.key /dev/da2
Enter new passphrase:
Reenter new passphrase:
It is not mandatory that both a passphrase and a key file are used; either method of
securing the Master Key can be used in isolation.
If key file is given as “-”, standard input will be used. This example
shows how more than one key file can be used.
Once the work on the encrypted partition is done, and the /private partition is no longer needed, it is prudent to consider
unmounting and detaching the geli encrypted partition from the
kernel.
#umount /private#geli detach da2.eli
More information about the use of geli(8) can be found
in the manual page.
This will configure /dev/da2 as a geli provider of which the Master Key file is located in /root/da2.key, and geli will not use a
passphrase when attaching the provider (note that this can only be used if -P was given during the geli init phase).
The system will detach the geli provider from the kernel before
the system shuts down.
More information about configuring rc.d is provided in the
rc.d section of the Handbook.
