On 11/11/2018 1:09 PM, Mimi Zohar wrote:
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?
There's the original dracut support for loading a masterkey, which is
used by the EVM and ecryptfs dracut modules. After the last usage,
the masterkey needs to be removed from the keyring.
How does one generate new encrypted keys with the system masterkey
removed from the keyring?
Different people over the years have wanted to add support for
calculating the boot time expected PCRs values in order to reseal keys
(trusted key update), but I haven't looked to see if there are any
open source tools available.
Mimi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
