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
GBDE(4)		       FreeBSD Kernel Interfaces Manual		       GBDE(4)

NAME
     gbde -- Geom Based	Disk Encryption

SYNOPSIS
     options GEOM_BDE

DESCRIPTION
     NOTICE: Please be aware that this code has	not yet	received much review
     and analysis by qualified cryptographers and therefore should be consid-
     ered a slightly suspect experimental facility.

     We	cannot at this point guarantee that the	on-disk	format will not	change
     in	response to reviews or bug-fixes, so potential users are advised to be
     prepared that dump(8)/restore(8) based migrations may be called for in
     the future.

     The objective of this facility is to provide a high degree	of denial of
     access to the contents of a ``cold'' storage device.

     Be	aware that if the computer is compromised while	up and running and the
     storage device is actively	attached and opened with a valid pass-phrase,
     this facility offers no protection	or denial of access to the contents of
     the storage device.

     If, on the	other hand, the	device is ``cold'', it should present a	formi-
     dable challenge for an attacker to	gain access to the contents in the
     absence of	a valid	pass-phrase.

     Four cryptographic	barriers must be passed	to gain	access to the data,
     and only a	valid pass-phrase will yield this access.

     When the pass-phrase is entered, it is hashed with	SHA2 into a 512	bit
     ``key-material''.	This is	a way of producing cryptographic usable	keys
     from a typically all-ASCII	pass-phrase of an unpredictable	user-selected
     length.

   First barrier: the location of the "lock-sector".
     During initialization, up to four independent but mutually	aware ``lock''
     sectors are written to the	device in randomly chosen locations.  These
     lock-sectors contain the 2048 random bit master-key and a number of
     parameters	of the layout geometry (more on	this later).  Since the	entire
     device will contain isotropic data, there is no short-cut to rapidly
     determine which sequence of bytes contain a lock-sector.

     To	locate a lock-sector, a	small piece of data called the ``metadata''
     and the key-material must be available.  The key-material decrypts	the
     metadata, which contains the byte offset on the device where the corre-
     sponding lock-sector is located.  If the metadata is lost or unavailable
     but the key-material is at	hand, it would be feasible to do a brute force
     scan where	each byte offset of the	device is checked to see if it con-
     tains the lock-sector data.

   Second barrier: decryption of the master-key	using key-material.
     The lock-sector contains an encrypted copy	of an architecture neutral
     byte-sequence which encodes the fields of the lock-structure.  The	order
     in	which these fields are encoded is determined from the key-material.
     The encoded byte stream is	encrypted with 256bit AES in CBC mode.

   Third barrier: decryption of	the sector key.
     For each sector, an MD5 hash over a ``salt'' from the lock-sector and the
     sector number is used to ``cherry-pick'' a	subset of the master key,
     which hashed together with	the sector offset through MD5 produces the
     ``kkey'', the key which encrypts the sector key.

   Fourth barrier: decryption of the sector data.
     The actual	payload	of the sector is encrypted with	128 bit	AES in CBC
     mode using	a single-use random bits key.

   Examining the reverse path
     Assuming an attacker knows	an amount of plaintext and has managed to
     locate the	corresponding encrypted	sectors	on the device, gaining access
     to	the plaintext context of other sectors is a daunting task:

     First he will have	to derive from the encrypted sector and	the known
     plain text	the sector key(s) used.	 At the	time of	writing, it has	been
     speculated	that it	could maybe be possible	to break open AES in only 2^80
     operations; even so, that is still	a very impossible task.

     Armed with	one or more sector keys, our patient attacker will then	go
     through essentially the same exercise, using the sector key and the
     encrypted sector key to find the key used to encrypt the sector key.

     Armed with	one or more of these ``kkeys'',	our attacker has to run	them
     backwards through MD5.  Even though he knows that the input to MD5	was 24
     bytes and has the value of	8 of these bytes from the sector number, he is
     still faced with 2^128 equally likely possibilities.

     Having successfully done that, our	attacker has successfully discovered
     up	to 16 bytes of the master-key, but is still unaware which 16 bytes,
     and in which other	sectors	any of these known bytes contribute to the
     kkey.

     To	unravel	the last bit, the attacker has to guess	the 16 byte random-
     bits salt stored in the lock-sector to recover the	indexes	into the mas-
     terkey.

     Any attacker with access to the necessary machine power to	even attempt
     this attack will be better	off attempting to brute-force the pass-phrase.

   Positive denial facilities
     Considering the infeasibility of the above	attack,	gaining	access to the
     pass-phrase will be of paramount importance for an	attacker, and a	number
     of	scenarios can be imagined where	undue pressure will be applied to an
     individual	to divulge the pass-phrase.

     A ``Blackening'' feature provides a way for the user, given a moment of
     opportunity, to destroy the master-key in such a way that the pass-phrase
     will be acknowledged as good but access to	the data will still be denied.

   A practical analogy
     For persons who think cryptography	is only	slightly more interesting than
     watching silicon sublimate	the author humbly offers this analogy to the
     keying scheme for a protected device:

     Imagine an	installation with a vault with walls of	several	hundred	meters
     thick solid steel.	 This vault can	only be	feasibly accessed using	the
     single key, which has a complexity	comparable to a	number with 600	dig-
     its.

     This key exists in	four copies, each of which is stored in	one of four
     small safes, each of which	can be opened with unique key which has	a com-
     plexity comparable	to an 80 digit number.

     In	addition to the	masterkey, each	of the four safes also contains	the
     exact locations of	all four key-safes which are located in	randomly cho-
     sen places	on the outside surface of the vault where they are practically
     impossible	to detect when they are	closed.

     Finally, each safe	contains four switches which are wired to a bar	of
     dynamite inside each of the four safes.

     In	addition to this, a keyholder after opening his	key-safe is also able
     to	install	a copy of the master-key and re-key any	of key-safes (includ-
     ing his own).

     In	normal use, the	user will open the safe	for which he has the key, take
     out the master-key	and access the vault.  When done, he will lock up the
     master-key	in the safe again.

     If	a keyholder-X for some reason distrusts	keyholder-Y, she has the
     option of opening her own safe, flipping one of the switches and detonat-
     ing the bar of dynamite in	safe-Y.	 This will obliterate the master-key
     in	that safe and thereby deny keyholder-Y access to the vault.

     Should the	facility come under attack, any	of the keyholders can detonate
     all four bars of dynamite and thereby make	sure that access to the	vault
     is	denied to everybody, keyholders	and attackers alike.  Should the
     facility fall to the enemy, and a keyholder be forced to apply his	per-
     sonal key,	he can do so in	confidence that	the contents of	his safe will
     not yield access to the vault, and	the enemy will hopefully realize that
     applying further pressure on the personnel	will not give access to	the
     vault.

     The final point to	make here is that it is	perfectly possible to make a
     detached copy of any one of these keys, including the master key, and
     deposit or	hide it	as one sees fit.

   Steganography support
     When the device is	initialized, it	is possible to restrict	the encrypted
     data to a single contiguous area of the device.  If configured with care,
     this area could masquerade	as some	sort of	valid data or as random	trash
     left behind by the	systems	operation.

     This can be used to offer a plausible deniability of existence, where it
     will be impossible	to prove that this specific area of the	device is in
     fact used to store	encrypted data and not just random junk.

     The main obstacle in this is that the output from any encryption algo-
     rithm worth its salt is so	totally	random looking that it stands out like
     a sore thumb amongst practically any other	sort of	data which contains at
     least some	kind of	structure or identifying byte sequences.

     Certain file formats like ELF contain multiple distinct sections, and it
     would be possible to locate things	just right in such a way that a	device
     contains a	partition with a file system with a large executable, (``a
     backup copy of my kernel'') where a non-loaded ELF	section	is laid	out
     consecutively on the device and thereby could be used to contain a	gbde
     encrypted device.

     Apart from	the ability to instruct	gbde which those sectors are, no sup-
     port is provided for creating such	a setup.

   Deployment suggestions
     For personal use, it may be wise to make a	backup copy of the masterkey
     or	use one	of the four keys as a backup.  Fitting protection of this key
     is	up to yourself,	your local circumstances and your imagination.

     For company or institutional use, it is strongly advised to make a	copy
     of	the master-key and put it under	whatever protection you	have at	your
     means.  If	you fail to do this, a disgruntled employee can	deny you
     access to the data	``by accident''.  (The employee	can still intention-
     ally deny access by applying another encryption scheme to the data, but
     that problem has no technical solution.)

   Cryptographic strength
     This section lists	the specific components	which contribute to the	cryp-
     tographic strength	of gbde.

     The payload is encrypted with AES in CBC mode using a 128 bit random sin-
     gle-use key (``the	skey'').  AES is well documented.

     No	IV is used in the encryption of	the sectors, the assumption being that
     since the key is random bits and single-use, an IV	adds nothing to	the
     security of AES.

     The random	key is produced	with arc4rand(9) which is believed to do a
     respectable job at	producing unpredictable	bytes.

     The skey is stored	on the device in a location which can be derived from
     the location of the encrypted payload data.  The stored copy is encrypted
     with AES in CBC mode using	a 128 bit key (``the kkey'') derived from a
     subset of the master key chosen by	the output of an MD5 hash over a 16
     byte random bit static salt and the sector	offset.	 Up to 6.25% of	the
     masterkey (16 bytes out of	2048 bits) will	be selected and	hashed through
     MD5 with the sector offset	to generate the	kkey.

     Up	to four	copies of the master-key and associated	geometry information
     is	stored on the device in	static randomly	chosen sectors.	 The exact
     location inside the sector	is randomly chosen.  The order in which	the
     fields are	encoded	depends	on the key-material.  The encoded byte-stream
     is	encrypted with AES in CBC mode using 256 bit key-material.

     The key-material is derived from the user-entered pass-phrase using 512
     bit SHA2.

     No	chain is stronger than its weakest link, which usually is poor pass-
     phrases.

SEE ALSO
     gbde(8)

HISTORY
     This software was developed for the FreeBSD Project by Poul-Henning Kamp
     and NAI Labs, the Security	Research Division of Network Associates, Inc.
     under DARPA/SPAWAR	contract N66001-01-C-8035 (``CBOSS''), as part of the
     DARPA CHATS research program.

AUTHORS
     Poul-Henning Kamp <phk@FreeBSD.org>

FreeBSD	10.1		       October 19, 2002			  FreeBSD 10.1

NAME | SYNOPSIS | DESCRIPTION | SEE ALSO | HISTORY | AUTHORS

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

home | help