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

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

Hello everyone,

I was looking for a way to access a GELI encrypted disk from within
Linux (for forensics of disks used in FreeBSD, but people wanting to
access encrypted FreeNAS data from OpenMediaVault could benefit as well)
and found this email. Did the code for GEOM_ELI encryption support in
cryptsetup/dm-crypt ever get written? If not, I might have a go at it.

Admittedly the only part I'm interested right now is the unauthenticated
aes-xts with the bytecount64 IV because that is apparently the most
commonly used variant.


On Fri Dec 13 07:42:52 CET 2013, f000m at z1p.biz wrote:
> --- Ursprüngliche Nachricht ---
> Von: Milan Broz <gmazyland at gmail.com>
> Datum: 30.11.2013 18:33:02
> An: f000m at z1p.biz
> Betreff: Re: [dm-crypt] GEOM_ELI support in dm-crypt/cryptsetup
> 
>> On 11/30/2013 04:25 PM, f000m at z1p.biz wrote:
>> > I am planing to make dm-crypt and cryptsetup able to
>> > handle FreeBSD's GEOM_ELI crypted devices (without its
>> > integrity stuff).
>>
>> I think that even integrity stuff would be interesting
>> but that's a lot of kernel work.
>> (But I am quite interested how FreeBSD approach looks like anyway.)
>>
> The first comment in the header file explains how it works.
> http://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli_integrity.c?view=co
> 
>> > In the kernel modul there would be minor changes
>> > concerning two more IV generators needed to add:
>> > First, because of a slightly different handling of plain type
>> > (it uses offsets instead of sectors).
>> > Second, GEOM_ELI uses CBC with unpredictable IV instead of
>> > ESSIV Mode.
>>
>> Not sure I understand offset/sectors problem.
>> Can you elaborate more here? Is it just multiplication
>> of sector number by sector size or something else?
>> (Or just point me to the docs :)
>>
> Yes it is for plain mode. You can see it in g_eli_crypto_ivgen().
> http://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?view=co
> 
> The unpredicable IV generation creates a SHA256 digest. It uses a IV seed
> and the offset number (sector number by sector size).
> 
> Also it would need to add a routine to calculate (HMAC-SHA-512) the
> encryption key on the fly because GEOM_ELI uses multiple encryption keys
> since version 5. It uses a different key for every 2^20 sectors.
> So I would put it in the IV generators, too.
> 
>> Anyway, adding new IV generators to dmcrypt should not be big problem
>> (in principle).
>>
>> > Additionally cryptsetup must be patched to be able
>> > to deal with the metadata structure of GEOM_ELI devices.
>> >
>> > Would there be any interests in committing me this code
>> > to the upstream?
>>
>> Well, I am not sure how broadly this format is used and if
>> there are potential users in Linux world, so if you can
>> post more description here it would be nice.
>>
> It is a common tool in FreeBSD for cryptography. So it would be
> nice one could access these FreeBSD devices with Linux, too (I think =).
> 
>> (And if anyone on list is interested, plesase say so... now :)
>>
>> But in general, yes, I think it is good idea.
>>
>> I would suggest you to do these steps:
>>
>> 1) provide links to documentation of format, limitation
>> of your approach etc (also should be included in patch later)
>>
>> 2) first, implement needed changes in Linux kernel (dmcrypt IVs)
>> (if it is only new IV, it should be straightforward)
>> Please post patches to DM devel list (dm-devel at redhat.com)
>>
>> This should be done in advance - for testing, you can use
>> dmsetup to configure dmcrypt device and test it works for your
>> images.
>>
>> Cryptsetup support can come later (we need patch in stable kernel
>> first to release build supporting it).
>>
>> 3) second, post patches for cryptsetup to this list.
>>
>> Please keep format specific code in separate directory,
>> lib/geli/* or so.
>> (I am planning some unified interface for formats in future (1.7),
>> so see how is e.g. TCRYPT done - it should be very similar).
>>
>> Please post at least simple regression tests together with patches
>> (see tests/ dir).
>>
>> License of new code must be compatible with released code,
>> basically GPL2+/LGPL2.1+ for cryptsetup.
>>
>> (And be prepared it will take some time and perhaps reiterated
>> patch posts - mainly for kernel part :)
>>
>> Thanks,
>> Milan
>>
> Thanks for your suggestions.
> 
> Best regards.

Regards,
Carl-Daniel