CGD(4)

CGD(4) | Device Drivers Manual | CGD(4)

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

August 31, 2018 | NetBSD 9.4