[ add keyrings and lkml ] On Sun, Nov 11, 2018 at 9:28 AM Mimi Zohar <zo...@linux.ibm.com> wrote: > > On Fri, 2018-11-09 at 15:13 -0700, Dave Jiang wrote: > > In order to make nvdimm more secure, encrypted keys will be used instead of > > clear text keys. A master key will be created to seal encrypted nvdimm > > keys. The master key can be a trusted key generated from TPM 2.0 or a less > > secure user key. > > Trusted keys also work for TPM 1.2. Are you intentionally limiting > the master key to TPM 2.0?
TPM 1.2 is supported from a software perspective, however the intersection of hardware platforms deploying security enabled NVDIMMs and TPM 1.2 might be a null set. > Traditionally there is a single master key for the system, which would > be sealed to a set of boot time PCR values. After decrypting all of > the encrypted keys, the master key would be removed from the keyring > and a PCR extended. Extending a PCR would prevent the master key from > being unsealed again and used to decrypt encrypted keys, without > rebooting the system. Normally this would be done before pivoting > root. > > If you're not referring to the system master key and are intentionally > limiting usage to TPM 2.0, more details on the master key security > requirements should be included. Oh, interesting point. I think we had been assuming a local + unsealed-at-runtime nvdimm master key rather than a system-wide master key. Yes, we need to rethink this in terms of supporting a sealed system-key. This would seem to limit security actions, outside of unlock, to always requiring a reboot. I.e. the nominal case is that we boot up and unlock the DIMMs, but any subsequent security operation like erase, or change-passphrase would require rebooting into an environment where the system-master key is unsealed. I do think re-provisioning keys and erasing DIMM contents are sufficiently exceptional events that a reboot requirement is tolerable. Is there already existing tooling around this to be able to schedule master-key related actions to be deferred to an initrd environment? > Using trusted keys that are encrypted/decrypted using a user key > should really be limited to testing environments. Makes sense. > > > > In the process of this conversion, the kernel cached key will be removed > > in order to simplify the verification process. The hardware will be used to > > verify the decrypted user payload directly. > > Making this sort of change implies there is no concern in breaking > existing userspace. Either the code hasn't yet been upstreamed or > there are not any users. If the code hasn't been upstreamed, it would > make more sense to squash the git history: > > - making code review easier > - making the git history bisect safe Yes, the old scheme is not upstream. I'll do the squash once we've finalized the key-management details. Thanks for the help Mimi.