home | help
GELI(8) 		     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 following
     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:

	   *   Utilizes  the  crypto(9) framework, so when there is crypto hard-
	       ware 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 verifica-
	       tion)  utilizing  one  of  the  following  algorithms:  HMAC/MD5,
	       HMAC/SHA1,    HMAC/RIPEMD160,	HMAC/SHA256,	HMAC/SHA384   or
	       HMAC/SHA512.
	   *   Can create a key  from  a  couple  of  components  (user  entered
	       passphrase, random bits from a file, etc.).
	   *   Allows to encrypt the root partition - the user will be asked for
	       the passphrase before the root file system is mounted.
	   *   The passphrase of the user is strengthened with: B. Kaliski, PKCS
	       #5: Password-Based Cryptography Specification, Version 2.0., RFC,
	       2898.
	   *   Allows to use two independent keys (e.g.  "user key" and "company
	       key").
	   *   It is fast - geli performs simple sector-to-sector encryption.
	   *   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.
	   *   Providers can be configured to automatically detach on last close
	       (so  users  do not have to remember to detach providers after un-
	       mounting the file systems).
	   *   Allows to attach a provider with a random, one-time key -  useful
	       for swap partitions and temporary file systems.
	   *   Allows to verify data integrity (data authentication).
	   *   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 sub-
		command    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  (authentica-
				tion)  using the given algorithm.  This will re-
				duce size of available storage and  also  reduce
				speed.	 For example, when using 4096 bytes sec-
				tor and HMAC/SHA256 algorithm, 89% of the origi-
				nal 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		Ask  for the passphrase on 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.

		-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 spec-
				ified 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  multi-
				ple 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.   In-
				creasing  sector size allows to increase perfor-
				mance, 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 us-
		ing 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  sys-
			     tem.   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 sub-
			     command.

		-j passfile  Specifies a file which contains the  passphrase  or
			     its part.	For more information see the description
			     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 auto-
		    matically detached (even if it was only opened for reading).

     onetime	Attach the given providers with random, one-time keys.	The com-
		mand  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 description
			       of the init subcommand.

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

		-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 information, see the
			       description of the attach subcommand.

		-l keylen      Key length to use with  the  given  cryptographic
			       algorithm.   For  more  information,  see the de-
			       scription 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 informa-
		    tion, 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 initial-
		ized.  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 subcommand, 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 de-
				crypted  with  the  passphrase/keyfile	will  be
				changed.

		-p		Do not use passphrase as the old key component.

		-P		Do not use passphrase as the new key component.

     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  de-
			  stroy 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 de-
			  tached (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 com-
		mand  -  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 de-
		tached.

		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 differ-
		    ent 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  kernel
		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  closing  all
		files and directories opened from a file system placed on an en-
		crypted device, unmounting the file system and detaching the de-
		vice, the suspend subcommand can be used.  Any access to the en-
		crypted  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 de-
		vices  created	with  the  onetime subcommand.	Please note that
		sensitive data might still be present in memory 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 description
			     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 be-
	     tween 0 and 3 inclusive.  If set to 0, minimal debug information is
	     printed.  If set to 3, the maximum amount of debug  information  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 ex-
	     posed   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 software
	     cryptography.   Its  purpose is to increase performance on SMP sys-
	     tems.  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.  At-
     tach the provider, create a file system and mount it.  Do	the  work.   Un-
     mount 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 at-
     tached 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 keyfile:

	   # 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  re-
     stored.  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 up-
     date 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 overwrite 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  or-
     der  to  make  sure  that all sectors and their corresponding checksums are
     properly initialized into a consistent state.

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  ci-
     pher is implemented by Yoshisato Yanagisawa in FreeBSD 7.0.

AUTHORS
     Pawel Jakub Dawidek <pjd@FreeBSD.org>

FreeBSD 9.0			  March 9, 2011 			 GELI(8)

home | help