ZFS Crypto key hand off to kernel

ZFS Crypto key hand off to kernel

[Darren J Moffat]

I've been testing the ZFS Crypto support in GRUB2 with Solaris 11 and 
found it works great - many thanks!

The 'zfskey' command works very nicely, however the key is only 
available to grub and isn't handed off to the kernel that GRUB2 starts up.

I'm considering an extension to the multiboot2 spec to provide a 
mechanism to hand off the key from GRUB2 to the running kernel.

I would like for this not to be specific to the ZFS crypto support but 
to be usable for LUKS and other systems that allow for an encrypted 
root/boot where both GRUB2 and the kernel need the same key.

Is this something that would be of interest for GRUB2 ?  If so I'll look 
at developing the spec update and a patch for GRUB2 to support it for 
the zfs crypto support.

-- 
Darren J Moffat

Re: ZFS Crypto key hand off to kernel

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.01.2012 13:23, Darren J Moffat wrote:
> I've been testing the ZFS Crypto support in GRUB2 with Solaris 11 and 
> found it works great - many thanks!
>
> The 'zfskey' command works very nicely, however the key is only 
> available to grub and isn't handed off to the kernel that GRUB2 starts 
> up.
>
> I'm considering an extension to the multiboot2 spec to provide a 
> mechanism to hand off the key from GRUB2 to the running kernel.
>
> I would like for this not to be specific to the ZFS crypto support but 
> to be usable for LUKS and other systems that allow for an encrypted 
> root/boot where both GRUB2 and the kernel need the same key.
>
> Is this something that would be of interest for GRUB2 ?  If so I'll 
> look at developing the spec update and a patch for GRUB2 to support it 
> for the zfs crypto support.
>
That would be most welcome. The main issues are:
1) What to consider a key? IMHO it should be the master key, and not 
password or session key.
2) How to match keys to actual devices? I think it should be UUID for 
LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD.
3) GRUB may have some keys without knowing which pool/fs it's used for. 
They should be marked as such.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

Re: ZFS Crypto key hand off to kernel

[Darren J Moffat]

On 01/13/12 14:17, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Is this something that would be of interest for GRUB2 ? If so I'll
>> look at developing the spec update and a patch for GRUB2 to support it
>> for the zfs crypto support.
>>
> That would be most welcome. The main issues are:
> 1) What to consider a key? IMHO it should be the master key, and not
> password or session key.

Agreed, it is really helpful that GRUB2 has already done the PKCS#5 PBE 
transform in the case of a ZFS encrypted dataset. So there is no need to 
give the passphrase to the kernel when you can give the real key.

Also it wouldn't actually be useful in the case of ZFS encryption for 
GRUB2 to hand off the list of actual data encryption keys all we need is 
the key encryption key (aka master key, aka wrapping key).

> 2) How to match keys to actual devices? I think it should be UUID for
> LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD.

I need to brush up on LUKS it has been a while since I looked at it but 
that sounds correct to me.

For ZFS I think it might be enough to give the dataset name but I like 
the idea of passing the POOL GUID as well. If I had both I would 
certainly use them.

> 3) GRUB may have some keys without knowing which pool/fs it's used for.
> They should be marked as such.

I must be missing something here, how could that happen in the ZFS case? 
Or do you mean in general ?

-- 
Darren J Moffat

Re: ZFS Crypto key hand off to kernel

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.01.2012 15:27, Darren J Moffat wrote:
> On 01/13/12 14:17, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Is this something that would be of interest for GRUB2 ? If so I'll
>>> look at developing the spec update and a patch for GRUB2 to support it
>>> for the zfs crypto support.
>>>
>> That would be most welcome. The main issues are:
>> 1) What to consider a key? IMHO it should be the master key, and not
>> password or session key.
>
> Agreed, it is really helpful that GRUB2 has already done the PKCS#5 
> PBE transform in the case of a ZFS encrypted dataset. So there is no 
> need to give the passphrase to the kernel when you can give the real key.
>
> Also it wouldn't actually be useful in the case of ZFS encryption for 
> GRUB2 to hand off the list of actual data encryption keys all we need 
> is the key encryption key (aka master key, aka wrapping key).
>
>> 2) How to match keys to actual devices? I think it should be UUID for
>> LUKS and POOLUUID+FSNAME for ZFS, or perhaps just POOLUUD.
>
> I need to brush up on LUKS it has been a while since I looked at it 
> but that sounds correct to me.
>
> For ZFS I think it might be enough to give the dataset name but I like 
> the idea of passing the POOL GUID as well. If I had both I would 
> certainly use them.
>
>> 3) GRUB may have some keys without knowing which pool/fs it's used for.
>> They should be marked as such.
>
> I must be missing something here, how could that happen in the ZFS 
> case? Or do you mean in general ?
>
I mean exactly the ZFS case. zfskey only stores the password and files 
in a special place and on an attempt to read encrypted data, the real 
key is decoded. IF no such attempt has been made, they key won't be 
decoded and GRUB won't know what it's for.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko