Document Affected:
HCD cPP and/or HCD SD, depending on the resolution path.
Certification Deadline Dates:
N/A
Section of HCD cPP/HCD SD in question (reference to SFR or subchapter in the HCD cPP or HCD SD):
SFR: FPT_SBT_EXT.1.
Sections: 5.8.1 (HCD cPP), 2.6.1 (HCD SD)
Supporting Document testing in question:
Section 2.6.1 (HCD SD). Please refer to Issue for details.
Issue:
FPT_SBT_EXT.1 states that Root of Trust is implemented in immutable code or a HW-based write-protection mechanism. HCD cPP provides no further description or additional detail on the definition for the Root of Trust in terms of its protection. “Appendix G: Glossary” also fails to provide further information on this matter.
SD includes a requirement that the TSS shall describe how the Root of Trust is immutable. However, HCD cPP is not clear on how the immutable code or HW-based write-protection is defined. The SD does not provide clear guidance on the level of assurance the evaluator shall take into consideration to confirm a compliant Root of Trust protection mechanism.
Proposed Resolution (if any):
Further clarification on the protection requirements for the Root of Trust is needed. Immutability should be defined clearly.
Rationale: (Possible scenarios of concern that leads to this issue)
Is a software write protection mechanism at boot considered as immutable code, as immutable code can still be described as an object whose state cannot be modified after it is created. Is it applicable if the TOE implements a write-protect mechanism in kernel mode (which restricts user mode or MFP firmware accessibility)?
Also, considering HW-based protection mechanisms, is power off/on protection considered as a HW-based protection? (I.e. the TOE invokes a write-protect with the power-on during the start of the boot sequence, and this function is on until the power is turned off.)
Requesting Organization: CCTL | Lightship Security, Inc.
Status: [ ] On-going certification [X] Preparatory/Other
Document Affected: HCD cPP and/or HCD SD, depending on the resolution path.
Certification Deadline Dates: N/A
Section of HCD cPP/HCD SD in question (reference to SFR or subchapter in the HCD cPP or HCD SD): SFR: FPT_SBT_EXT.1. Sections: 5.8.1 (HCD cPP), 2.6.1 (HCD SD)
Supporting Document testing in question: Section 2.6.1 (HCD SD). Please refer to Issue for details.
Issue: FPT_SBT_EXT.1 states that Root of Trust is implemented in immutable code or a HW-based write-protection mechanism. HCD cPP provides no further description or additional detail on the definition for the Root of Trust in terms of its protection. “Appendix G: Glossary” also fails to provide further information on this matter.
SD includes a requirement that the TSS shall describe how the Root of Trust is immutable. However, HCD cPP is not clear on how the immutable code or HW-based write-protection is defined. The SD does not provide clear guidance on the level of assurance the evaluator shall take into consideration to confirm a compliant Root of Trust protection mechanism.
Proposed Resolution (if any): Further clarification on the protection requirements for the Root of Trust is needed. Immutability should be defined clearly.
Rationale: (Possible scenarios of concern that leads to this issue) Is a software write protection mechanism at boot considered as immutable code, as immutable code can still be described as an object whose state cannot be modified after it is created. Is it applicable if the TOE implements a write-protect mechanism in kernel mode (which restricts user mode or MFP firmware accessibility)?
Also, considering HW-based protection mechanisms, is power off/on protection considered as a HW-based protection? (I.e. the TOE invokes a write-protect with the power-on during the start of the boot sequence, and this function is on until the power is turned off.)