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
The TPM unsealing code will fall back to trying with a transient primary key if the initial unsealing attempt with the persistent primary key fails in some cases - if the TPM2_Load command fails with a handle error, indicating that the supplied parent handle is not a valid storage key.
But it fails immediately if TPM2_Load returns a TPM_RC_INTEGRITY error for the inPrivate parameter, which may indicate that although the parent handle corresponds to a valid storage key, it may not be the correct parent key. This might happen if other software that uses the TPM evicts the primary key we create during install and then creates a new one with a non-standard template.
The unsealing code should probably adopt a belt and braces approach to error handling here and fall back to trying with a transient primary key if the TPM2_Load command fails for any reason, rather than implementing handling that is specific to each error type. I would also extend the existing error handling to work like this:
Initial try with the persistent shared SRK at the well-known handle (0x81000001).
If that fails, try every persistent key on the TPM.
If that fails, try creating a transient SRK.
The text was updated successfully, but these errors were encountered:
Thanks for taking a look at this - so I've actually misunderstood my own code and probably the issue that started me looking at this. I think it would probably still be a good idea to implement trying with other persistent keys on the TPM.
sespiros
added a commit
to sespiros/secboot
that referenced
this issue
Sep 23, 2022
loadForUnseal() will now try all the persistent SRKs stored in NV
before falling back to creating a transient SRK. Any errors during
that process are returned as an ErrTPMProvisioning error to the
caller.
This resolvescanonical#207.
The TPM unsealing code will fall back to trying with a transient primary key if the initial unsealing attempt with the persistent primary key fails in some cases - if the TPM2_Load command fails with a handle error, indicating that the supplied parent handle is not a valid storage key.
But it fails immediately if TPM2_Load returns a TPM_RC_INTEGRITY error for the inPrivate parameter, which may indicate that although the parent handle corresponds to a valid storage key, it may not be the correct parent key. This might happen if other software that uses the TPM evicts the primary key we create during install and then creates a new one with a non-standard template.
The unsealing code should probably adopt a belt and braces approach to error handling here and fall back to trying with a transient primary key if the TPM2_Load command fails for any reason, rather than implementing handling that is specific to each error type. I would also extend the existing error handling to work like this:
The text was updated successfully, but these errors were encountered: