[dm-crypt] Kernel Keyring Service
gmazyland at gmail.com
Sun Dec 14 19:10:23 CET 2014
On 12/12/2014 05:23 PM, Ahmed, Safayet (GE Global Research) wrote:
> Is there a way to setup an encrypted partition with keys from the
> kernel key ring? The key-ring services support special keys called
> encrypted keys. These keys never exist outside kernel memory in an
> un-encrypted state. These encrypted keys are encrypted with other
> keys in the kernel keyring: user keys and trusted keys. Trusted keys
> are keys protected by a TPM SRK.
As Alasdair said, this was discussed long time ago but never realized.
(Please do not forget that main FDE threat model is covering
offline system only and there are a lot of other attack vectors.
If we allow attacker tampering with hw or access the system on
administrator level nothing will help here.)
But what storing key in keyring solves now? There are still issues
1) Key is still "open" in kernel memory just elsewhere
In current system the key resides in memory directly, not only in
dmcrypt but also in all crypto API providers (it must be there
if the encryption is done by CPU).
Removing key from dmcrypt structure is possible but with
crypto provider it is not so easy.
So to make it at least some sense you have to use some crypto provider
system which does not store key in memory.
No such generic provider is in upstream kernel.
(We are talking about designs like TreVisor/TRESOR, Loop amnesia and similar.
These will be never usable for generic configurations and architectures.)
2) Key must be transferred anyway
Currently the key is sent into dmcrypt in plain form in ioctl and only
root can do this. This path was audited and properly wipes all buffers
once the key is not needed.
(And yes, this is not coolest design but it is simple.)
Replacing it with transfer from kernel keyring will just move this inside
kernel but removes the KISS principle here.
(On the other side, if we have one day non-root private device-mapper devices,
keyring could help to properly isolate keys among users of these private
3) We do not have proper userspace support
If you see how the LUKS is designed, it processes volume key in userspace
decrypted from keyslot. So it means redesigning keyslot operations.
(At least it means to add another level of key-hierarchy which covers
keyring operations with "encrypted keys".)
I would like to see that instead of keyslots we have configurable key
references (IOW it stores some unique ID of key stored in some token,
keyring or whatever instead of directly encrypted volume key).
But we do not have such system yet.
I know that kernel part is kind of independent to this but without
thinking how to integrate it to LUKS it does not make much sense.
So, I think using keyring is doable but I do not see it
as a thing which primarily improves security.
I see it as logic separation of functions instead (keyring handles keys,
dmcrypt block encryption). And as such it should be implemented one day.
More information about the dm-crypt