Common Criteria evaluations have traditionally been performed against a set of Evaluated Assurance Levels (EALs). The assurance levels reflect added assurance requirements that must be met to achieve Common Criteria certification. Note that the EAL levels indicate to what assurance package the product was tested with and not that the product itself is more secure.
EAL based evaluations have been criticized for being time-consuming while modern software systems are progressing rapidly, which can lead to a software version already becoming outdated when the Common Criteria certificate is finally issued. In response, Common Criteria has introduced the collaborative Protection Profile (cPP) based approach to provide achievable, repeatable, testable evaluation results and facilitate easier comparison among certified products.
The restructuring of the certification approach means that when certifying a product against most cPPs there are no EALs defined. Note that when reviewing a specification of an ongoing cPP evaluation, the assurance package is typically specified in the format "EAL 1 ASE_SPD.1". If you are used to traditional Protection Profiles, the format can easily be misinterpreted as indicating a low level, while it is the exact level specified in the collaborative Protection Profile. Currently, both EAL and non-EAL based evaluations are being performed, causing confusion in the market.
EAL levels are specified by the Protection Profile, and all certified protection profiles and their EAL levels are listed on the Common Criteria Portal.
The relevant distinction is that a PP’s security functional requirements (SFRs) describe the security functionalities of a product, while the security assurance requirements (SARs) define the level of effort (CC Part 3, §6.3) required during the evaluation process. Adequacy of a product to a given field is hence contained in the PP’s SFRs, not by the (optional) SARs. The collaborative Protection Profile for Certification Authorities is intended to provide a minimal, baseline set of requirements that are targeted at mitigating well defined and described threats. It contains 78 SFRs and abundantly uses the so-called “extended components” which specializes in the standard CC SFRs to the PKI domain. In these extended components, the added assurance activities augment the assurance requirements beyond those of EAL1 and ensure that these extended SFRs are evaluable with activities that can be considered focused versions of SARs with Independent Testing.
For more information, refer to Common Criteria for Information Technology Security Evaluation.
Common Criteria for PKI Products
For PKI products, Common Criteria certification can be of help in certain audits but is rarely a formal requirement by legislation, and local requirements may apply.
The United States currently promotes cPP based evaluations and not EAL based CC evaluations. Being certified against a cPP approved by NIAP is a requirement for a product to be on the Commercial Solutions for Classified Program (CSfC) list, required for some governmental use.
Other national evaluation schemes, have phased out generic EAL based evaluations and only accept products for evaluation that claim strict conformance with an approved PP.
In the EU, the Cybersecurity Act will define future certification requirements, which will be the basis for requirements for certain governmental use. EU plan to work with both EAL and non-EAL (classic PP and cPP) based certifications but there are currently no plans to consider certifications of PKI products. The Cybersecurity Act will in contrast to previous EAL levels define assurance levels as Basic, Substantial, and/or High. The level corresponds to the level of the risk associated with the intended use of the product, service, or process.
For more information on Collaborative Protection Profiles (cPP) and EALs, refer to the SEALWeb note and presentation at PrimeKey Tech Days 2020.
SEALWeb note on Primekey’s EJBCA Enterprise CC evaluation:
PrimeKey Tech Days 2020: Trust services – new compliance approach: