| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software |
| Embodiment | Multi-Chip Stand Alone |
| Status | Historical |
| Caveat | Interim validation. No assurance of the minimum strength of generated SSPs (e.g., keys). When operated in approved mode |
| Vendor | DigiCert, Inc. |
flowchart LR
%% Deterministic review-risk graph for Mocana Cryptographic Suite B Module
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output<br/>Show status</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>no library/version identified</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C5 --> I5 --> R5 --> E5
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C5,C6 clue;
class I2,I3,I5,I6 infer;
class R2,R3,R5,R6 risk;
class E2,E3,E5,E6 evidence;flowchart LR
%% Deterministic clue tier for Mocana Cryptographic Suite B Module
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output<br/>Show status</i><br/>src: text:keyword"]
C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>no library/version identified</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C5,C6 clueLow;Mocana Cryptographic Suite B Module Version 7.0.0f_u1 Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.2 Date: July 23, 2024 DigiCert, Inc.
Suite 500 Lehi, UT 84043 +1 800-896-7973 May be reproduced only in its original entirety [without revision]
| # | Section | Page |
|---|
| Item | Page |
|---|---|
| Table 1 – Security Level of Security Requirements | 4 |
| Table 2 – Tested Operational Environments - Software | 5 |
| Table 3 – Vendor Affirmed Operational Environment | 6 |
| Table 4 – Approved Algorithms | 8 |
| Table 5 – Vendor Affirmed Algorithms Allowed in the Approved Mode of Operation | 12 |
| Table 6 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation | 12 |
| Table 7 – Security Function Implementation (SFI) | 13 |
| Table 8 – Ports and Interfaces | 17 |
| Table 9 – Roles, Service Commands, Input and Output | 17 |
| Table 10 – Approved Services | 20 |
| Table 11 – Non-Approved Services | 25 |
| Table 12 – SSP Management Methods | 27 |
| Table 13 – SSPs | 28 |
| Table 14 – Non-Deterministic Random Number Generation Specification | 30 |
| Table 15 – Pre-Operational Self-Test | 30 |
| Table 16 – Conditional Self-Tests | 31 |
| Table 17 – Error States and Indicators | 32 |
| Table 18 – References | 33 |
| Table 19 – Acronyms and Definitions | 35 |
| Figure 1 – Cryptographic Module Interface Design | 6 |
| Figure 2 – Logical Object | 7 |
version 7.0.0f_u1 hereafter denoted the Module. It contains the security rules under which the module must operate and describes how this module meets the requirements specified in FIPS 140-3 for a Security Level
Table 1
1 General 1
2 Cryptographic Module Specification 1
3 Cryptographic Module Interfaces 1
4 Roles, Services and, Authentication 1
5 Software/Firmware Security 1
6 Operational Environment 1
7 Physical Security N/A
8 Non-Invasive Security N/A
9 Sensitive Security Parameter Management 1
10 Self-Tests 1
11 Life-Cycle Assurance 1
12 Mitigation of Other Attacks N/A
Overall 1 The Module design corresponds to the Module security rules. The security rules enforced by the Module are described in this document.
The primary purpose of this Module is to provide approved cryptographic routines to consuming applications via an Application Programming Interface (API). The Module conforms to [ISO/IEC 19790:2012] Section 7.2 Cryptographic Module Specification. The Module is a software, multi-chip standalone cryptographic module that runs on a general-purpose computer which is the Tested Operational Environment’s Physical Perimeter (TOEPP). The cryptographic boundary of the Module is the single shared object (SO), libmss.so, associated signature file, a persistent status file, and the CPU when PAA is enabled. No components are excluded from the [ISO/IEC 19790:2012] A.2.2 requirements. The Module supports the normal mode of operation under which all of the algorithms, security functions, and services are available; degraded operation is not supported. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated Security Level 1 software modules. The Module is intended to be used in dedicated purpose IOT (Internet of Things) devices and general-purpose computer systems.
The Mocana Suite B Cryptographic Module is tested on the following operational environment(s): Table 2
1 Yocto Linux 3.1 Xerox Explorer 6.5 Intel Atom with PAA NA
2 Yocto Linux 3.1 Xerox Explorer 6.5 Intel Atom without PAA NA
3 Yocto Linux 3.1 Xerox Explorer 8.0 Intel Atom with PAA NA
4 Yocto Linux 3.1 Xerox Explorer 8.0 Intel Atom without PAA NA
5 Yocto Linux 3.1 Xerox Alexandra ARM Cortex without PAA NA
6 Buildroot Linux Ultra Charge & Ingenic without PAA NA
7 Buildroot Linux Honeywell Cordless Ingenic without PAA NA
bit) DigiCert also performed the testing of the Module on the following Operational Environment(s) and claims vendor affirmation on them:
Table 3
1 Ubuntu Linux 4.15 (64-bit) Intel NUC with processor: i7-8650U with and without PAA
3 Yocto Linux 4.4.11 DVF101 using ARM Cortex-A9 with Neon
The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment that is not listed on the validation certificate.
The software block diagram in Figure 1 shows the module, interfaces with the Tested Operational Environment, and the delimitation of its cryptographic boundary, shown shaded in blue. The Cryptographic Boundary is shown in Figure 1 and is comprised of the shared library files (libmss.so) and the integrity check signature file (libmss.so.sig), the POST status file (mssp.bin), and the CPU when PAA is enabled. The dashed line in Figure 2 indicates the Logical Object. The Module's operations occur via API calls from calling applications running within the same process as the Module. Figure 1
The Module supports approved and non-approved modes of normal operation:
The approved mode of operation is configured at instantiation of the Module by the Cryptographic Officer role by execution of an application or protocol operating system process that uses the Module’s cryptographic functions.
The Module transitions to the non-approved mode of operation when one of the non-approved security functions is utilized. The Module can transition back to the approved mode of operation by utilizing an approved security function.
The Module implements the approved and non-approved but allowed cryptographic functions listed in the table(s) below. Table 4
CAVP Algorithm Mode/Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) (L = 2048, N = 224) SHA2 (224, 256, 384, 512) (L = 2048, N = 256) SHA2 (256, 384, 512) PQG Gen (L = 3072, N= 256) SHA2 (256, 384, 512) (L = 2048, N = 224) SHA2 (224, 256, 384, 512) (L = 2048, N = 256) SHA2 (256, 384, 512) (L = 3072, N= 256) SHA2 (256, 384, 512) PQG Ver (L = 1024, N = 160) SHA-1, SHA2 (224, 256, 384, 512)
CAVP Algorithm Mode/Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA2-256 increment 8 Authentication, KDF MAC = 32–256 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA2-384 increment 8 Authentication, KDF MAC = 32–384 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA2-512 increment 8 Authentication, KDF MAC = 32–512 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA3-224 increment 8 Authentication, KDF MAC = 32–224 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA3-256 increment 8 Authentication, KDF MAC = 32–256 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA3-384 increment 8 Authentication, KDF MAC = 32–384 increment 8 Key Sizes: Key Length = 112-65536 Message A4653 HMAC [198] SHA3-512 increment 8 Authentication, KDF MAC = 32–512 increment 8 P-224, P-256, P-384, P-521 Ephemeral HMAC SHA-1, SHA2-(224, KAS ECC [SP 256, 384, 512), SHA3-(224, Key Agreement Unified 800-56Arev3] 256, 384, 512) Scheme provides (Initiator, A4653 per IG D.F between 112 and 256 Responder), Concatenation Scenario 2 path bits of encryption KPG, Full with (2) strength twoStepKdf KDF mode: feedback, supports empty IV
CAVP Algorithm Mode/Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) FB, FC MODP-2048, MODP-3072, MODP-4096, MODP-6144, Diffie-Hellman MODP-8192 KAS FFC [SP Key Agreement Ephemeral 800-56Arev3] HMAC SHA-1, SHA2-(224, Scheme provides (Initiator, A4653 per IG D.F 256, 384, 512), SHA3-(224, between 112 and 200 Responder), Scenario 2 path 256, 384, 512) bits of encryption KPG, Full with (2) strength twoStepKdf Concatenation KDF mode: feedback, supports empty IV HMAC SHA-1, SHA2-(224, 256, 384, 512), SHA3-(224, KDF SP800- Key Based Key A4653 Feedback 256, 384, 512)
108 [108] Derivation
8-bit counter after fixed input data Modulus sizes: 2048, 3072, Asymmetric Key KeyGen
Modulus 2048 SHA2 (224, 256, 384, 512) Modulus 3072 SHA2 (224, Digital Signature PKCS1_v1.5 256, 384, 512) Generation Modulus 4096 SHA2 (224, 256, 384, 512) Modulus 2048 SHA2 (224, 256, 384, 512) A4653 RSA [186] Modulus 3072 SHA2 (224, Digital Signature PSS 256, 384, 512) Generation Modulus 4096 SHA2 (224, 256, 384, 512) Modulus 1024* SHA-1*, SHA2-(224, 256, 384, 512) Modulus 2048 SHA-1*, SHA2-(224, 256, 384, 512) Digital Signature PKCS1_v1.5 Modulus 3072 SHA-1*, Verification SHA2-(224, 256, 384, 512) Modulus 4096 SHA-1*, SHA2-(224, 256, 384, 512) * Legacy Use
CAVP Algorithm Mode/Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) Modulus 1024* SHA-1*, SHA2-(224, 256, 384, 512) Modulus 2048 SHA-1*, SHA2-(224, 256, 384, 512) Digital Signature PSS Modulus 3072 SHA-1*, Verification SHA2-(224, 256, 384, 512) Modulus 4096 SHA-1*, SHA2-(224, 256, 384, 512) * Legacy Use SHA-1, SHA2224, SHA2-256, Message Digest A4653 SHS [180] SHA2-384, Generation SHA2-512 SHA3-224 SHA3-256 SHA3-384 A4653 SHA-3 [202] Hash Function SHA3-512 SHAKE128 SHAKE256 Table 5
Algorithm Use/Function AES EAX Authentication/Encryption, non-approved algorithm AES GCM 4K 256-bit encryption/decryption for 256k implementation AES GCM 64K AES XCBC Message Authentication, non-approved algorithm DES Encryption/Decryption, non-approved algorithm DH Key agreement; key establishment methodology provides less than 112 bits of encryption strength; non-compliant DSA SigGen using 2048/N=224 using SHA-1 ECC CDH Key agreement; key establishment methodology provides less than 112 bits of encryption strength; non-compliant EDDH Curve 25519, Curve 448 HMAC HMAC generation with key size less than 112 bits; non-compliant HMAC-MD5 Non-approved algorithm MD2, MD4, MD5 Message Digest, non-approved algorithm RNG FIPS 186-2 Random Number Generation RSA Key wrapping; key establishment methodology provides less than 112 bits of encryption strength; non-compliant RSA PKCS #1 v2.1 RSAES-OAEP encryption/decryption RSA (key Key establishment methodology provides between 112 and 128 bit of encryption wrapping) strength. Per IG D.G the module wraps data sent by the requesting application via an API call. Data being wrapped is unknown. PKCS non-approved padding Triple-DES Encryption/Decryption, non-approved algorithm. Note: All the various AES mode (e.g., EAX, XCBC, XTS, etc.) use the same underlying AES implementation as the approved AES cert. The Module implements the approved security functions listed in the table below. Table 7
strength 2024-bit, 3072-bit, 4096-bit, KAS-FFC SP800SP 800-56Arev3. KAS6144-bit, 8192-bit keys 56Ar3/A4653 KAS-2 KAS FFC per IG D.F Scenario providing between 112 and
The Module shall be installed within the operating system confines and structures consistent with Mocana’s operating environment specific documentation. For example: on most linux systems, this means that the libmss.so shared library will be installed in the file system in “/lib” or “/lib64”, or it may be specified in the operating environment specific documentation to be installed in “/usr/local/lib” as appropriate for the target
platform. The Module is automatically started when linked and loaded with an application using the cryptographic functions of the Module. To update or replace the module, all SSPs shall first be zeroized and the calling application shall be closed. SSP zeroization is performed through the Key Destruction service that is described below. API calls will overwrite the memory occupied by the key information with zeros before that memory is de-allocated. If the calling application is terminated prior to zeroization, the Linux kernel overwrites the keys in physical memory before the physical memory is allocated to another process. The key zeroization process is performed in a sufficient time to prevent compromise of SSPs, taking only a few milliseconds. The previous existing module files shall be removed prior to following the installation directions above, for the new module version. (RSA) The calling application of the Module must generate RSA key pairs of at least 2048 bits to operate in approved mode. (ECC) The calling application of the module must generate ECC keys using a P-Curve with a security strength of at least 112 bits to operate in the approved mode of operation.
(Random Number Generation) The Module implements a CTR-based DRBG per SP800-90A for creation of symmetric and asymmetric keys. The Module accepts input from entropy sources external to the cryptographic boundary for use as seed material for the Module's approved DRBGs. External entropy can be added via several APIs available to the cryptographic module client application. The calling application of the Module shall use entropy sources that meet the security strength required for the random bit generation mechanism as shown in NIST SP 800-90A Table 3 (CTR_DRBG). A minimum of 384 bits of entropy must be provided by the calling application. The calling application shall provide full entropy for 256-bit keys. Due to the entropy being provided by an external source, the following caveat applies: There is no assurance of the minimum strength of generated SSPs (e.g., keys). The Module performs DRBG health tests (Instantiate, Generate, Reseed) as defined in section 11.3 of SP800-90A. (Key Management) The application that uses the module is responsible for appropriate destruction and zeroization of the keys. The Module provides API calls for key allocation and destruction. These API calls overwrite the memory occupied by the key information with zeros before that memory is de-allocated. See Key Destruction Service below. (Key/CSP Authorized Access and Use) An authorized application has access to all key data generated during the operation of the Module. (Key/CSP Storage) Private and public keys are provided to the module by the calling process and are destroyed when released by the appropriate API function calls. The module does not perform persistent storage of keys. (Key/CSP Zeroization) The application is responsible for calling the appropriate destruction functions from the API. These functions overwrite the memory with zeros and de-allocate the memory. In case of abnormal termination, the Linux kernel overwrites the keys in physical memory before the physical memory is allocated to another process. (Key Destruction Service) A context structure is associated with every cryptographic algorithm available in the Module. Context structures hold sensitive information such as cryptographic keys. These context structures must be destroyed via respective API calls when the application software no longer needs to use a specific algorithm. This API call will zeroize all sensitive information before freeing the dynamically allocated memory. This will occur while the application process is still in memory, but no longer needs the specific algorithm, which protects the sensitive information from compromise. See the Mocana Cryptographic API Reference for additional information.
The Module’s ports and associated defined logical interface categories are listed in Table 8. The module’s logical interface (API) provides logical separation of the input and output interfaces. Table 8
The module is Level 1 and does not implement any Authentication techniques. The Module supports one operator role, Cryptographic Officer (CO). The cryptographic module does not support multiple concurrent users, bypass capability, or a maintenance role. The Cryptographic Officer role is implicitly identified by the service that is requested. Table 9
Roles Service Input Output CO Asymmetric Key Perform key verification with Return of status of OK or error Verification input of (DSA, ECDSA, or condition EdDSA) Public/Private key pairs CO Digital Signature Signature command with input Return of the Digital Signature of (RSA, DSA, ECDSA, or and status of OK or error EdDSA) private key and condition message using RSA, DSA, ECDSA, or EdDSA algorithm Verify command with input of Return of the Valid Signature (RSA, DSA, ECDSA, or Indicator (True or False) and EdDSA) public key and status of OK or error condition signature to be verified by RSA, DSA, ECDSA, or EdDSA algorithm CO Event Logging Install callback function Return status of algorithm is Approved or non-Approved CO Integrity Status Integrity Command to perform Return OK or error condition Integrity Check with no input parameter CO Key Agreement Generate command with input of Return secret shared symmetric random number for DH or key and status of OK or error ECDH algorithm condition CO Key Derivation Derive key material using input Return key material and status of (HMAC) psuedorandom key material to OK or error condition expand into additional key material CO Keyed Message Generate a keyed-hash message Return keyed-hash with status of Digest (CMAC) authentication code using input OK or error condition of AES key and message CO Keyed Message Generate a keyed-hash message Return keyed-hash with status of Digest (GMAC) authentication code using input OK or error condition of AES key and message CO Keyed Message Generate a keyed-hash message Return keyed-hash with status of Digest (HMAC) authentication code using input OK or error condition of HMAC key and message CO Message Authenticate command with Return MAC and status of OK Authentication input of a message, None, and or error condition AAD using CMAC, GMAC, and HMAC algorithm CO Message Digest Hash command with input data Return hash with status of OK or of a message using a SHA-2 or error condition SHA-3 algorithm CO Random Number Generate command with input of Return random number with OK Generation entropy or error condition
Roles Service Input Output CO Self-tests Execute command with input of Return OK or error condition list of CAST tests to be performed CO Show module’s Version command with no input SW Version: xxx and Git versioning parameter repository name information CO Show status Status command with no input Overall status of tests run parameter either OK or error condition CO Symmetric Encrypt command with AES, Return the ciphertext and status Encryption input data, input size, key, key of OK or error condition size, mode of operation Symmetric Decrypt command with AES, Return the plaintext and status of CO Decryption input data, input size, key, key OK or error condition size, mode of operation Zeroize Zeroize command, no input Return OK or an error condition CO parameter
All services implemented by the Module are listed in Table 10 and Table 11 below. The SSPs modes of access shown in Table 10 are defined as:
Access rights Approved Keys to Service Description Security and/or Roles Indicator Keys Functions SSPs and/or SSPs EdDSA Public CO W, E Key Asymmetric Generate and verify Public / RSA Key RSA Key Private Asymmetric key pairs. Generation Private CO W, E Generation and Key Verification Approved RSA Public CO G, R Key Asymmetric Generate and verify Public / DSA Key DSA Key Private Asymmetric key pairs. Generation Private CO G, R Generation and Key Verification Approved DSA Public CO G, R Key DSA Key DSA Verification Private CO W, E Key Approved DSA Public CO W, E Key Digital Perform digital signature DSA DSA Signature generation and digital Signature Private CO W, E signature verification Generation Key functions. Approved DSA DSA Signature Public CO W, E Verification Key Digital Perform digital signature ECDSA ECDSA Signature generation and digital Signature Private CO W, E signature verification Generation Key functions. Approved ECDSA ECDSA Signature Public CO W, E Verification Key Digital Perform digital signature EdDSA EdDSA Signature generation and digital Signature Private CO W, E signature verification Generation Key functions. Approved EdDSA EdDSA Signature Public CO W, E Verification Key
Access rights Approved Keys to Service Description Security and/or Roles Indicator Keys Functions SSPs and/or SSPs Digital Perform digital signature RSA RSA Signature generation and digital Signature Private CO W, E signature verification Generation Key functions. Approved RSA RSA Signature Public CO W, E Verification Key Integrity Status Perform integrity test and N/A N/A CO E N/A return the status Key Agreement Generate a secret key to be DH Key FCC used between two or more Generation Private CO R, G, E parties based on the key- Key agreement protocol FFC Public CO R, G, E Key DH Key FCC Exchange Private CO W, E Key FFC Public CO W, E Key ECC CDH ECC Key CDH Approved CO R, G, E Generation Private Key ECC CDH CO R, G, E Public Key ECC CDH ECC Key CDH CO W, E Exchange Private Key ECC CDH CO W, E Public Key Key Agreement Generate a secret key to be DH Shared DH used between two or more Secret Shared CO R, G Approved parties based on the keySecret agreement protocol
Access rights Approved Keys to Service Description Security and/or Roles Indicator Keys Functions SSPs and/or SSPs Key Agreement Generate a secret key to be ECC CDH ECC used between two or more Shared Secret CDH CO R, G Approved parties based on the key- Shared agreement protocol Secret Key Derivation Extract input key material and HMAC(HMAC) expand into additional keys SHA-1, HMACSHA2-224, 256, -384, HMACKDF -512, psuedor CO W, E Approved HMAC- andom SHA3-224, - Key 256, -384, 512, Shake128, Shake256 Keyed Message Generate a keyed-hash AES-CMAC AES Digest message authentication code CO W, E Approved Key (CMAC) Keyed Message Generate a keyed-hash AES-GMAC AES Digest message authentication code CO W, E Approved Key (GMAC) Keyed Message Generate a keyed-hash HMACDigest message authentication code SHA-1, (HMAC) HMACSHA2-224, 256, -384, -512, HMAC CO W, E Approved HMAC- Key SHA3-224, 256, -384, 512, Shake128, Shake256 Message Hash Generate a SHA-1, SHA-2, or SHA-1, SHA-3 message digest SHA2-224, SHA2-256, SHA2-384, SHA2-512, N/A CO N/A Approved SHA3-224, SHA3-256, SHA3-384, SHA3-512
Access rights Approved Keys to Service Description Security and/or Roles Indicator Keys Functions SSPs and/or SSPs Random Generate and Re-seed random AES-CTR Seed, Number numbers. DRBG Nonce Generation Generation and CO R Approved DRBG Values AES-CTR DRBG DRBG Re- Entropy CO W Approved seed Input Self-tests Initiate self-tests (Software Integrity Check, DRBG KAT, N/A N/A CO R, E Approved SHA-256 KAT, HMAC-SHA-
Show Status Return status of the module state, exit codes, kernel log N/A N/A CO E N/A (dmesg). Show Version Return module version N/A N/A CO E N/A information Symmetric Perform encryption and AES-CBC, Encryption/ decryption on a block of data AES-CTR, Decryption using the shared key AES-ECB, AES AES-CFB, CO W, E Keys AES-OFB, AES-XTS Encryption Approved AES-CBC, AES-CTR, AES-ECB, AES AES-CFB, CO W, E Keys AES-OFB, AES-XTS Decryption Symmetric Perform encryption and Encryption/ decryption on a block of data AES Decryption using shared key and message AES-CCM CO W, E Approved Keys with Message authentication code Digest (CCM) Symmetric Perform encryption and Encryption/ decryption on a block of data AES Decryption using shared key and message AES-GCM CO W, E Approved Keys with Message authentication code Digest (GCM) Zeroize Destroys all SSPs N/A All CO Z Approved SSPs
Table 11
The Module is composed of the following single software component packaged as a shared object (also known as a shared library).
After the CAST test for each algorithm is run, the status of each algorithm CAST test is stored as an array within the FIPS module so that subsequent usage of each algorithm can detect the CAST test for that module has completed successfully and no longer needs to run. If the CAST test fails for an algorithm, then a global CAST status is set to a failure code and subsequent calls to FIPS cryptographic functions will fail. The FIPS module provides an API to allow the Cryptographic Officer to initiate the FIPS powerup selftests on demand. This includes all CAST tests. Additionally, an API is provided to enable the Cryptographic Officer to persist the state of these self-tests. The state of the self-test is stored in the mssp.bin file. During Module startup, the presence of the previously saved state of self-tests is detected. If the saved-state is more recent than the O/S boot time, then the saved state information for the self-tests is loaded as the starting state. This will enable a cryptographic officer to execute a single run of all conditional self-tests after each boot of the operating system, and subsequent applications using the same Module will not have to re-run the conditional self-tests. Note that the Pre-Integrity Check Power up Self Tests, and Integrity Check described above are always run within each instance of the Module.
The Module has a modifiable operational environment under the FIPS 140-3 definitions. The tested operational environments - Software are listed in Table 2 above. In addition, Mocana claims that the Module can be ported on the Operational Environment(s) listed in Table 3; no statement is made regarding the correct operation of the Module on the Vendor Affirmed Operational Environments.
The FIPS 140-3 Physical Security requirements are not applicable because the Mocana Cryptographic Suite B Module is software only.
The Module does not implement any mitigation method against non-invasive attacks.
The SSPs access methods are described in Table 12 below: Table 12
Method Description G9 EC Diffie-Hellman shared secret generation using the internal CAVP validated 56Arev3 protocol S1 Only stored in volatile memory (RAM). E1 Input in plaintext (client key) E2 Output in plaintext E3 Output in plaintext public key Z1 Zeroized by the Key destruction service by overwriting with a fixed pattern of zeros. All SSPs used by the Module are described in this section. All usage of these SSPs by the Module is described in the services detailed in Section 4.2. Table 13
KAS G3 E1 N/A S1 Z1 during ECC CDH
key agreement protocol ECC CDH 112 to KAS N/A E1 G9 S1 Z1 Shared secret Shared Secret 256 bits computation Used to derive the secret session key ECC CDH 112 to KAS G3 E1, E2 N/A S1 Z1 during ECC CDH Public Key 256 bits key agreement protocol DRBG 384 bits CTR N/A E1 N/A S1 Z1 Used to seed the Entropy Input for 384 DRBG DRBG for key entropy generation bits
Key/SSP Strength Security Gener- Import Establish- Storage Zeroiza Use & Related Name/Type Function ation /Export ment -tion keys and Cert. Number Seed, Nonce 384 bits CTR G2 N/A N/A S1 Z1 Used by the and DRBG for 384 DRBG DRBG to generate values entropy random bits bits RSA Private 112 to RSA G1, G5 E1, E2 N/A S1 Z1 Used to create Key 256 bits RSA digital signatures RSA Public 112 to Used to verify RSA G5 E1, E3 N/A S1 Z1 Key 256 bits RSA signatures DSA Private 112 to DSA G1, G4 E1, E2 N/A S1 Z1 Used to create Key 128 bits DSA digital signatures DSA Public 112 to N/A Used to verify DSA G4 E1, E3 S1 Z1 Key 128 bits DSA signatures ECDSA 112 to ECDSA G1, G6 E1, E2 N/A S1 Z1 Used to create Private Key 256 bits ECDSA digital signatures ECDSA 112 to N/A Used to verify ECDSA G6 E1, E3 S1 Z1 Public Key 256 bits ECDSA signatures EdDSA 128 to EdDSA G1, G7 E1, E2 N/A S1 Z1 Used to create Private Key 224 bits EdDSA digital signatures EdDSA 128 to N/A Used to verify EdDSA G7 E1, E3 S1 Z1 Public Key 224 bits EdDSA signatures AES Keys 128 to AES G1 E1 N/A S1 Z1 Used during AES
256 bits encryption,
decryption, CMAC and GMAC operations HMAC Key 112 to HMAC G1 E1 N/A S1 Z1 Used during
256 bits HMAC-SHA-1,
HMAC-SHA-224, 256, 384, 512, HMAC-SHA3224, 256, 384, 512 operations HMAC-KDF 112 to HMAC- G1 E1 N/A S1 Z1 Used in deriving Psuedorando 256 bits KDF other keys per SP m Key 800-108 with HMAC-SHA2224, 256, 384, 512, HMACSHA3-224, 256, 384, 512 operations
Table 14
The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests.
Security Level 1 - Pre-operational self-tests are available on demand by power cycling or reloading the Module into memory. The Module is available to perform services only after successfully completing the pre-operational self-tests. The Module performs the following pre-operational self-tests: Table 15
The Module performs the following conditional self-tests: Table 16
* HMAC-SHA-256 instantiation: This CAST is performed before the Software Integrity Check. This is the third KAT performed. HMAC-SHA3 KAT Calculate a cryptographic hash-based authentication on ES2 data for SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE-128, SHAKE-256 HMAC-KDF- KAT Extract and expand the input key into additional keys ES2 SHA using SHA-1, SHA-224, -256, -384, -512 HMAC-KDF- KAT Extract and expand the input key into additional keys ES2 SHA3 using SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE-128, SHAKE-256 SHA KAT Calculate a cryptographic hash function on the data for ES2 SHA-1, SHA-224, SHA-256*, SHA-384, SHA-512 * SHA-256 instantiation: This CAST is performed before the Software Integrity Check. This is the second KAT performed. SHA3 KAT Calculate a cryptographic hash function on the data for ES2 SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE-256 Triple-DES CBC KAT 3-key Triple-DES encryption and decryption tested using ES2 a 192-bit key RSA KAT 2048-bit RSA PKCSv1.5 with SHA-224 - no hash - ES2 Signature Generation and Signature Verification RSA PCT RSA Pairwise Consistency Test Signature Generation and ES3 Signature Verification RSA KAT 3072-bit RSA Encryption and Decryption per IG D.G. ES2
The self-tests error states and status indicator are described in table below: Table 17
Installation is performed by placing the module in the target file system during the OEM or ISV’s manufacturing process. The module initialization is performed automatically by the operating system’s loader when a calling application is loaded into memory. Operation of the module is controlled by the calling application’s use of the module’s API functions. There is no specific guidance for Administrator or non-Administrators. The module is provided with supporting documentation which includes an API Reference document and Operating Environment document.
The Cryptographic Officer will install the Module and associated signature of the Module into the proper location within the computer system. For example, the shared memory library and signature file may be installed in the /usr/local/lib directory, which is protected by Linux access control mechanisms. The Module is protected from modification by the integrity self-test performed during start-up. The Module is initialized by the operating system upon loading the Module into memory for use by calling applications. The Module must be operated in the approved mode to ensure that FIPS 140-3 validated cryptographic algorithms and security functions are used.
The Module does not implement any mitigation method against other attacks beyond the requirements for FIPS 140-3 Level 1 cryptographic modules.
The following standards are referred to in this Security Policy. Table 18
Abbreviation Full Specification Name [132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, Part 1: Storage Applications, December 2010 [133] NIST Special Publication 800-133, Recommendation for Cryptographic Key Generation, Revision 2, June 2020 [135] National Institute of Standards and Technology, Recommendation for Existing Application-Specific Key Derivation Functions, Special Publication 800-135rev1, December 2011. [186] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-4, July 2013. [197] National Institute of Standards and Technology, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 26, 2001 [198] National Institute of Standards and Technology, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Processing Standards Publication 198-1, July, 2008 [180] National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards Publication 180-4, August, 2015 [202] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, FIPS PUB 202, August 2015 [38A] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation, Methods and Techniques, Special Publication 800-38A, December 2001 [38B] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Special Publication 80038B, May 2005 [38C] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, Special Publication 800-38C, May 2004 [38D] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, Special Publication 800-38D, November 2007 [38E] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices, Special Publication 800-38E, January 2010 [38F] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, Special Publication 800-38F, December 2012 [56Ar3] NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 [56Br2] NIST Special Publication 800-56B Revision 2, Recommendation for Pair-Wise Key Establishment Schemes Using Finite Field Cryptography, March 2019
Abbreviation Full Specification Name [56Cr2] NIST Special Publication 800-56C Revision 2, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, August 2020 [67] National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Special Publication 800-67, May 2004 [90A] National Institute of Standards and Technology, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Special Publication 800-90A, Revision 1, June 2015. [90B] National Institute of Standards and Technology, Recommendation for the Entropy Sources Used for Random Bit Generation, Special Publication 800-90B, January 2018. Table 19
Acronym Definition KAT Known Answer Test KDF Key Derivation Function KVM Kernel-based Virtual Machine PAA Processor Algorithm Acceleration PCT Pair-wise Consistency Test RNG Random Number Generator RSA Rivest, Shamir and Adleman Algorithm SHA Secure Hash Algorithm SHS Secure Hash Standard SO Shared Object TDES Triple-DES XTS XEX-based Tweaked-codebook mode with ciphertext Stealing