Japanese
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:
- Testing began under FIPS 140-3: September 2020
- Application acceptance ended for FIPS 140-2: September 2021
- Expiration of validation validity under FIPS 140-2: September 2026
Abbreviated terms
- CMVP: Cryptographic Module Validation Program
- CAVP: Cryptographic Algorithm Validation Program
- ACVT: Automated Cryptographic Validation Testing
- NVLAP: National Voluntary Laboratory Accreditation Program
- CST: Cryptographic and Security Testing
- NIST: National Institute of Standards and Technology
- CCCS: Canadian Centre for Cyber Security
- FIPS PUB: Federal Information Processing Standards Publication
CMVP
| STEP | STATUS | PROCESS |
|---|---|---|
| 0 | The applicant (vendor) enters into a contract with the testing laboratory (ITSC) and submits the cryptographic module for testing. | |
| 1 | IUT | The testing laboratory conducts tests in accordance with FIPS PUB 140-3. |
| 2 | Review Pending | The testing laboratory submits the test report to the authority (CMVP: NIST and CCCS) |
| 3 | In Review | The validation authority verifies the validity of the test report. |
| 4 | Coordination | During the validation process, comments are submitted to the testing laboratory as needed, and the process continues until resolved. |
| 5 | Finalization | Once the verification process is completed, Validation Certificate is issued and published on the validation authority’s website. |
Documents and other materials
For the Cryptographic Module Testing under CMVP, please prepare the following:
- SP (Security Policy: in English): This will be made public.
- Source code, chips (in the case of hardware), etc.
- Documents required for testing (functional specifications, design documents, guidance documents, etc.).
CAVP
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
| Classification | Cryptographic Algorithm Name |
|---|---|
| Symmetric Key – Encryption | AES Triple-DES |
| Asymmetric Key – Signature | DSA, RSA, ECDSA |
| Message Authentication | Triple-DES CMAC AES (CMAC/CCM/GCM/GMAC) HMAC |
| Hashing | SHA-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 Establishment | DSA, 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 Requirements | Discription | Security 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 Security | Approved 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 Environment | Non-Modifiable, Limited or Modifiable. Control of SSPs. | ● | — | — | |
| Modifiable. 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 Security | Module 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 Management | Random 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-Tests | Pre-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. | ● | ● | |||
| [Design] Module designed to allow testing of all provided security related services. | ● | ● | ● | ● | |
| [FSM] Finite state model. | ● | ● | ● | ● | |
| [Development] Annotated source code, schematics or HDL. | ● | ● | ● | ● | |
| [Development] Software high-level language. Hardware high-level descriptive language. | ● | ● | ● | ||
| [Development] Documentation annotated with pre- conditions upon entry into module components and postconditions expected to be true when components is completed. | ● | ||||
| [Testing] Functional Testing. | ● | ● | |||
| [Testing] Low-level Testing. | ● | ● | |||
| [Delivery and Operation] Initialisation procedures. | ● | ● | ● | ● | |
| [Delivery and Operation] Delivery Procedures. | ● | ● | ● | ||
| [Delivery and Operation] Operator authentication using vendor provided authentication information. | ● | ||||
| [Guidance] 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. | ● | ||||
