Hi, 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 dmcrypt devices.) 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. Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
