| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software |
| Embodiment | Multi-Chip Stand Alone |
| Status | Historical |
| Caveat | Interim validation. When operated in approved mode. No assurance of the minimum strength of generated SSPs (e.g., keys) |
| Vendor | DigiCert, Inc. |
flowchart LR
%% Deterministic review-risk graph for Mocana Cryptographic Loadable Kernel 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 Loadable Kernel 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 Loadable Kernel Module Version 7.0.0f Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.1 Date: August 01, 2024 DigiCert, Inc.
| # | 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 | 5 |
| Table 4 – Approved Algorithms | 8 |
| Table 5 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation | 10 |
| Table 6 – Ports and Interfaces | 13 |
| Table 7 – Roles, Service Commands, Input and Output | 14 |
| Table 8 – Approved Services | 15 |
| Table 9– Non-Approved Services | 16 |
| Table 10 – SSP Management Methods | 19 |
| Table 11– SSPs | 20 |
| Table 12 – Non-Deterministic Random Number Generation Specification | 21 |
| Table 13 – Pre-Operational Self-Test | 21 |
| Table 14 – Conditional Self-Tests | 22 |
| Table 15 – Error States and Indicators | 23 |
| Table 16 – References | 24 |
| Table 17 – Acronyms and Definitions | 25 |
| Figure 1 – Cryptographic Module Interface Design | 6 |
| Figure 2 – Logical Object | 7 |
| Figure 3 - Code Example for Self-Test | 18 |
Module version 7.0.0f 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 1 module. 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 only, 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 kernel object (KO), moc_crypto.ko and associated signature file. 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 Cryptographic Module is tested on the following operational environment(s): Table 2
1 Yocto Linux 3.1 Xerox Explorer 6.5 Intel Atom E3950 without PAA NA
2 Yocto Linux 3.1 Xerox Explorer 8.0 Intel Atom x6413E without PAA NA
3 Yocto Linux 3.1 Xerox Alexandra ARM Cortex A53 without PAA NA
(64-bit) Platform 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
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 kernel module, (moc_crypto.ko) and the integrity check signature file (moc_crypto.ko.sig). 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:
Keys and CSPs shall not be shared between the approved and non-approved mode of 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 and Mode/Method Description / Key Size(s) / Use / Function Cert Standard Key Strength(s) Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA-224 increment 8 KDF MAC = 32–224 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA-256 increment 8 KDF MAC = 32–256 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA-384 increment 8 KDF MAC = 32–384 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA-512 increment 8 KDF MAC = 32–512 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA3-224 increment 8 KDF MAC = 32–224 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA3-256 increment 8 KDF MAC = 32–256 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA3-384 increment 8 KDF MAC = 32–384 increment 8 Key Sizes: Key Length = 112-65536 Message Authentication, A845 HMAC [198] SHA3-512 increment 8 KDF MAC = 32–512 increment 8 HMAC-SHA-1, SHA2-(224, 256, 384, 512, SHA3-(224, A845 KBKDF [108] Feedback 256, 384, 512) Key Based Key Derivation 8-bit counter after fixed input data SHA-1, SHA2224, SHA-256, A845 SHS [180] SHA-384, Message Digest Generation SHA-512
CAVP Algorithm and Mode/Method Description / Key Size(s) / Use / Function Cert Standard Key Strength(s) SHA3-224 SHA3-256 SHA3-384 A845 SHA-3 [202] Hash Function SHA3-512 SHAKE 128 SHAKE 256 Note: Other algorithms were tested but not implemented by this module. Note: The module does not have any vendor affirmed algorithms allowed in the approved mode of operation. Note: The module does not have any non-approved but allowed algorithms. Note: The module does not have any non-approved algorithms with no security claimed. Table 5
The Module shall be installed within the operating system confines and structures consistent with Digicert’s operating environment specific documentation. For example: on most linux systems, this means that the moc_crypto.ko kernel module 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. (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: When operated in approved mode. 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 FIPS defined logical interface categories are listed in Table 6
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 7
All services implemented by the Module are listed in Table 8 and Table 9 below. The SSPs modes of access shown in Table 8 are defined as:
Table 8
CO W, E Approved HMAC-SHA3- Key 224, -256, -384, 512, Shake128, Shake256 Message Hash Generate a SHA-1, SHA-2, or SHA-1, SHA2SHA-3 message digest 224, SHA2-256, SHA2-384, SHA2-512, N/A CO N/A Approved SHA3-224, SHA3-256, SHA3-384, SHA3-512 Random Generate and Re-seed Seed, Number random numbers. Nonce AES-CTR DRBG Generation and CO R Approved Generation DRBG Values DRBG AES-CTR DRBG Entropy CO W Approved Re-seed Input
Keys Roles Access Indicator and/or rights Approved SSPs to Service Description Security Keys Functions and/or SSPs Self-tests Initiate self-tests (Software Integrity Check, DRBG N/A N/A CO R, E Approved KAT, SHA-256 KAT, HMAC-SHA-256 KAT) 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, AESEncryption/ decryption on a block of data CTR, AES-ECB, Decryption AES using the shared key AES-CFB, AES- CO W, E Keys OFB, AES-XTS, Encryption Approved AES-CBC, AESCTR, AES-ECB, AES AES-CFB, AES- CO W, E Keys OFB, AES-XTS, Decryption Symmetric Perform encryption and Encryption/ decryption on a block of data AES Decryption with using shared key and message AES-CCM CO W, E Approved Keys Message Digest authentication code (CCM) Symmetric Perform encryption and Encryption/ decryption on a block of data AES Decryption with using shared key and message AES-GCM CO W, E Approved Keys Message Digest authentication code (GCM) All Zeroize Destroys all SSPs N/A CO Z Approved SSPs Table 9– Non-Approved Services Service Description Algorithm Accessed Roles Indicator Key Derivation Extract input key material and HMAC-KDF-SHA1 CO Non-Approved (HMAC) expand into additional keys
Service Description Algorithm Accessed Roles Indicator Keyed Message HMAC generation with key HMAC-SHA1, HMAC-MD5 CO Non-Approved Digest size less than 112 bit; noncompliant Message Digest Generate an MD2, MD4, or MD2, MD4, MD5 CO Non-Approved MD5 message digest Message Digest Generate a SHA-1 message SHA-1 CO Non-Approved digest Random FIPS 186-2 Random Number RNG CO Non-Approved Number Generation Generation Symmetric Non-approved algorithm AES-EAX, AES-XCBC, DES CO Non-Approved Encryption/ Decryption Symmetric AES GCM AES-GCM 64k/GMAC 64k CO Non-Approved Encryption/ encryption/decryption for Decryption 256 implementation Symmetric Non-approved algorithm Triple-DES CO Non-Approved Encryption/ Decryption
The Module is composed of the following single software component packaged as a kernel object.
Figure 3 - Code Example for Self-Test The operator can also explicitly initiate the integrity test on demand by calling the API function: FIPS_StartupSelftestIntegrity(void). Pre-Integrity Check Power up Self Tests: To fulfill the Implementation Guidance 10.3.A, the algorithms used to perform the integrity check are executed before the module integrity check. These are lists in more detail in Table 18 Pre-Operational Self-Test. The following algorithm KAT tests are performed in the FIPS_powerupSelfTest implementation before the integrity check:
Post-Integrity Check Algorithm Self Tests: As a startup optimization, the self-tests for all other approved algorithms are implemented as Conditional Self-Tests (see Table Table 16). These KAT Self-Tests are performed on-demand. This means that the first time an approved algorithm is used, the CAST test for that algorithm is tested before the approved algorithm processing is done.
The Module has a modifiable operational environment under the FIPS 140-3 definitions. The tested operational environments are listed in Table 2 above. In addition, Digicert 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 Cryptographic Module is software only.
The Module does not implement any mitigation method against non-invasive attack.
The SSPs access methods are described in Table 10 below: Table 10
Table 11– SSPs CSP Strengt Security Generation Import Establish Storage Zeroiza- Use / h Functio /Export -ment tion Related (in bits) n / Cert. SSPs DRBG 384 bits CTR N/A E1 N/A S1 Z1 Used to Entropy for 384 DRBG seed the Input entropy DRBG for bits key generation Seed, 384 bits CTR G2 N/A N/A S1 Z1 Used by Nonce for 384 DRBG the DRBG and entropy to DRBG bits generate values random bits AES 128 to AES N/A E1 N/A S1 Z1 Used Keys 256 bits during AES encryption , decryption , CMAC and GMAC operations HMAC 112 to HMAC N/A E1 N/A S1 Z1 Used Key 256 bits during HMACSHA-1, HMACSHA-224, 256, 384, 512, HMACSHA3224, 256, 384, 512 operations HMAC- 112 to HMAC- N/A E1 N/A S1 Z1 Used in KDF 256 bits KDF deriving Psuedora other keys ndom per SP Key 800-108 with HMACSHA2224, 256, 384, 512, HMAC-
CSP Strengt Security Generation Import Establish Storage Zeroiza- Use / h Functio /Export -ment tion Related (in bits) n / Cert. SSPs SHA3224, 256, 384, 512 operations Note: The module does not have PSPs.
Table 12
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 13
The Module performs the following conditional self-tests:
Table 14
The self-tests error states and status indicator are described in table below: Table 15
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 Cryptographic Officer will install the Module and associated signature of the Module into the proper location within the computer system. For example, the kernel module 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 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 16
Abbreviation Full Specification Name [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 [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 17
Acronym Definition CTR Counter Mode DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator DSA Digital Signature Algorithm ECC CDH Elliptic Curve Cryptography Cofactor Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GCM Galois Counter Mode HMAC Hash Message Authentication Code IG Implementation Guidance KAT Known Answer Test KDF Key Derivation Function KO Kernel Object 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 TDES Triple-DES XTS XEX-based Tweaked-codebook mode with ciphertext Stealing