Section of HCD cPP/HCD SD in question (reference to SFR or subchapter in the HCD cPP or HCD SD):
FPT_SBT_EXT.1.1
Issue:
Would it be acceptable to have multiple immutable roots of trust, any one of which could be used to verify firmware integrity?
For example, in one-time programmable efuses, we would have:
RSA public key 1
RSA public key ..
RSA public key n
LMS/XMSS public key 1
LMS/XMSS public key ..
LMS/XMSS public key n
which algorithm to use
The "which algorithm to use" value would determine whether to use RSA or LMS/XMSS for the firmware signature verification. We would try each public key for that algorithm and proceed if any one successfully verifies the signature.
We would invalidate keys in the field by remotely zeroing them out. According to the proposed solution for issue #25, "making changes" to the root of trust would require "manufacturing or service tools directly connected to a locally(physically) present platform or device" (i.e. not remote), but this implementation would not be "making changes" to the root of trust, per se, but rather switching from one truly immutable root of trust to another.
Proposed Resolution(if any):
State the resolution you would like to see.
Rationale:
Provide any additional rationale (i.e. RFC references).
Requesting Organization: Matt Glockner, Lexmark
Status: [ ] On-going certification [X] Preparatory/Other
Document Affected HCD cPP v1.0e
Section of HCD cPP/HCD SD in question (reference to SFR or subchapter in the HCD cPP or HCD SD): FPT_SBT_EXT.1.1
Issue: Would it be acceptable to have multiple immutable roots of trust, any one of which could be used to verify firmware integrity?
For example, in one-time programmable efuses, we would have:
The "which algorithm to use" value would determine whether to use RSA or LMS/XMSS for the firmware signature verification. We would try each public key for that algorithm and proceed if any one successfully verifies the signature.
We would invalidate keys in the field by remotely zeroing them out. According to the proposed solution for issue #25, "making changes" to the root of trust would require "manufacturing or service tools directly connected to a locally(physically) present platform or device" (i.e. not remote), but this implementation would not be "making changes" to the root of trust, per se, but rather switching from one truly immutable root of trust to another.
Proposed Resolution(if any): State the resolution you would like to see.
Rationale: Provide any additional rationale (i.e. RFC references).