Manual Pages  — GELI

Alternatively, to load the GEOM_ELI module at boot time, add the following line to your loader.conf(5):

geom_eli_load="YES"

Usage of the
geli utility:

geli init [-bdgPTv] [-a aalgo] [-B backupfile] [-e ealgo] [-i iterations] [-J newpassfile] [-K newkeyfile] [-l keylen] [-s sectorsize] [-V version] prov ...
geli label - an alias for init
geli attach [-Cdprv] [-n keyno] [-j passfile] [-k keyfile] prov ...
geli detach [-fl] prov ...
geli stop - an alias for detach
geli onetime [-dT] [-a aalgo] [-e ealgo] [-l keylen] [-s sectorsize] prov
geli configure [-bBdDgGtT] prov ...
geli setkey [-pPv] [-i iterations] [-j passfile] [-J newpassfile] [-k keyfile] [-K newkeyfile] [-n keyno] prov
geli delkey [-afv] [-n keyno] prov
geli kill [-av] [prov ...]
geli backup [-v] prov file
geli restore [-fv] file prov
geli suspend [-v] -a | prov ...
geli resume [-pv] [-j passfile] [-k keyfile] prov
geli resize [-v] -s oldsize prov
geli version [prov ...]
geli clear [-v] prov ...
geli dump [-v] prov ...
geli list
geli status
geli load
geli unload

• Utilizes the crypto(9) framework, so when there is crypto hardware available, geli will make use of it automatically.
• Supports many cryptographic algorithms (currently AES-XTS, AES-CBC, Blowfish-CBC, Camellia-CBC and 3DES-CBC).
• Can optionally perform data authentication (integrity verification) utilizing one of the following algorithms: HMAC/MD5, HMAC/SHA1, HMAC/RIPEMD160, HMAC/SHA256, HMAC/SHA384 or HMAC/SHA512.
• Can create a User Key from up to two, piecewise components: a passphrase entered via prompt or read from one or more passfiles; a keyfile read from one or more files.
• Allows encryption of the root partition. The user is asked for the passphrase before the root filesystem is mounted.
• Strengthens the passphrase component of the User Key with:

  B. Kaliski, 2898, RFC, PKCS #5: Password-Based Cryptography Specification, Version 2.0.,

• Allows the use of two independent User Keys (e.g., a "user key" and a "company key").
• It is fast - geli performs simple sector-to-sector encryption.
• Allows the encrypted Master Key to be backed up and restored, so that if a user has to quickly destroy key material, it is possible to get the data back by restoring keys from backup.
• Providers can be configured to automatically detach on last close, so users do not have to remember to detach providers after unmounting the filesystems.
• Allows attaching a provider with a random, one-time Master Key, which is useful for swap partitions and temporary filesystems.
• Allows verification of data integrity (data authentication).
• Allows suspending and resuming encrypted devices.

The first argument to geli indicates an action to be performed:

init

Initialize providers which need to be encrypted. If multiple providers are listed as arguments, they will all be initialized with the same passphrase and/or User Key. A unique salt will be randomly generated for each provider to ensure the Master Key for each is unique. Here you can set up the cryptographic algorithm to use, Data Key length, etc. The last sector of the providers is used to store metadata. The init subcommand also automatically writes metadata backups to /var/backups/<prov>.eli file. The metadata can be recovered with the restore subcommand described below. Additional options include:

-a aalgo	Enable data integrity verification (authentication) using the given algorithm. This will reduce the size of storage available and also reduce speed. For example, when using 4096 bytes sector and HMAC/SHA256 algorithm, 89% of the original provider storage will be available for use. Currently supported algorithms are: HMAC/MD5, HMAC/SHA1, HMAC/RIPEMD160, HMAC/SHA256, HMAC/SHA384 and HMAC/SHA512. If the option is not given, there will be no authentication, only encryption. The recommended algorithm is HMAC/SHA256.
-b	Try to decrypt this partition during boot, before the root partition is mounted. This makes it possible to use an encrypted root partition. One will still need bootable unencrypted storage with a /boot/ directory, which can be a CD-ROM disc or USB pen-drive, that can be removed after boot.
-B backupfile
	File name to use for metadata backup instead of the default /var/backups/<prov>.eli. To inhibit backups, you can use none as the backupfile. If multiple providers were initialized in the one command, you can use PROV (all upper-case) in the file name, and it will be replaced with the provider name. If PROV is not found in the file name and multiple providers were initialized in the one command, -<prov> will be appended to the end of the file name specified.
-d	When entering the passphrase to boot from this encrypted root filesystem, echo ‘*’ characters. This makes the length of the passphrase visible.
-e ealgo	Encryption algorithm to use. Currently supported algorithms are: AES-XTS, AES-CBC, Blowfish-CBC, Camellia-CBC, 3DES-CBC, and NULL. The default and recommended algorithm is AES-XTS. NULL is unencrypted.
-g	Enable booting from this encrypted root filesystem. The boot loader prompts for the passphrase and loads loader(8) from the encrypted partition.
-i iterations
	Number of iterations to use with PKCS#5v2 when processing User Key passphrase component. If this option is not specified, geli will find the number of iterations which is equal to 2 seconds of crypto work. If 0 is given, PKCS#5v2 will not be used. PKCS#5v2 processing is performed once, after all parts of the passphrase component have been read.
-J newpassfile
	Specifies a file which contains the passphrase component of the User Key (or part of it). If newpassfile is given as -, standard input will be used. Only the first line (excluding new-line character) is taken from the given file. This argument can be specified multiple times, which has the effect of reassembling a single passphrase split across multiple files. Cannot be combined with the -P option.
-K newkeyfile
	Specifies a file which contains the keyfile component of the User Key (or part of it). If newkeyfile is given as -, standard input will be used. This argument can be specified multiple times, which has the effect of reassembling a single keyfile split across multiple keyfile parts.
-l keylen	Data Key length to use with the given cryptographic algorithm. If the length is not specified, the selected algorithm uses its default key length.

AES-XTS	128, 256
AES-CBC	128, 192, 256
Blowfish-CBC	128 + n * 32, for n=[0..10]
3DES-CBC	192

-P	Do not use a passphrase as a component of the User Key. Cannot be combined with the -J option.
-s sectorsize	Change decrypted provider's sector size. Increasing the sector size allows increased performance, because encryption/decryption which requires an initialization vector is done per sector; fewer sectors means less computational work.
-T	Don't pass through BIO_DELETE calls (i.e., TRIM/UNMAP). This can prevent an attacker from knowing how much space you're actually using and which sectors contain live data, but will also prevent the backing store (SSD, etc) from reclaiming space you're not using, which may degrade its performance and lifespan. The underlying provider may or may not actually obliterate the deleted sectors when TRIM is enabled, so it should not be considered to add any security.
-V version	Metadata version to use. This option is helpful when creating a provider that may be used by older FreeBSD/GELI versions. Consult the HISTORY section to find which metadata version is supported by which FreeBSD version. Note that using an older version of metadata may limit the number of features available.

attach

Attach the given providers. The encrypted Master Keys are loaded from the metadata and decrypted using the given passphrase/keyfile and new GEOM providers are created using the specified provider names. A ".eli" suffix is added to the user specified provider names. Multiple providers can only be attached with a single attach command if they all have the same passphrase and keyfiles. Additional options include:

-C	Do a dry-run decryption. This is useful to verify passphrase and keyfile without decrypting the device.
-d	If specified, the decrypted providers are detached automatically on last close, so the user does not have to remember to detach providers after unmounting the filesystems. This only works when providers were opened for writing, and will not work if the filesystems on the providers were mounted read-only. Probably a better choice is the -l option for the detach subcommand.
-n keyno
	Specifies the index number of the Master Key copy to use (could be 0 or 1). If the index number is not provided all keys will be tested.
-j passfile
	Specifies a file which contains the passphrase component of the User Key (or part of it). For more information see the description of the -J option for the init subcommand. The same passfiles are used for all listed providers.
-k keyfile
	Specifies a file which contains the keyfile component of the User Key (or part of it). For more information see the description of the -K option for the init subcommand. The same keyfiles are used for all listed providers.
-p	Do not use a passphrase as a component of the User Keys. Cannot be combined with the -j option.
-r	Attach read-only providers. They are not opened for writing.

detach	Detach the given providers, which means remove the devfs entry and clear the Master Key and Data Keys from memory. Additional options include:

-f
	Force detach - detach even if the provider is open.
-l
	Mark provider to detach on last close, after the last filesystem has been unmounted. If this option is specified, the provider will not be detached while it is open, but will be automatically detached when it is closed for the last time even if it was only opened for reading.

onetime
	Attach the given providers with a random, one-time (ephemeral) Master Key. The command can be used to encrypt swap partitions or temporary filesystems. Additional options include:

-a aalgo	Enable data integrity verification (authentication). For more information, see the description of the init subcommand.
-e ealgo	Encryption algorithm to use. For more information, see the description of the init subcommand.
-d	Detach on last close, after the last filesystem has been unmounted. Note: this option is not usable for temporary filesystems as the provider is detached after the filesystem has been created. It still can, and should, be used for swap partitions. For more information, see the description of the attach subcommand.
-l keylen
	Data Key length to use with the given cryptographic algorithm. For more information, see the description of the init subcommand.
-s sectorsize
	Change decrypted provider's sector size. For more information, see the description of the init subcommand.
-T	Disable TRIM/UNMAP passthru. For more information, see the description of the init subcommand.

configure	Change configuration of the given providers. Additional options include:

-b
	Set the BOOT flag on the given providers. For more information, see the description of the init subcommand.
-B
	Remove the BOOT flag from the given providers.
-d
	When entering the passphrase to boot from this encrypted root filesystem, echo ‘*’ characters. This makes the length of the passphrase visible.
-D
	Disable echoing of any characters when a passphrase is entered to boot from this encrypted root filesystem. This hides the passphrase length.
-g
	Enable booting from this encrypted root filesystem. The boot loader prompts for the passphrase and loads loader(8) from the encrypted partition.
-G
	Deactivate booting from this encrypted root partition.
-t
	Enable TRIM/UNMAP passthru. For more information, see the description of the init subcommand.
-T
	Disable TRIM/UNMAP passthru.

setkey
	Install a copy of the Master Key into the selected slot, encrypted with a new User Key. If the selected slot is populated, replace the existing copy. A provider has one Master Key, which can be stored in one or both slots, each encrypted with an independent User Key. With the init subcommand, only key number 0 is initialized. The User Key can be changed at any time: for an attached provider, for a detached provider, or on the backup file. When a provider is attached, the user does not have to provide an existing passphrase/keyfile. Additional options include:

-i iterations
	Number of iterations to use with PKCS#5v2. If 0 is given, PKCS#5v2 will not be used. To be able to use this option with the setkey subcommand, only one key has to be defined and this key must be changed.
-j passfile
	Specifies a file which contains the passphrase component of a current User Key (or part of it).
-J newpassfile
	Specifies a file which contains the passphrase component of the new User Key (or part of it).
-k keyfile
	Specifies a file which contains the keyfile component of a current User Key (or part of it).
-K newkeyfile
	Specifies a file which contains the keyfile component of the new User Key (or part of it).
-n keyno	Specifies the index number of the Master Key copy to change (could be 0 or 1). If the provider is attached and no key number is given, the key used for attaching the provider will be changed. If the provider is detached (or we are operating on a backup file) and no key number is given, the first Master Key copy to be successfully decrypted with the provided User Key passphrase/keyfile will be changed.
-p	Do not use a passphrase as a component of the current User Key. Cannot be combined with the -j option.
-P	Do not use a passphrase as a component of the new User Key. Cannot be combined with the -J option.

delkey	Destroy (overwrite with random data) the selected Master Key copy. If one is destroying keys for an attached provider, the provider will not be detached even if all copies of the Master Key are destroyed. It can even be rescued with the setkey subcommand because the Master Key is still in memory. Additional options include:

-a	Destroy all copies of the Master Key (does not need -f option).
-f	Force key destruction. This option is needed to destroy the last copy of the Master Key.
-n keyno
	Specifies the index number of the Master Key copy. If the provider is attached and no key number is given, the key used for attaching the provider will be destroyed. If provider is detached (or we are operating on a backup file) the key number has to be given.

kill

This command should be used only in emergency situations. It will destroy all copies of the Master Key on a given provider and will detach it forcibly (if it is attached). This is absolutely a one-way command - if you do not have a metadata backup, your data is gone for good. In case the provider was attached with the -r flag, the keys will not be destroyed, only the provider will be detached. Additional options include:

-a
	If specified, all currently attached providers will be killed.

backup
	Backup metadata from the given provider to the given file.
restore
	Restore metadata from the given file to the given provider. Additional options include:
-f
	Metadata contains the size of the provider to ensure that the correct partition or slice is attached. If an attempt is made to restore metadata to a provider that has a different size, geli will refuse to restore the data unless the -f switch is used. If the partition or slice has been grown, the resize subcommand should be used rather than attempting to relocate the metadata through backup and restore.

suspend
	Suspend device by waiting for all inflight requests to finish, clearing all sensitive information such as the Master Key and Data Keys from kernel memory, and blocking all further I/O requests until the resume subcommand is executed. This functionality is useful for laptops. Suspending a laptop should not leave an encrypted device attached. The suspend subcommand can be used rather than closing all files and directories from filesystems on the encrypted device, unmounting the filesystem, and detaching the device. Any access to the encrypted device will be blocked until the Master Key is reloaded through the resume subcommand. Thus there is no need to close nor unmount anything. The suspend subcommand does not work with devices created with the onetime subcommand. Please note that sensitive data might still be present in memory locations such as the filesystem cache after suspending an encrypted device. Additional options include:
-a
	Suspend all geli devices.

resume
	Resume previously suspended device. The caller must ensure that executing this subcommand does not access the suspended device, leading to a deadlock. For example, suspending a device which contains the filesystem where the geli utility is stored is a bad idea. Additional options include:

-j passfile
	Specifies a file which contains the passphrase component of the User Key, or part of it. For more information see the description of the -J option for the init subcommand.
-k keyfile
	Specifies a file which contains the keyfile component of the User Key, or part of it. For more information see the description of the -K option for the init subcommand.
-p	Do not use a passphrase as a component of the User Key. Cannot be combined with the -j option.

resize	Inform geli that the provider has been resized. The old metadata block is relocated to the correct position at the end of the provider and the provider size is updated. Additional options include:

-s oldsize
	The size of the provider before it was resized.

version	If no arguments are given, the version subcommand will print the version of geli userland utility as well as the version of the ELI GEOM class. If GEOM providers are specified, the version subcommand will print metadata version used by each of them.
clear	Clear metadata from the given providers. WARNING: This will erase with zeros the encrypted Master Key copies stored in the metadata.
dump	Dump metadata stored on the given providers.
list	See geom(8).
status	See geom(8).
load	See geom(8).
unload	See geom(8).

Additional options include:

-v
	Be more verbose.

# dd if=/dev/random of=/mnt/pendrive/da2.key bs=64 count=1
# geli init -s 4096 -K /mnt/pendrive/da2.key /dev/da2
Enter new passphrase:
Reenter new passphrase:
# geli attach -k /mnt/pendrive/da2.key /dev/da2
Enter passphrase:
# dd if=/dev/random of=/dev/da2.eli bs=1m
# newfs /dev/da2.eli
# mount /dev/da2.eli /mnt/secret
amp;...
# umount /mnt/secret
# geli detach da2.eli

# geli init /dev/da2
Enter new passphrase:   (enter security officer's passphrase)
Reenter new passphrase:
# geli setkey -n 1 /dev/da2
Enter passphrase:       (enter security officer's passphrase)
Enter new passphrase:   (let your employee enter his passphrase ...)
Reenter new passphrase: (... twice)

# dd if=/dev/random of=/mnt/pendrive/keys/`hostname` bs=64 count=1
# geli init -P -K /mnt/pendrive/keys/`hostname` /dev/ada0s1e
# geli backup /dev/ada0s1e /mnt/pendrive/backups/`hostname`
(use key number 0, so the encrypted Master Key will be re-encrypted by this)
# geli setkey -n 0 -k /mnt/pendrive/keys/`hostname` /dev/ada0s1e
(allow the user to enter his passphrase)
Enter new passphrase:
Reenter new passphrase:

# dd if=/dev/random of=/dev/ada0s1b bs=1m
# geli onetime -d -e 3des ada0s1b
# swapon /dev/ada0s1b.eli

# dd if=/dev/random of=/dev/da0 bs=1m
# dd if=/dev/random of=/boot/keys/da0.key0 bs=32k count=1
# dd if=/dev/random of=/boot/keys/da0.key1 bs=32k count=1
# dd if=/dev/random of=/boot/keys/da0.key2 bs=32k count=1
# geli init -b -K /boot/keys/da0.key0 -K /boot/keys/da0.key1 -K /boot/keys/da0.key2 da0
Enter new passphrase:
Reenter new passphrase:
# dd if=/dev/random of=/dev/da1s3a bs=1m
# dd if=/dev/random of=/boot/keys/da1s3a.key bs=128k count=1
# geli init -b -P -K /boot/keys/da1s3a.key da1s3a

geli_da0_keyfile0_load="YES"
geli_da0_keyfile0_type="da0:geli_keyfile0"
geli_da0_keyfile0_name="/boot/keys/da0.key0"
geli_da0_keyfile1_load="YES"
geli_da0_keyfile1_type="da0:geli_keyfile1"
geli_da0_keyfile1_name="/boot/keys/da0.key1"
geli_da0_keyfile2_load="YES"
geli_da0_keyfile2_type="da0:geli_keyfile2"
geli_da0_keyfile2_name="/boot/keys/da0.key2"

geli_da1s3a_keyfile0_load="YES"
geli_da1s3a_keyfile0_type="da1s3a:geli_keyfile0"
geli_da1s3a_keyfile0_name="/boot/keys/da1s3a.key"

geli_da1s3a_keyfile_load="YES"
geli_da1s3a_keyfile_type="da1s3a:geli_keyfile"
geli_da1s3a_keyfile_name="/boot/keys/da1s3a.key"

# geli init -a hmac/sha256 -s 4096 /dev/da0
Enter new passphrase:
Reenter new passphrase:
# geli attach /dev/da0
Enter passphrase:
# dd if=/dev/random of=/dev/da0.eli bs=1m
# newfs /dev/da0.eli
# mount /dev/da0.eli /mnt/secret

# geli init /dev/da0
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0.eli and
can be restored with the following command:

        # geli restore /var/backups/da0.eli /dev/da0

# geli clear /dev/da0
# geli attach /dev/da0
geli: Cannot read metadata from /dev/da0: Invalid argument.
# geli restore /var/backups/da0.eli /dev/da0
# geli attach /dev/da0
Enter passphrase:

# gpart create -s GPT ada0
# gpart add -s 1g -t freebsd-ufs -i 1 ada0
# geli init -K keyfile -P ada0p1
# gpart resize -s 2g -i 1 ada0
# geli resize -s 1g ada0p1
# geli attach -k keyfile -p ada0p1

# echo foo > da0.pass0
# echo bar > da0.pass1
# geli init -J da0.pass0 -J da0.pass1 da0
# geli attach -j da0.pass0 -j da0.pass1 da0
# geli detach da0
# geli attach da0
Enter passphrase: foobar

# geli suspend -a
# zzz
<resume your laptop>
# geli resume -p -k keyfile gpt/secret
# geli resume gpt/private
Enter passphrase:

# dd if=/dev/zero of=/usr/private0 bs=1m count=256
# chmod 0600 /usr/private0
# mdconfig -t vnode -f /usr/private0

It is recommended to place the following line in rc.conf(5) to have the memory disk automatically created during boot.

mdconfig_md0="-t vnode -f /usr/private0"

After /dev/md0 is created a random key has to be generated and stored in a secure location, like /root for example. This key should be protected by a passphrase, which is requested when geli init is called.

# dd if=/dev/random of=/root/private0.key bs=64 count=1
# geli init -K /root/private0.key -s 4096 /dev/md0
Enter new passphrase:
Reenter new passphrase:
# geli attach -k /root/private0.key /dev/md0
Enter passphrase:
# dd if=/dev/random of=/dev/md0.eli bs=1m

Once the initialization of the /dev/md0.eli device is ready create a UFS filesystem and mount it for example in /private.

# newfs /dev/md0.eli
# mount /dev/md0.eli /private

After a system reboot the geli device can be mounted again with the following commands. The call of geli attach will ask for the passphrase. It is recommended to do this procedure after the boot, because otherwise the boot process would be waiting for the passphrase input.

# geli attach -k /root/private0.key /dev/md0
Enter passphrase:
# mount /dev/md0.eli /private