HIRS
HIRS copied to clipboard
Is the default TPM 2.0 NV Index for platform certificates correct?
The code currently uses 0x1c90000: https://github.com/nsacyber/HIRS/blob/8b25ae698a250c70367c21b473f5af44b6968610/HIRS_ProvisionerTPM2/src/CommandTpm2.cpp#L106-L108
In the TCG "Registry of Reserved TPM 2.0 Handles and Localities":
- (page 9) the index range 0x01C00000–0x01C07FFF is reserved for endorsement
- (page 9) the index range 0x01C08000–0x01C0FFFF is reserved for platform
- (page 14), the index range 0x01C90000-0x01C9FFFF is for the infrastructure working group
Section 2.2.2.2.2 on "Platform" (page 11) says the Platform range contains NV Indices to support Certificates to identity the Platform such as Platform Certificates.
Should the platform certificate be expected in the range 0x01C08000–0x01C0FFFF for consistency with the TPM spec? It's so far unclear to me which specific index within this range should be used.
The Comments in the code above this snippet refer to Table 2 (pg. 29) of the TCG TPM v2.0 Provisioning Guidance, Revision 1.0. That table provides a handle for an IDevID certificate, not the Platform Certificate. Thankyou for pointing this out.
The Registry of reserved TPM 2.0 handles and localities table 3 would imply the Handle should be in the 0x1c08000 to 0x1c08FFFF range but they need to be determined by individual working groups. There does not appear be any TCG published applicable handles at this time.
The Platform certificate can vary in size, depending upon how many components are included. This makes it a bad candidate to be stored within the TPMs NVRAM. The current trend has been to define a file location on the device itself. Refer to the TCG PC Client Firmware Integrity Measurements specification section 3.2.2.2 as an example.
HIRS currently uses the following device paths which are consistent with current PC Client specifications, but likely to change in future TCG specifications:
/boot/tcg/cert/platform/
and for Reference Integrity Manifests:
/boot/tcg/manifest/rim/ /boot/tcg/manifest/swidtag /
Please re-open if there are any further questions.
I agree with you. There is no good security reason to keep it there. Not a good use of a scarce resource. We're set.
thanks, @iadgovuser26!