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 considered 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 formidable 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 corresponding 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 contains 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 masterkey.

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

     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 complexity 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 chosen 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 (including 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 detonating 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 personal 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 algorithm 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 support 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
     intentionally 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 cryptographic strength of
     gbde.

     The payload is encrypted with AES in CBC mode using a 128 bit random single-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>