Cryptographic Modules Testing (CMVP/CAVP)

Cryptographic Modules Testing Services

IT Security Center was accredited as a testing laboratory for ‘Cryptography and Security Testing (CST)’ by the U.S. NIST’s accreditation program (NVLAP) on May 15, 2009 (NVLAP Lab. Code 200822-0).

As a result, it conducts cryptographic module testing and cryptographic algorithm testing based on FIPS PUB 140-3 as a testing laboratory for the CMVP/CAVP of the United States (NIST) and Canada (CCCS).

Additionally, it provides consulting related to CMVP/CAVP validation.

NVLAP Accreditation

Lab Name : IT Security Center
NVLAP Lab Code : 200822-0
Scope of Accreditation :

Based on FIPS PUB 140-3(*)

  • Automated Cryptographic Validation Testing (ACVT) for all FIPS-approved and/or NIST-recommended security functions as required in applicable versions of FIPS 140.
  • Test method for FIPS 140 incorporate testing for all Security Levels (1 through 4) and all types (Software, Firmware, Hardware, and Hybrids)

(*) FIPS PUB 140-2 has transitioned to FIPS PUB 140-3 according to the following schedule:

Abbreviated terms


Cryptographic Module Testing and Validation Process
0The applicant (vendor) enters into a contract with the testing laboratory (ITSC) and submits the cryptographic module for testing.
1IUTThe testing laboratory conducts tests in accordance with FIPS PUB 140-3.
2Review PendingThe testing laboratory submits the test report to the authority (CMVP: NIST and CCCS)
3In ReviewThe validation authority verifies the validity of the test report.
4CoordinationDuring the validation process, comments are submitted to the testing laboratory as needed, and the process continues until resolved.
5FinalizationOnce the verification process is completed, Validation Certificate is issued and published on the validation authority’s website.
Source: FIPS 140-3 Cryptographic Module Validation Program Management Manual DRAFT(Date 12/23/2022 Version1.2)

Documents and other materials

For the Cryptographic Module Testing under CMVP, please prepare the following:


CAVP validates that the cryptographic algorithms of the security functions approved in FIPS PUB 140-3 are correctly implemented. For CMVP validation, at least one CAVP-approved service algorithm is required.

Source: Cryptographic Algorithm Validation Program (CAVP)

For the testing, the Automated Cryptographic Validation Testing System (ACVTS) is used. Based on the test specifications, the testing laboratory creates Test Cases, which form the Test Vector. You will be required to produce a Test Vector Response using the cryptographic implementation under test.

The results are verified on the NIST server, and if passed, they are listed on the validation list. The format of the Response is indicated in the JSON Specification for each algorithm of ACVP.

FIPS PUB 140-3

Security functions approved under FIPS PUB 140-3

ClassificationCryptographic Algorithm Name
Symmetric Key – EncryptionAES
Asymmetric Key – SignatureDSA, RSA, ECDSA
Message AuthenticationTriple-DES CMAC
HashingSHA-1, SHA-224, SHA-256, SHA-384, SHA-512,
SHA-512/224 and SHA-512/256
SHA3-224, SHA3-256, SHA3-384, SHA3-512,
SHAKE128, SHAKE256, CSHAKE, KMAC, TupleHash, ParallelHash
Key EstablishmentDSA, RSA, ECDSA
Random Number Generators (RNG)NIST-Recommendation for Random Number Generation Using Deterministic Random Bit Generators (SP800-90A)
NIST-Recommendation for the Entropy Sources Used for Random Number Generation (SP800-90B)

Security Level

In FIPS PUB 140-3, security levels 1 to 4 are defined for the following requirements:

Summary of security requirements

Security RequirementsDiscriptionSecurity Level
Cryptographic Module Specification Specification of cryptographic module, cryptographic boundary, approved security functions, and normal and degraded modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. All services provide status information to indicate when the service utilises an approved cryptographic algorithm, security function or process in an approved manner.
Cryptographic Module Interfaces Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
Trusted channel.  
Roles, Services, and Authentication
Logical separation of required and optional roles and services.
Role-based or identitybased operator authentication.      
Identity-based operator authentication.    
Multi-factor authentication.    
Software/Firmware SecurityApproved integrity technique, or EDC based integrity test. Defined SFMI, HFMI and HSMI.
Executable code.
Approved digital signature or keyed message authentication
code- based integrity test.
Approved digital signature based integrity test.  
Operational EnvironmentNon-Modifiable, Limited or Modifiable.
Control of SSPs.
Role-based or discretionary access control.
Audit mechanism.
Physical Security Production-grade components.
Tamper evidence.
Opaque covering or enclosure.
Tamper detection and response for covers and doors. Strong enclosure or coating. Protection from direct probing. EFP
or EFT.
Tamper detection and response envelope. EFP.
Fault injection mitigation.
Non-Invasive SecurityModule is designed to mitigate against non-invasive attacks specified in Annex F.
Documentation and effectiveness of mitigation techniques specified in Annex F.
Mitigation Testing.  
Sensitive Security Parameter ManagementRandom bit generators, SSP generation, establishment, entry and output, storage and zeroisation.
Automated SSP transport or SSP agreement using approved methods.
Manually established SSPs may be entered or output in plaintext form.
Manually established SSPs may be entered or output in either encrypted form, via a trusted channel or using split knowledge procedures.  
Self-TestsPre-operational: software/firmware integrity, bypass, and critical functions test.
Conditional: cryptographic algorithm, pair-wise consistency, software/firmware loading, manual entry, conditional bypass and critical functions test.
Life-Cycle Assurance [Configuration Management]
Configuration management system for cryptographic module, components, and documentation. Each
uniquely identified and tracked throughout lifecycle.
[Configuration Management]
Automated configuration management system.
Module designed to allow testing of all provided security related services.
Finite state model.
Annotated source code, schematics or HDL.
Software high-level language. Hardware high-level descriptive language.
Documentation annotated with pre- conditions upon entry into module components and postconditions expected to be
true when components is completed.
Functional Testing.
Low-level Testing.
[Delivery and Operation]
Initialisation procedures.
[Delivery and Operation]
Delivery Procedures.
[Delivery and Operation]
Operator authentication using vendor provided authentication information.
Administrator and non-administrator guidance.
Mitigation of other attacks Specification of mitigation of attacks for which no testable requirements are currently available.
Specification of mitigation of attacks with testable requirements.
▲ このページのTOPに戻る
お問い合わせ お問い合わせ >