NAME
cgd —
cryptographic disk driver
SYNOPSIS
pseudo-device cgd
DESCRIPTION
The
cgd driver provides the capability of encrypting blocks on
their way to and from a disk or partition.
In order to compile support for the
cgd into your kernel, you
must add the driver to your kernel configuration file. To do this, add a line
similar to:
pseudo-device cgd # cryptographic disk driver
The
cgd devices are allocated as needed.
Encryption Algorithms
Currently the following cryptographic algorithms are supported:
-
-
- aes-cbc
- AES in CBC mode. AES uses a 128 bit blocksize and can
accept keys of length 128, 192, or 256. The default key length is
128.
-
-
- aes-xts
- AES in XTS mode. AES-XTS uses a 128 bit blocksize and can
accept keys of length 256 or 512. Note that an AES-XTS key consists of two
AES keys of equal size. The second key is used solely to encrypt the block
number of the physical disk block. The default key length is 256.
-
-
- 3des-cbc
- Triple DES in CBC mode. Triple DES uses a 64 bit blocksize
and is performed in EDE3 mode with a 168 bit key. The key passed to the
kernel is 192 bits but the parity bits are ignored.
-
-
- blowfish-cbc
- Blowfish in CBC mode. Blowfish uses a 64 bit blocksize and
can accept keys between 40 and 448 bits in multiples of 8. It is strongly
encouraged that keys be at least 128 bits long. There are no performance
advantages of using shorter keys. The default key length is 128 bits.
IV Methods
Currently, the following IV Methods are supported:
-
-
- encblkno1
- This method encrypts the block number of the physical disk
block once with the cipher and key provided and uses the result as the IV
for CBC mode. This method should ensure that each block has a different IV
and that the IV is reasonably unpredictable. This is the default method
used by cgdconfig(8) when
configuring a new cgd.
-
-
- encblkno8
- This is the original IV method used by
cgd and provided for backward compatibility. It
repeatedly encrypts the block number of the physical disk block eight
times and uses the result as the IV for CBC mode. This method should
ensure that each block has a different IV and that the IV is reasonably
unpredictable. The eightfold encryption was not intended and causes a
notable performance loss with little (if any) increase in security over a
single encryption.
IOCTLS
A
cgd responds to all of the standard disk
ioctl(2) calls defined in
sd(4), and also defines the
following:
-
-
CGDIOCSET
- Configure the cgd. This
ioctl(2) sets up the
encryption parameters and points the cgd at the
underlying disk.
-
-
CGDIOCCLR
- Unconfigure the cgd.
-
-
CGDIOCGET
- Get info about the cgd.
These
ioctl(2)'s and their
associated data structures are defined in
<dev/cgdvar.h> header.
WARNINGS
It goes without saying that if you forget the passphrase that you used to
configure a
cgd, then you have irrevocably lost all of the
data on the disk. Please ensure that you are using an appropriate backup
strategy.
A
cgd device doesn't authenticate data and thus it can't
guarantee integrity of the encrypted data. In particular, if the plaintext is
known to an adversary, it is possible to change every second block on a disk
encrypted in the CBC mode to plaintext blocks of their choice. The XTS mode
isn't vulnerable to this particular attack but a lack of integrity should be
taken into account when evaluating security risks.
FILES
-
-
- /dev/{,r}cgd*
- cgd device special files.
SEE ALSO
config(1),
ioctl(2),
sd(4),
cgdconfig(8),
MAKEDEV(8)
Roland C. Dowdeswell and
John Ioannidis, The CryptoGraphic
Disk Driver, Proceedings of the FREENIX Track: 2003
USENIX Annual Technical Conference, USENIX Association,
http://www.usenix.org/event/usenix03/tech/freenix03/full_papers/dowdeswell/dowdeswell.pdf,
179-186, June 9-14,
2003.
HISTORY
The
cgd driver was written by Roland C. Dowdeswell for
NetBSD. The
cgd driver originally
appeared in
NetBSD 2.0.