Selecting an EAL (Evaluation Assurance Level) is not an easy task. Depending which assurance level you want to comply, there are 7 EALs defined, the higher the number, the higher the effort to pass the evaluation. According to our Common Criteria Statistics Report, the most demanded EALs are 2, 4 and 5. If you want to know more about the requirements requested for each EAL, check our Common Criteria cheat sheet. At the end, the decision should be driven by your market target and the maturity of your development processes.

Depending on the EAL/PP against the product is being tested, the higher the assurance level is, the longer it usually takes the certification to be carried out. As a basic guideline, a Common Criteria certification needs around 6-8 months to be completed, then there are many factors that can make the consultancy or evaluation process take longer (serious vulnerabilities found, errors and inconsistencies in the product documentation...).

The budget needed to face a Common Criteria certification will depend on the EAL/PP chosen to evaluate the product and the scope of the evaluation. The higher assurance level, the higher cost of the certification. At jtsec, we adjust the budget for each client once we have analyzed the project, with the idea of offering the most suitable approach.

There are two types of Common Criteria member countries, those that are authorized members (countries with laboratories and certification bodies able to assess Common Criteria) and those that are consuming members (countries that do not assess, but do recognize Common Criteria certification).

Authorized members: Canada, France, USA, Italy, Spain, The Netherlands, Germany, Sweden, Australia, India, Japan, Malaysia, New Zealand, Norway, South Korea, Singapore and Turkey.

Consuming members: Austria, Czech Republic, Denmark, Ethiopia, Finland, Greece, Hungary, Poland, Israel, Pakistan, Indonesia, Qatar, UK and Slovak Republic.

Certifying a product under the Common Criteria standard is not a simple process, so we recommend that the first step is to carry out a Gap Analysis. The first decisions to make are: assurance level you want to achieve, the time, personnel and economic investment of the certification and the choice of the scheme under which the certification will be carried out (it must be one of the countries included in the authorizing members).

Once these points have been clarified, it is feasible to start the process of drafting all the paperwork.

The requirements needed to carry out a Common Criteria evaluation depend significantly on the EAL/PP the product will be facing. Although there are requirements common to all assurance levels and protection profiles, there are many other requirements that depend on the product's EAL/PP chosen. If you want to know more about the requirements requested for each EAL, check our Common Criteria cheat sheet

Both, Evaluation Assurance Level (EAL) and Protection Profile (PP), are guidelines that indicate the security requirements that the product must pass in order to obtain Common Criteria certification.

A PP specifies generic security evaluation criteria to substantiate vendors' claims of a given family of information system products and includes an EAL. An EAL is less specific as it does not refer to a specific type of product but to an assurance level.

Preferably and if possible, the product should be evaluated in conformance to a PP.

The areas covered, related to the secure design and implementation of a cryptographic module, include specification; ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.

FIPS 140-3 is a standard developed by the NIST to define requirements to be satisfied by a cryptographic module. So, to achieve a FIPS certification, you will need a cryptographic module included in your product, otherwise it makes no sense.

There are four compliance levels from level 1 (lowest level) to level 4 (highest level):

Level 1: Very low requirements, involves production-grade equipment and externally tested algorithms.

Level 2: Adds requirements for physical tamper-evidence and role-based authentication. Software implementations must run on an Operating System approved to Common Criteria at EAL2.

Level 3: Hardware must feature physical tamper-resistance and identity-based authentication. There must also be physical or logical separation between the interfaces by which “critical security parameters” enter and leave the module. This level offers the best balance and compromise between effective security and operational convenience.

Level 4: This is the highest level, makes the physical security requirements more stringent, its main goal is to avoid environmental attacks, so requires much more robustness again these types of attacks.

There is a current list of FIPS validates algorithms, if your device is running an algorithm developed for a third party, check if is already validated by the NIST.

Otherwise, if you are developing your our algorithm and you want it to be approved by the NIST, you must pass a FIPS certification. Our advice is that, first of all, to contact a consultancy firm, as jtsec, before starting any further steps.

There are four assurance level for FIPS 140-3, from 1 to 4. The standard provides four increasing qualitative levels of security, the higher the number, the higher the requirements to pass the evaluation. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed, the most common ones are levels 1 and 2.