gcolunga
commented
2 weeks ago In the HIT meeting held on 10/7/2024, all proposals for the issue were reviewed and not accepted. Closing this issue as not accepted.
Closed Ryuichiro-Ohya-FX closed 2 weeks ago
gcolunga
commented
2 weeks ago In the HIT meeting held on 10/7/2024, all proposals for the issue were reviewed and not accepted. Closing this issue as not accepted.
Requesting Organization: ryuichiro.ohya.jz@fujifilm.com
Status: This issue is not related to CC evaluation for any actual products. This issue should be a kind of concern for the future products.
[ ] On-going certification [x] Preparatory/Other
Document Affected HCD cPP v1.0e, HCD SD v1.0e
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): FPT_SBT_EXT.1.5
Supporting Document testing in question: The following notes on FCS_COP.1/xxxs. "Note: Testing of cryptographic functions implemented in the Root of Trust for Secure Boot (FPT_SBT_EXT.1) may not be feasible and independent testing may not be available. In this situation, contact the CC Scheme."
Issue: As the result of addition of the above note to FCS_COP.1/xxx in HCD cPP v1.0e, JISEC introduced the attached operation, which requires manufacturers to describe the information to identify the Root of Trust product or implementation in TSS. We, Japanese manufacturers accepted it once, but still have a concern about this operation because such kind of information should be sensitive to be disclosed. We manufacturer asked with JISEC if it is acceptable to describe the information in KMD or something else which is not disclosed publicly, but the answer was negative because they think public disclosure of the information should deter false claims by manufacturers.
Proposed Resolution(if any): Modify FPT_SBT_EXT.1.2 so that it requires only to ensure the authenticity by Root of Trust instead of requiring selection of specific cryptographic method, and remove FPT_SBT_EXT.1.5 and 1.6. The following is an example. This modification may allow us to remove the notes added in FCS_COP.1/xxx.
FPT_SBT_EXT.1.2 At boot time the TSF shall use the chain(s) of trust to confirm integrity of its firmware/software (strike out the succeeding part).
A JISEC person mentioned that CC manner requires evaluator to verify the validity of the implementation for the claimed SFR. So, he believes that if FPT_SBT_EXT.1.2 requires the detailed cryptographic method and if verification cannot be done for the immutable RoT, then the additional notes are reasonable. And he mentioned that the additional notes can be removed if FPT_SBT_EXT.1.2 can be more abstract requirements, as above.
Rationale: N/A
JISEC interpretation on RoT testing.docx