Cryptography evaluated under CCN-STIC 2100

MEMeC cryptographic mechanisms evaluation

We evaluate the cryptography implemented in your product: mechanisms and protocols, parameterisation, conformity testing, implementation pitfalls and the evidence required for the applicable CL1, CL2 or CL3 level.

Request a MEMeC evaluation Read the CCN-STIC 2100 guide
Request an evaluation

When it applies

An evaluation of the actual implementation

MEMeC is used when a product's cryptographic mechanisms need to be assessed in depth during a certification or CPSTIC inclusion process. The methodology covers products under Common Criteria, LINCE or STIC. MEMeC is performed as a separate evaluation in parallel with the main process. It must not be confused with MEC, the cryptographic module integrated into LINCE. The work goes beyond checking a list of algorithms: it examines how they are configured, how the product uses them and whether the implementation returns conformant results.

Before testing starts, we identify the mechanisms in scope, the libraries and components implementing them, the required level and the interfaces available to exercise them.

CCN-STIC 221 sets out the cryptographic mechanisms and parameters accepted by the CCN. MEMeC verifies that the product implements and uses them correctly with the declared parameterisation.

End-to-end service

What the MEMeC evaluation includes

We start from your team's technical knowledge and handle the documentation structure, test preparation and traceability through remediation verification.

Scope and level

We inventory mechanisms, protocols, parameters and dependencies to define the scope and determine the applicable level: CL1, CL2 or CL3.

MEMeC questionnaires

We work with your team to complete the Vendor Questionnaire (VQ), its Lite version or the random number generation questionnaire.

Test environment

We review the interfaces, test harness and instructions needed to reach the primitives and reproduce the tests.

Cryptographic conformity

We run the test vectors and analyse the response files produced by the mechanisms included in scope to verify that they return the expected results.

Technical review

We check parameterisation, library use and the evidence needed to rule out implementation pitfalls.

Non-conformities and remediation verification

We report the non-conformities so your team can resolve them. We then verify against the corrected version that the identified issues have been resolved.

Formal process

From preparation to the evaluation outcome

We follow the process defined in the CCN-STIC 2100 guide and maintain traceability between the declared mechanisms, applicable tasks, performed tests and the resulting outcome.

  1. 1

    Inputs and scope

    We review the inventory, questionnaires, version, interfaces and evidence to establish the scope and level.

  2. 2

    Evaluation plan

    We identify mandatory tasks and those that depend on functionality implemented by the product.

  3. 3

    Technical execution

    We assess requirements, CCN-STIC 221, conformity, self-tests, sensitive parameters and implementation pitfalls.

  4. 4

    Closure and remediation verification

    We report non-conformities, verify against the corrected version that the identified issues have been resolved and document the outcome with full traceability.

Evaluation outcome

The outcome maintains traceability between the performed tasks, reviewed evidence, tests and verified remediation throughout the evaluation.

What we need from your team

You do not need to have all the information prepared before we start. We do need access to the people who understand the implementation, as well as the ability to prepare an evaluable build and remediate any non-conformities.

  • An identified product version and its configuration
  • Access to the team responsible for the cryptographic implementation
  • Information on proprietary mechanisms and external libraries
  • Ability to expose test interfaces or provide testing tools
  • Availability to answer questions and resolve non-conformities

Documentation and results

What is prepared when the process is complete

The technical documentation is complete and verified, and the results are submitted to the CCN through the corresponding evaluation reports.

Documented scope

An inventory of mechanisms, the applied level, the evaluated version and traceability to the interfaces and evidence used.

Complete, verified MEMeC documentation

Completed MEMeC documentation supported by the technical information needed to substantiate each response.

Test results

Conformity results and traceability of the checks performed on the cryptographic mechanisms included in scope.

Remediation verification

We verify against the corrected version that the issues identified during the evaluation have been resolved.

One team throughout the process

We handle the analysis, documentation preparation, testing and remediation verification. The same team coordinates the work throughout to preserve the technical context between phases.

We handle the MEMeC evaluation so your team can stay focused on the product.

Frequently asked questions about MEMeC evaluation

Which products may need a MEMeC evaluation?
Products whose primary functionality depends directly on cryptography, such as a VPN or an encryption tool, may require MEMeC when evaluated under Common Criteria, LINCE or STIC. MEMeC is performed as a separate evaluation in parallel with the main process. The applicable level depends on the implemented mechanisms and the certification requirements.
What is the difference between MEC and MEMeC?
MEC is the cryptographic evaluation module integrated into LINCE. MEMeC is a different evaluation defined in CCN-STIC 2100 and is performed separately, in parallel with the main process, to assess the cryptography implemented in the product in greater depth.
Does the vendor need to provide source code?
CL1 does not require source code. For CL2, the vendor provides the code excerpts needed to demonstrate that implementation pitfalls have been avoided, including integration code for external libraries where relevant. CL3 requires the implementation representation. If the cryptography is provided by an external library, this must include the code calling its functions and the build configuration where it affects the implementation.
Can a special build be used for testing?
Yes. The methodology allows modified builds or interfaces that expose mechanisms which are not directly accessible in the final product, provided that the differences are documented and the test results can be justified as valid for the evaluated version.
What happens if a cryptographic test fails?
We analyse the cause and report the non-conformity so your team can resolve it. We then verify against the corrected version that the identified issue has been resolved.

Does your product require security and cryptographic evaluation?

We handle the security evaluation and MEMeC from start to finish so your team can stay focused on the product.