Common Criteria (CC) is a formal evaluation methodology agreed by national governments that aims to reduce the need to have a product evaluated in different end markets. It is typically used in high assurance use cases, such smart cards, where there is a widely recognized protection profile (PP0084). There are two inter-governmental mutual recognition agreements CCRA with 31 members worldwide and the European Union based SOGIS. CC is now published as an ISO standard, enabling its use by other schemes.
CC is not a natural fit for IoT security evaluation for several reasons:
- IoT devices will need their own market specific Protection Profiles or threat models. These need to be easy to develop and be understandable by a wide audience of developers. CC scheme documents are written in an abstract technical language that will be inaccessible to many IoT developers. This is very important, as if a software engineer does not understand the security requirements, then they are unlikely to develop an appropriately secure device.
- CC evaluation is often a costly process.
- The preparation of evaluation evidence and documentation creation requires significant time and money, due to the fact it was initially designed for critical security infrastructure.
- The time spent in the test lab can be many months, which is often longer than the product lifetime for most consumer IoT products.
- It is difficult for non-specialists to infer from assurance levels (EALs), vulnerability assessment packages (VANs) and attack potentials how much security assurance and robustness they are getting.
Consequently, other evaluation methodologies have been created for devices that need to be moderately or substantially robust, notably CSPN created by the French Certification body ANSSI. A paper on how CSPN compares to CC can be found here.
Comparing PSA Certified and Common Criteria
|PSA Certified Level 2 and PSA Certified Level 3||Common Criteria|
|Suitable for||IoT, consumer, civil||High assurance and high robustness, limited low assurance applications in some countries|
|Protection Profile||English Language, readable by engineers and test labs (ANSSI CSPN style)||Highly technical, need CC specialist to understand|
|Evaluation Methodology||Fixed time for analysis and test (25 days). Access to source code||Variable – depends on assurance packages, can sometimes take months in the test lab. No assumption on source code (until EAL3)|
|Attack Methods||CC Attack Potential calc.|
Level 2 = Scalable software attacks
Level 3 = Physical attacks as well as software attacks
|CC Attack Potential calc.|
Typically Substantial to high attack resistance
|Certification Body||Independent (TrustCB)||Various|
PSA Certified Level 1
Most common security vulnerabilities can be avoided by ensuring basic security goals are met. PSA Certified Level 1 is a security questionnaire that provides documentary evidence that chips, software platforms and devices follow methodically developed security principles. The test laboratory marks the questionnaire and, where necessary, seeks clarifications under a process overseen by an independent certification body. Since this process is for the developer to fill out the questionnaire and not a security evaluation (i.e. not a penetration test on a real device), the comparison to CC is not relevant here.
The design of PSA Certified Level 1 provides a questionnaire and a formalized test lab and Certification Body review process that results in signed documentary evidence that security principles have been applied. For further reading please download the 2020 version of PSA Certified Level 1 questionnaire in the resources section.
PSA Certified Level 2
The security design of a device necessarily involves trusting the “Root of Trust”. This security component is often integrated into the chip and provides trustworthy services such as trusted boot, secure storage, crypto and attestation. PSA Certified defines a Root of Trust (PSA-RoT) using a PSA-RoT Protection Profile that outlines nine Security Functional Requirements that are tested by the laboratory. This certification builds on work done in ANSSI CSPN. At PSA Certified Level 2, the Protection Profile takes the security requirements from the Security Model and turns those into Security Functional Requirements designed to be understandable by IoT developers while also being formal enough for the evaluation laboratories. The developer writes a Security Target (ST) that describes how their product implements these functions. They provide the ST and sample product to the evaluation laboratory who perform a time-limited evaluation, with access to source code, according to Evaluation Methodology (EM) and Attack Methods (AM) documents that are available from the PSA Certified Founders. The scheme uses an independent Certification Body, TrustCB, that oversees the work of the laboratories and ensures they come to consistent interpretations. When comparing different methods of attacking a device, PSA Certified uses the same method as Common Criteria, selecting a level that mainly limits consideration to software attacks. For further reading please download the PSA Certified Level 2 Protection Profile from the resources section.
PSA Certified Level 3
This level considers hardware attacks and software attacks. The scheme documents are in preparation and should be available to lead partners in the second half of 2020.
In summary, the question of whether PSA Certified uses CC is only applicable to PSA Certified Level 2 and PSA Certified Level 3. To ensure that IoT developers can understand the scheme documents the PSA Founding members have chosen to use a variant of CC namely an independent security evaluation scheme based on ANSSI CSPN.
Learn more about PSA Certified methodology