Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
GELI(8)			FreeBSD	System Manager's Manual		       GELI(8)

NAME
     geli -- control utility for cryptographic GEOM class

SYNOPSIS
     To	compile	GEOM_ELI into your kernel, place the following lines in	your
     kernel configuration file:

	   device crypto
	   options GEOM_ELI

     Alternately, to load the GEOM_ELI module at boot time, place the follow-
     ing line in your loader.conf(5):

	   geom_eli_load="YES"

     Usage of the geli(8) utility:

     geli init [-bPv] [-a aalgo] [-B backupfile] [-e ealgo] [-i	iterations]
	   [-J newpassfile] [-K	newkeyfile] [-l	keylen]	[-s sectorsize]	prov
     geli label	- an alias for init
     geli attach [-dprv] [-j passfile] [-k keyfile] prov
     geli detach [-fl] prov ...
     geli stop - an alias for detach
     geli onetime [-d] [-a aalgo] [-e ealgo] [-l keylen] [-s sectorsize] prov
     geli configure [-bB] 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 clear	[-v] prov ...
     geli dump [-v] prov ...
     geli list
     geli status
     geli load
     geli unload

DESCRIPTION
     The geli utility is used to configure encryption on GEOM providers.

     The following is a	list of	the most important features:

	   +o   Utilizes	the crypto(9) framework, so when there is crypto hard-
	       ware available, geli will make use of it	automatically.
	   +o   Supports	many cryptographic algorithms (currently AES-XTS,
	       AES-CBC,	Blowfish-CBC, Camellia-CBC and 3DES-CBC).
	   +o   Can optionally perform data authentication (integrity verifica-
	       tion) utilizing one of the following algorithms:	HMAC/MD5,
	       HMAC/SHA1, HMAC/RIPEMD160, HMAC/SHA256, HMAC/SHA384 or
	       HMAC/SHA512.
	   +o   Can create a key	from a couple of components (user entered
	       passphrase, random bits from a file, etc.).
	   +o   Allows to encrypt the root partition - the user will be asked
	       for the passphrase before the root file system is mounted.
	   +o   The passphrase of the user is strengthened with:	B. Kaliski,
	       PKCS #5:	Password-Based Cryptography Specification, Version
	       2.0., RFC, 2898.
	   +o   Allows to use two independent keys (e.g.	 "user key" and
	       "company	key").
	   +o   It is fast - geli performs simple sector-to-sector encryption.
	   +o   Allows to backup/restore	Master Keys, so	when a user has	to
	       quickly destroy his keys, it is possible	to get the data	back
	       by restoring keys from the backup.
	   +o   Providers can be	configured to automatically detach on last
	       close (so users do not have to remember to detach providers
	       after unmounting	the file systems).
	   +o   Allows to attach	a provider with	a random, one-time key - use-
	       ful for swap partitions and temporary file systems.
	   +o   Allows to verify	data integrity (data authentication).
	   +o   Allows to suspend and resume encrypted devices.

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

     init	Initialize provider which needs	to be encrypted.  Here you can
		set up the cryptographic algorithm to use, key length, etc.
		The last provider's sector is used to store metadata.  The
		init subcommand	also automatically backups metadata in
		/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 (authenti-
				cation)	using the given	algorithm.  This will
				reduce size of available storage and also
				reduce speed.  For example, when using 4096
				bytes sector and HMAC/SHA256 algorithm,	89% of
				the original provider storage will be avail-
				able 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 recom-
				mended algorithm is HMAC/SHA256.

		-b		Ask for	the passphrase on boot,	before the
				root partition is mounted.  This makes it pos-
				sible 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.

		-e ealgo	Encryption algorithm to	use.  Currently	sup-
				ported algorithms are: AES-XTS,	AES-CBC,
				Blowfish-CBC, Camellia-CBC and 3DES-CBC.  The
				default	and recommended	algorithm is AES-XTS.

		-i iterations	Number of iterations to	use with PKCS#5v2.  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.

		-J newpassfile	Specifies a file which contains	the passphrase
				or its part.  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.

		-K newkeyfile	Specifies a file which contains	part of	the
				key.  If newkeyfile is given as	-, standard
				input will be used.  This argument can be
				specified multiple times.

		-l keylen	Key length to use with the given cryptographic
				algorithm.  If not given, the default key
				length for the given algorithm is used,	which
				is: 128	for AES-XTS, AES-CBC, Blowfish-CBC and
				Camellia-CBC and 192 for 3DES-CBC.

		-P		Do not use passphrase as the key component.

		-s sectorsize	Change decrypted provider's sector size.
				Increasing sector size allows to increase per-
				formance, because we need to generate an IV
				and do encrypt/decrypt for every single	sector
				- less number of sectors means less work to
				do.

     attach	Attach the given provider.  The	master key will	be decrypted
		using the given	passphrase/keyfile and a new GEOM provider
		will be	created	using the given	provider's name	with an	".eli"
		suffix.

		Additional options include:

		-d	     If	specified, a decrypted provider	will be
			     detached automatically on last close.  This can
			     help with short memory - user does	not have to
			     remember to detach	the provider after unmounting
			     the file system.  It only works when the provider
			     was opened	for writing, so	it will	not work if
			     the file system on	the provider is	mounted	read-
			     only.  Probably a better choice is	the -l option
			     for the detach subcommand.

		-j passfile  Specifies a file which contains the passphrase or
			     its part.	For more information see the descrip-
			     tion of the -J option for the init	subcommand.

		-k keyfile   Specifies a file which contains part of the key.
			     For more information see the description of the
			     -K	option for the init subcommand.

		-p	     Do	not use	passphrase as the key component.

		-r	     Attach read-only provider.	 It will not be	opened
			     for writing.

     detach	Detach the given providers, which means	remove the devfs entry
		and clear the keys from	memory.

		Additional options include:

		-f  Force detach - detach even if the provider is open.

		-l  Mark provider to detach on last close.  If this option is
		    specified, the provider will not be	detached until it is
		    open, but when it will be closed last time,	it will	be
		    automatically detached (even if it was only	opened for
		    reading).

     onetime	Attach the given providers with	random,	one-time keys.	The
		command	can be used to encrypt swap partitions or temporary
		file systems.

		Additional options include:

		-a aalgo       Enable data integrity verification (authentica-
			       tion).  For more	information, see the descrip-
			       tion of the init	subcommand.

		-e ealgo       Encryption algorithm to use.  For more informa-
			       tion, see the description of the	init subcom-
			       mand.

		-d	       Detach on last close.  Note, the	option is not
			       usable for temporary file systems as the
			       provider	will be	detached after creating	the
			       file system on it.  It still can	(and should
			       be) used	for swap partitions.  For more infor-
			       mation, see the description of the attach sub-
			       command.

		-l keylen      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.

     configure	Change configuration of	the given providers.

		Additional options include:

		-b  Set	the BOOT flag on the given providers.  For more	infor-
		    mation, see	the description	of the init subcommand.

		-B  Remove the BOOT flag from the given	providers.

     setkey	Change or setup	(if not	yet initialized) selected key.	There
		is one master key, which can be	encrypted with two independent
		user keys.  With the init subcommand, only key number 0	is
		initialized.  The key can always be changed: 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
		old 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 setkey subcom-
				mand, only one key have	to be defined and this
				key has	to be changed.

		-j passfile	Specifies a file which contains	the old
				passphrase or its part.

		-J newpassfile	Specifies a file which contains	the new
				passphrase or its part.

		-k keyfile	Specifies a file which contains	part of	the
				old key.

		-K newkeyfile	Specifies a file which contains	part of	the
				new key.

		-n keyno	Specifies the number of	the key	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 key decrypted with	the
				passphrase/keyfile will	be changed.

		-p		Do not use passphrase as the old key compo-
				nent.

		-P		Do not use passphrase as the new key compo-
				nent.

     delkey	Destroy	(overwrite with	random data) the selected key.	If one
		is destroying keys for an attached provider, the provider will
		not be detached	even if	all keys will be destroyed.  It	can be
		even rescued with the setkey subcommand.

		Additional options include:

		-a	  Destroy all keys (does not need -f option).

		-f	  Force	key destruction.  This option is needed	to
			  destroy the last key.

		-n keyno  Specifies the	key number.  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 in emergency situations.  It will
		destroy	all keys on the	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 dif-
		    ferent 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 request to finish,
		clearing all sensitive informations (like keys)	from the ker-
		nel memory and blocking	all further I/O	requests until the
		resume subcommand is executed.	This functionality is useful
		for eg.	laptops	- when one wants to suspend a laptop, one does
		not want to leave encrypted device attached.  Instead of clos-
		ing all	files and directories opened from a file system	placed
		on an encrypted	device,	unmounting the file system and detach-
		ing the	device,	the suspend subcommand can be used.  Any
		access to the encrypted	device will be blocked until the keys
		are recovered through 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 mem-
		ory after suspending encrypted device, because of file system
		cache, etc.

		Additional options include:

		-a  Suspend all	geli devices.

     resume	Resume previously suspended device.  The caller	must ensure
		that executing this subcommand won't try to access suspended
		device,	which will lead	to a deadlock.	For example suspending
		device,	which contains file system where the geli utility is
		stored is bad idea.

		Additional options include:

		-j passfile  Specifies a file which contains the passphrase or
			     its part.	For more information see the descrip-
			     tion of the -J option for the init	subcommand.

		-k keyfile   Specifies a file which contains part of the key.
			     For more information see the description of the
			     -K	option for the init subcommand.

		-p	     Do	not use	passphrase as the key component.

     resize	Inform geli that the provider has been resized.	 The old meta-
		data 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.

     clear	Clear metadata from the	given providers.

     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.

SYSCTL VARIABLES
     The following sysctl(8) variables can be used to control the behavior of
     the ELI GEOM class.  The default value is shown next to each variable.
     Some variables can	also be	set in /boot/loader.conf.

     kern.geom.eli.version
	     Version number of the ELI GEOM class.

     kern.geom.eli.debug: 0
	     Debug level of the	ELI GEOM class.	 This can be set to a number
	     between 0 and 3 inclusive.	 If set	to 0, minimal debug informa-
	     tion is printed.  If set to 3, the	maximum	amount of debug	infor-
	     mation is printed.

     kern.geom.eli.tries: 3
	     Number of times a user is asked for the passphrase.  This is only
	     used for providers	which should be	attached on boot (before the
	     root file system is mounted).  If set to 0, attaching providers
	     on	boot will be disabled.	This variable should be	set in
	     /boot/loader.conf.

     kern.geom.eli.overwrites: 5
	     Specifies how many	times the Master-Key will be overwritten with
	     random values when	it is destroyed.  After	this operation it is
	     filled with zeros.

     kern.geom.eli.visible_passphrase: 0
	     If	set to 1, the passphrase entered on boot (before the root file
	     system is mounted)	will be	visible.  This possibility should be
	     used with caution as the entered passphrase can be	logged and
	     exposed via dmesg(8).  This variable should be set	in
	     /boot/loader.conf.

     kern.geom.eli.threads: 0
	     Specifies how many	kernel threads should be used for doing	soft-
	     ware cryptography.	 Its purpose is	to increase performance	on SMP
	     systems.  If hardware acceleration	is available, only one thread
	     will be started.  If set to 0, CPU-bound thread will be started
	     for every active CPU.

     kern.geom.eli.batch: 0
	     When set to 1, can	speed-up crypto	operations by using batching.
	     Batching allows to	reduce number of interrupts by responding on a
	     group of crypto requests with one interrupt.  The crypto card and
	     the driver	has to support this feature.

     kern.geom.eli.key_cache_limit: 8192
	     Specifies how many	encryption keys	to cache.  The default limit
	     (8192 keys) will allow to cache all keys for 4TB provider with
	     512 bytes sectors and will	take around 1MB	of memory.

     kern.geom.eli.key_cache_hits
	     Reports how many times we were looking up a key and it was
	     already in	cache.	This sysctl is not updated for providers that
	     need less keys than the limit specified in
	     kern.geom.eli.key_cache_limit.

     kern.geom.eli.key_cache_misses
	     Reports how many times we were looking up a key and it was	not in
	     cache.  This sysctl is not	updated	for providers that need	less
	     keys than the limit specified in kern.geom.eli.key_cache_limit.

EXIT STATUS
     Exit status is 0 on success, and 1	if the command fails.

EXAMPLES
     Initialize	a provider which is going to be	encrypted with a passphrase
     and random	data from a file on the	user's pen drive.  Use 4kB sector
     size.  Attach the provider, create	a file system and mount	it.  Do	the
     work.  Unmount the	provider and detach it:

	   # 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
	   ...
	   # umount /mnt/secret
	   # geli detach da2.eli

     Create an encrypted provider, but use two keys: one for your employee and
     one for you as company's security officer (so there is no tragedy if the
     employee "accidentally" forgets his passphrase):

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

     You are the security-person in your company.  Create an encrypted
     provider for use by the user, but remember	that users forget their
     passphrases, so back Master Key up	with your own random key:

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

     Encrypted swap partition setup:

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

     The example below shows how to configure two providers which will be
     attached on boot (before the root file system is mounted).	 One of	them
     is	using passphrase and three keyfiles and	the other is using only	a key-
     file:

	   # 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

     The providers are initialized, now	we have	to add those lines to
     /boot/loader.conf:

	   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"

     Not only configure	encryption, but	also data integrity verification using
     HMAC/SHA256.

	   # 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 backups metadata by default to the /var/backups/_prov_.eli file.  If
     metadata is lost in any way (eg. by accidental overwrite),	it can be
     restored.	Consider the following situation:

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

     If	an encrypted filesystem	is extended, it	is necessary to	relocate and
     update the	metadata:

	   # 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

     Initialize	provider with passphrase split into two	files.	The provider
     can be attached by	giving those two files or by giving ``foobar''
     passphrase	on geli	prompt:

	   # 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

     Suspend all geli devices, suspend a laptop, then resume devices one by
     one after resuming	a laptop:

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

ENCRYPTION MODES
     geli supports two encryption modes: XTS, which was	standardized as	IEE
     P1619 and CBC with	unpredictable IV.  The CBC mode	used by	geli is	very
     similar to	the mode ESSIV.

DATA AUTHENTICATION
     geli can verify data integrity when an authentication algorithm is	speci-
     fied.  When data corruption/modification is detected, geli	will not
     return any	data, but instead will return an error (EINVAL).  The offset
     and size of the corrupted data will be printed on the console.  It	is
     important to know against which attacks geli provides protection for your
     data.  If data is modified	in-place or copied from	one place on the disk
     to	another	even without modification, geli	should be able to detect such
     a change.	If an attacker can remember the	encrypted data,	he can over-
     write any future changes with the data he owns without notice.  In	other
     words geli	will not protect your data against replay attacks.

     It	is recommended to write	the whole provider before the first use, in
     order to make sure	that all sectors and their corresponding checksums are
     properly initialized into a consistent state.  One	can safely ignore data
     authentication errors that	occur immediately after	the first time a
     provider is attached and before it	is initialized in this way.

SEE ALSO
     crypto(4),	gbde(4), geom(4), loader.conf(5), gbde(8), geom(8), crypto(9)

HISTORY
     The geli utility appeared in FreeBSD 6.0.	Support	for Camellia block
     cipher is implemented by Yoshisato	Yanagisawa in FreeBSD 7.0.

AUTHORS
     Pawel Jakub Dawidek <pjd@FreeBSD.org>

FreeBSD	10.1			 March 9, 2011			  FreeBSD 10.1

NAME | SYNOPSIS | DESCRIPTION | SYSCTL VARIABLES | EXIT STATUS | EXAMPLES | ENCRYPTION MODES | DATA AUTHENTICATION | SEE ALSO | HISTORY | AUTHORS

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=geli&manpath=FreeBSD+9.2-RELEASE>

home | help