You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Safeboot has an enrollment protocol where an admin enrolls {hostname, EKcert} (or even {hostname, EKpub} where there is a different way to validate the EKpub).
When systems come with IDevID or IAK certificates, then we could enroll {hostname, serial_number}, and the binding of an EKpub could then happen in an automated protocol where the client sends its IDevID or IAK certificate, and the EKpub, and then the enrollment protocol would encrypt assets for the host to the host's EKpub but with the cryptographic name of the IDevID/IAK as the activation object.
This makes for a simpler manual step than today: instead of having to boot trusted media to extract an EKcert, the admin would only have to copy a serial number from a manifest into an inventory system and assign a hostname.
The part of the protocol where the host sends its IDevID or IAK certs and the EKpub could be run in an isolated lab or in production networks. (In the former case the enrollment servers can be isolated for extra security.)
The text was updated successfully, but these errors were encountered:
So, basically we'd encrypt to the EKpub as in the WK method but with the name of the subject public key from the IDevID/IAK certificate as the activation object.
We don't even need to actually use the private keys for the IDevID/IAK -- the fact that TPM2_ActivateCredential() would require that key object to be loaded would enough.
Currently Safeboot has an enrollment protocol where an admin enrolls
{hostname, EKcert}
(or even{hostname, EKpub}
where there is a different way to validate theEKpub
).When systems come with
IDevID
orIAK
certificates, then we could enroll{hostname, serial_number}
, and the binding of anEKpub
could then happen in an automated protocol where the client sends itsIDevID
orIAK
certificate, and theEKpub
, and then the enrollment protocol would encrypt assets for the host to the host'sEKpub
but with the cryptographic name of theIDevID
/IAK
as the activation object.This makes for a simpler manual step than today: instead of having to boot trusted media to extract an
EKcert
, the admin would only have to copy a serial number from a manifest into an inventory system and assign a hostname.The part of the protocol where the host sends its
IDevID
orIAK
certs and theEKpub
could be run in an isolated lab or in production networks. (In the former case the enrollment servers can be isolated for extra security.)The text was updated successfully, but these errors were encountered: