search

DSC-iTC / cPP

Dedicated Security Components cPP & SD
MIT License
3 stars 3 forks source link

FPT_PRO_EXT.1 -> an FPT_ROT_EXT SFR? #279

Open woodbe opened 3 months ago

woodbe commented 3 months ago

It seems strange that having a RoT it FPT_PRO_EXT.1 while all the RoT services are FPT_ROT_EXT.

I think that we should rename FPT_PRO_EXT.1 to FPT_ROT_EXT.1 and then increase the numbers of the current ones to1->2 and 2->3.

This isn't urgent, but seems like something that would provide a little more consistency.

jvdsn commented 3 months ago

I guess FPT_PRO_EXT.1 is introducing the RoT concept first as something that could be internal to the TOE (it just requires that there's an RoT SDO and that this SDO is stored in an immutable or mutable but controlled location) Then FPT_ROT_EXT.1 is where the cPP actually starts requiring the TOE to expose the RoT services.

Maybe a wild proposal: what about merging FPT_PRO_EXT.1 and FPT_ROT_EXT.1? It doesn't really make sense to have RoT services without an RoT SDO, and FPT_ROT_EXT.1 depends on FPT_PRO_EXT.1 according to its definition.

slpotte commented 3 months ago

Consider "FCS_STG_EXT.1 Protected Storage". The GlobalPlatform document on Roots of Trust talk about shielded locations. It never really has a separate Root of Trust for Storage. They opted to include shielded locations for each service that needs them. FCS_STG_EXT.1 Protected Storage is synonymous with shielded locations for confidentiality. The shielded locations for integrity is equivalent to the Trusted Computing Group (TCG) platform configuration registers (PCRs). Even though the TCG really hasn't formally document any of their thoughts on roots of trust, the tech leaders often talk about the shielded locations in the context of integrity only.

I would be in favor of combining FTP_PRO_EXT.1 and FTP_ROT_EXT.1. I would eliminate Root of Trust for Storage, since there is some redundancy anyway. The new SFR should contain essentially three elements: 1) The primary Root of Trust, which is the compute engine, code, and data combined that first executes and provides some RoT Service, 2) a list of services provided by the primary Root of Trust (e.g. measurement, authentication, authorization, confidentiality, integrity, reporting, etc.), and 3) the identity of the primary Root of Trust. I would also keep the immutability element too. In the app note, reference the Global Platform document, section 3.1. I would say that RoT for Measurement is the only mandatory service for the RoT, the others are optional. I would not go into bootstrapping and extending the Chain of Trust - put this topic in the back of the parking lot! The identity of the primary Root of Trust is essential for reporting. Perhaps this is optional, especially if reporting is optional?

There are different use cases for RoT. Sometimes it's used to authenticate firmware during a secure boot sequence. Sometimes it's used to assert the state of a platform, as in the case of BitLocker and TCG attestation. Sometimes it's used to provide confidentiality for encryption keys, such as in BitLocker and self-encrypting disk drives. The ROT SFRs should be flexible enough to accommodate any of these use cases.