Re: [dm-crypt] GEOM_ELI support in dm-crypt/cryptsetup

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

On 05.01.2017 09:53, Carl-Daniel Hailfinger wrote:
> On 01.01.2017 23:23, Milan Broz wrote:
>> On 12/30/2016 07:31 AM, Carl-Daniel Hailfinger wrote:
>>> Followup to myself:
>>>
>>> A patch for cryptsetup follows. It does not talk to the kernel interface
>>> yet, but it can decode v7 of the GELI header.
>>> Keyfile support is next to decrypt the encrypted metadata in the header.
>> I think we can implement it as just another supported on-disk format but
>> it will need some testing images and full integration in libcryptsetup
>> (similar to TrueCrypt/VeraCrypt formats).
> I'm using the TrueCrypt/VeraCrypt code in libcryptsetup as template for
> the GELI code.
>
>
>> I can do that myself but I would like to have full documentation and/or
>> implementation of parsing of GELI on-disk format.
> That's actually a problem. The available documentation about the on-disk
> format is essentially just the FreeBSD code, and various bits and pieces
> scattered all over the net.
>
> GELI code in FreeBSD:
> https://svnweb.freebsd.org/base/head/sys/geom/eli/
>
> Example GPLv3 code in GRUB (for password-based containers only):
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/geli.c
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk/cryptodisk.c
>
> Example GPLv3 code as a NBD implementation:
> https://github.com/jepler/ungeli
>
> Bits and pieces of documentation (not all of them refer to the current
> version of GELI):
> https://www.freebsd.org/cgi/man.cgi?geli(8)
> https://www.freebsd.org/doc/handbook/disks-encrypting.html
> https://lists.freebsd.org/pipermail/freebsd-geom/2012-June/005284.html
> http://www.derkeiler.com/Newsgroups/sci.crypt/2005-07/0959.html
>
> The way keys are generated, stored and used is not entirely
> straightforward. The various pieces of documentation and analysis
> contradict each other and I have not verified which one is correct, so
> please take this with a large heap of salt, it might be totally bogus:
> For some cases, a 64-byte key file (generated from random data) is
> hashed with SHA512, the last 256 bits of the hash are thrown away, and
> the remaining 256 bits are divided into an IV key and an AES-128 key.
> For older versions of GELI, the IV key is used for AES encryption as
> well (a bug which was corrected in newer versions of GELI). The metadata
> has two key store slots. Each slot hosts an encrypted version of the
> master key (which itself is divided into IV key and encryption "data"
> key) and the SHA512 hash of the master key. The "data" key part of the
> master key is not directly used for AES-XTS encryption, but there are
> more derivation mechanisms in there which are relevant for storage media
> larger than 2^20 blocks.

Please note that SHA512 is always used as HMAC-SHA512 with zero key.


> A quick note about the on-disk format: Ciphertext starts directly at the
> beginning of the container. The metadata is stored in the last 512-byte
> sector of the container. Soft sectors are usually 4096 bytes, optionally
> amended with a 512-byte authentication data sector per 4096-byte soft
> sector. AFAIK no third-party code supports authentication data.
>
>
>> And it will take some time (maybe create issue for it in project tracker).
> I noticed that I had forgotten to attach the current state of the
> implementation. I think patch 3 compiles and does something useful,
> patch 4 is the current state (and probably doesn't compile). The code is
> full of #if 0 and similar crud, and you can see it's just messing with
> the TCRYPT code to replace some of the code with GELI code. The code
> does NOT reflect my coding standards, it's just a crufty hack while I
> was figuring out how to add code to cryptsetup.
>
> What the code does right now is parse a container and output the
> encrypted keyslots as well as check the MD5 checksum of the metadata.
>
>
>> Anyway, thanks for working on this!
> You're welcome. I hope to revisit this in a few weeks when I have more time.

Regards,
Carl-Daniel