FreeBSD Man Pages

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 an for-
     midable 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 bytestream is encrypted with 256bit AES in CBC mode.
     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 sectorkey.

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

     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 5.4		       October 19, 2002 		   FreeBSD 5.4

SPONSORED LINKS