Multi-Certified Root-of-Trust: Exploiting Synergies

In recent years, worldwide chip production has increased significantly. The “back to silicon” trend is driven by the digitization of multiple usages as well as the specificities of certain markets. As chips are liable for data protection, the proportion of chips with embedded security features is increasing. Because of the shortened time-to-market, some chips must be ready to be deployed in markets or use-cases unknown at the time of design. Since each market has its own security schemes, chips need to be “pre-certifiable” under different schemes. The design activity is usually tailored to a given set of security requirements. In the new context where multiple requirements will have to be satisfied proactively, design strategies must evolve. In this talk, we shall share experience regarding the design of chips eligible to triple precertification, namely: Common Criteria (CC), NIST FIPS 140 and Chinese OSCCA. The synergies arise at three levels. First, documentation production is rationalized. Typically, in the latest version of FIPS 140 (version 3), lifecycle assurance requirements can be mutualized with the ADV, AGD, ALC and ATE assurance classes in CC. Second, it is often beneficial to combine functional requirements. Consider, for example, the mandatory self-checks of cryptographic algorithms and/or keys in FIPS 140: these are sound precautions that reduce the number of vulnerabilities in the CC context. Third, some specific IPs need to be analyzed more deeply in all the schemes anyhow. For instance, regarding True Random Number Generators (TRNGs), there are very detailed, even intrusive requirements (e.g., access to “raw” bits). Similarly, the standards require testing on millions of bits generated in a row by the TRNG. The OSCCA scheme requires that several TRNG rationales be implemented, so as to withstand total failures. Obviously, this also benefits the resistance to fault attacks under a CC prism. However, it should be noted that some pitfalls should also be avoided. For example, EVITA's secure boot is based on firmware hash, which is incompatible with FIPS 140-3 requirements to leverage the digital signature (from level 3 onward). To sum up, we intend to show that certification efforts can be rationalized to better reach the market, with cost-saving factorization while designing or producing certification-related evidence sets.