wolfCrypt

Certificate

Approved Algorithms (41)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for wolfCrypt
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>UnAuth Block Cipher<br/>Self-test<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>library named: wolfssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>linux<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I3["Some services may process<br/>input 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"]
    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"]
    E3["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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for wolfCrypt
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>UnAuth Block Cipher<br/>Self-test<br/>Show Status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>library named: wolfssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>linux<br/>kernel<br/>application</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 C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

wolfSSL Inc. wolfCrypt Document Version 1.6

Edmonds, WA 98020 wolfSSL.com +1 425.245.8247 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

This document defines the Security Policy for wolfSSL Inc. wolfCrypt cryptographic module, security levels as described in section 1.2 below.

In accordance with AS02.05, [ISO19790] §7.7 Physical Security is optional and does not apply wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 2: Legend of Terms and references that appear in this document

TOEPP: The platform(s) used for testing are documented in Table 6: Tested Operational Environments - Software, Firmware, Hybrid. If the onboard CPU of a tested platform supported a known PAA [FIPS 140-3 IG 2.3.C] and was desirable for FIPS use, then in accordance with [FIPS 140-3 IG2.3.C] that platform was tested both with and without PAA unless an identical or similar platform had already been tested. When an identical or similar platform was already tested, the new platform was tested only with PAA. This is reflected by the column PAA/PAI in table 6 as marked with a Yes or No entry. The Intel and AMD AESNI (AES New Instructions) are known PAA(s). The Module is a cryptography software library. The Module is a Multi-Chip Stand Alone embodiment. The Module is intended for use by U.S. and Canadian Federal agencies in addition to any other markets that require FIPS 140-3 validated cryptographic functionality. The Module was originally designed with embedded and IoT in mind. As a side effect of this design, it also scales exceptionally well on larger desktop and server systems allowing more connections per box than similar competing solutions. The Module version under validation is Software Version v5.2.1. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Figure 1 depicts the Module operational environment, with the software module cryptographic boundary highlighted in red inclusive of all Module entry points (API calls). The Module is defined as a Software module per AS02.03. No components are excluded from [140-3] requirements. The pre-operational approved integrity test is performed over all components of the cryptographic boundary. Updates to the Module are provided as a complete replacement in accordance with AS04.27

• AS04.35. Figure 1: Module Block Diagram Table 3: Source Files The source code files listed in Table “Source Files” result in the corresponding object files that comprise the wolfCrypt module boundary on each supported operating environment; the extensions of the object file can differ across environments.

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): wolfSSL Inc. Public Material
• May be reproduced only in its original entirety (without revision).

wolfssl-5.6.3commercial-fipslinuxv5.2.1.7z Table 4: Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: Tested Operational Environments - Software, Firmware, Hybrid: 4.0 8.9 wolfSSL Inc. Public Material
• May be reproduced only in its original entirety (without revision).

2.1 2.1 2.1 2.1 2.1 2.1 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

2.1 2.1 2.1 Table 5: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: The Module conforms to [140-3 IG] 2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI). The Intel Processor AES-NI functions are identified by [140-3 IG] 2.3.C as a known PAA. No vendor affirmed operational environments are claimed for this validation of the module.

N/A the module does not support excluded components. Modes List and Description: wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

(2) Table 6: Modes List and Description Each time the module is power cycled or reloaded all CAST status are initialized to FIPS_CAST_STATE_INIT. Each algorithm invocation includes a check of the algorithms CAST status; if the CAST status is CAST status will be updated to either FIPS_CAST_STATE_SUCCESS (if it passes) or FIPS_CAST_STATE_FAILURE (if it fails). See degraded mode for when a CAST status fails. To check the modules overall status at any time the cryptographic officer may use the Show Status service by calling wolfCrypt_GetMode_fips() this will return either: FIPS_MODE_INIT (0) - Module is currently running its’ pre-operational self-test in another thread (multi-threaded) FIPS_MODE_NORMAL (1) - Module in normal mode of operation without errors To check the CAST state of any algorithm the cryptographic officer may use the Show Status Service by calling wc_GetCastStatus_fips(<algorithm type>) where algorithm type can be any of the following:

• FIPS_CAST_AES_CBC FIPS_CAST_AES_GCM FIPS_CAST_HMAC_SHA1 FIPS_CAST_HMAC_SHA2_256 FIPS_CAST_HMAC_SHA2_512 FIPS_CAST_HMAC_SHA3_256 FIPS_CAST_RSA_SIGN_PKCS1v15 FIPS_CAST_ECC_PRIMITIVE_Z FIPS_CAST_DH_PRIMITIVE_Z FIPS_CAST_KDF_TLS12 FIPS_CAST_KDF_TLS13 FIPS_CAST_KDF_SSH The returned status indicator of wc_GetCastStatus_fips(<algorithm type>) may be checked against any of the following states: wolfSSL Inc. Public Material
• May be reproduced only in its original entirety (without revision).

• FIPS_CAST_STATE_INIT (0) - CAST hasn't run yet FIPS_CAST_STATE_PROCESSING (1) - CAST is running FIPS_CAST_STATE_SUCCESS (2) - CAST has passed previously FIPS_CAST_STATE_FAILURE (3) - CAST has failed Degraded Mode Description: The Module implements a degraded mode of operation: when a CAST fails, the module enters an error state. The algorithm CAST status is set to FIPS_CAST_STATE_FAILED and the module runs all CASTS prior to the first operational use of any algorithm, regardless of the CAST having passed previously. Before exiting the error state, the module status (reported in the Show Status service) is set to FIPS_MODE_DEGRADED. Upon exiting the error state, the module enters the degraded mode of operation. This sequence of events is in accordance with AS02.26. The algorithm that failed its’ CAST initially triggering the error state will no longer be available for use in degraded mode of operation and any algorithms that depend on that algorithm will also be unavailable for use. See Table 16: Conditional Self-Tests in section 10.2, column Conditions to see if a CAST failure will affect use of another algorithm. To recover from degraded mode of operation CO shall power cycle or reload the module (equivalent to a power cycle).

Approved Algorithms: wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA3224 HMAC-SHA3256 HMAC-SHA3384 HMAC-SHA3512 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 7: Approved Algorithms NOTE: Only the algorithms specified in this section are supported by the module in approved mode of operation. No operational use of an algorithm may be performed until the corresponding CAST has passed. Vendor-Affirmed Algorithms: CKG1 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

CKG2 CKG3 Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. The Module does not implement non-approved algorithms. The services listed in this Security Policy include all cryptographic and non-cryptographic functionality. NOTE: For TLS 1.2 KDF Extended master-secret shall be used in approved mode of operation. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA3224 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

HMAC-SHA3384 HMAC-SHA3512 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

AsymKeyPairKeyGen AsymKeyPairKeyGen AsymKeyPairPubKeyVal AsymKeyPairDomPar AsymKeyPairKeyVer AsymKeyPairKeyGen AsymKeyPairDomPar HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA3224 HMAC-SHA3256 HMAC-SHA3384 HMAC-SHA3512 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

DigSigSigVer:1024 DigSigSigVer:SHA-1 DigSigSigVer:P-192 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 9: Security Function Implementations

The conditions for using the Module in the Approved mode of operation are:

1. The Module is a cryptographic library and it is intended to be used with a calling application. The calling application is responsible for the usage of the primitives in the correct sequence including the IVs and sessions.
2. The keys used by the Module for cryptographic purposes are determined by the calling application. The calling application is required to provide keys in accordance with [140Drev2].
3. With the Module installed and configured in accordance with [UG] instructions, only the algorithms listed in the table in Section 2.5 are available. The module is in the Approved mode if the following conditions for algorithm use are met. NOTE: All conditions and restrictions below are met when the executable binary is built in accordance with the UG instructions. Applications that would be at risk of violating any restriction in this section will fail to build and link successfully against the compliant module binary executable. a. Adherence to [140-3 IG] C.H Key/IV Pair Uniqueness Requirements from SP 800-38D. The Module supports both internal IV generation (for use with the [56Arev3] compliant KAS API entry points) and external IV generation (for TLS KAS usage). For internal IV generation, the Module complies with C.H 2, users MUST specify an IV length of GCM_NONCE_MID_SZ or greater for internal IV generation otherwise specifying any length less than 96-bits is rejected by the module. For internal IV generation, C.H requires the calling application to use the modules internal approved DRBG to generate the random IV For external IV generation, the Module complies with C.H 1 (a), tested per option (ii) under C.H TLS protocol IV generation. The module wolfSSL Inc. Public Material – May be reproduced only in its original entirety (without revision).

performs a check for nonce_explicit rollover, returning an error if that condition is encountered. b. ECDSA and RSA signature generation must be used with a SHA-2 or SHA-3 hash function. c. RSA signature generation and encryption primitives must use RSA keys with k = 2048,

d. The calling process shall adhere to all current [131Arev2] algorithm usage restrictions.

4. Manual key entry is not supported.
5. Data output is inhibited during self-tests, zeroization, and error states.
6. RSA Decrypt Primitive (RSADP) with k=2048-bit is the only CAVP testable aspect of [56Brev2]. The module implements the RSA primitive operations only, there are no claims of key transport. The module implements ‘RSA Encrypt Primitive’ (RSAEP) and RSADP. The vendor affirms conformance to [56Brev2] for RSAEP and RSADP with other key sizes since no CAVP test is available for key sizes other than 2048-bit.

N/A for this module. N/A for this module.

The Module conforms to [140-3 IG] D.C References to the Support of Industry Protocols: while the module provides [56A] conformant schemes and API entry points oriented to TLS and SSH usage, the Module does not contain the full implementation of TLS or SSH. The following statements are required per IG D.C case #2: No parts of the TLS protocol other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. No parts of the SSH protocol other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

The Module design corresponds to the Module security rules. Security rules enforced by the Module are described in the appropriate context of this document. wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 10: Ports and Interfaces Table 7 defines the Module’s [140-3] logical interfaces; the Module does not interact with physical ports.

Table 11: Roles The Module supports the Cryptographic Officer (CO) operator role, and does not support multiple concurrent operators, a maintenance role or bypass capability. The cryptographic module does not provide an authentication or identification method of its own. The CO role is implicitly identified by the service requested.

n wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

n 0) 0) e) 0) n 0) W,E,Z W,E,Z e: G,R,Z c: G,R,Z e: W,E,Z : W,E,Z G,R,Z R,E,Z W,E wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

n 0) 0) 0) 0) 0) W,E,Z G,E G,E W,E,Z G,Z E E,W wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

n generalpurpose Table 12: Approved Services 0) 0)

0. Z e: Z e: Z Z Z Z Z Z Z All services implemented by the Module are listed in Table
1. The calling application may use the Show status service (wolfCrypt_GetStatus_fips call) to determine the status of the Module. A return code of FIPS_MODE_NORMAL means the Module is in a state without errors; Please see Section 2.4 for more information. In addition, as per [140-3 IG] 2.4.C the module supports an implicit indicator via the successful completion of a service, module does not support nonapproved services. wolfSSL Inc. Public Material – May be reproduced only in its original entirety (without revision).

See the wolfCrypt FIPS 140-3 User Guide [UG] for additional information on the cryptographic services listed in this section. Note that the caller provides the KAS_Private and KAS_Public keys for shared secret computation; the caller’s exchange and assurance of PSPs with the remote participant is outside the scope of the Module. For services Generate Key Pair, Key Agreement and Key Derivation consistent with [140-3 IG] 9.5.A, available only if the private_key_read_enable property is set to TRUE

The Module uses HMAC-SHA2-256 with a 256-bit key (HMAC Cert. #A4308) as the approved integrity technique. Before the integrity technique is executed the module performs an HMACSHA2-256 KAT.

The operator can initiate the integrity test on demand by reloading the Module or by calling the API wolfCrypt_IntegrityTest_fips() at any time after power on. (See Section 10.5 “Operator Initiation of Self-Tests” later in this document for details of proper use of this API in an application).

While the module is not “open source” since it is only shipped under a commercial license, open source practice of source code delivery with a commercial license is standard for the module. As such the module (while not required to do so) will abide by ISO/IEC 19790:2012 B.2.5. Please see details in the wolfCrypt FIPS 140-3 User Guide [UG] for the [OE] listed on the FIPS certificate. Details will include information about compiler, compiler configuration settings and methods to compile the source code into an executable form in a FIPS validated manner. See also section 11.1 Installation, Initialization, and Startup Procedures later in this document.

Type of Operational Environment: Modifiable wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Any setting that affects the module directly while compiling the executable binary shall not be used. If unsure contact wolfSSL Inc. by sending email to “support at wolfssl dot com”. A wolfSSL engineer will review the setting for impact on the FIPS validated sources and determine if the setting is allowed or disallowed for an approved mode of operation. NOTE: The User Guide [UG] will contain an exact list of allowed settings. CO should refer to the [UG] first before contacting wolfSSL support.

The operational environment for the Module is modifiable. Table 6 lists the operational environments on which the Module was tested. Specification of the security rules, settings or restrictions to the configuration of the operational environment are covered in the [UG]. The configure script provided with the package detects the environment and sets the required flags. There are no specific restrictions to the configuration of the operational environment unless stated in the [UG].

The Module does not implement non-invasive security mechanisms.

wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 14: SSP Input-Output Methods

9.7.B Table 15: SSP Zeroization Methods The module supports an implicit Zeroisation indicator. The implicit indicator is a successful completion of the service call. h 6-4) wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

e h 6-4) 6-4) 6-4) 6-4) 6-4) wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

c e DiffieHellman c DiffieHellman h 6-4) 6-4) KASECCSSC Sp80056Ar3 KASFFCSSC Sp80056Ar3 KASECCSSC Sp80056Ar3 KASFFCSSC Sp80056Ar3 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

h KASECCSSC Sp80056Ar3 KASFFCSSC Sp80056Ar3 AESCMAC AESGMAC HMACSHA-1 HMACSHA2224 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

nonce (128bit) h SHA2256 HMACSHA2384 HMACSHA2512 HMACSHA3224 HMACSHA3256 HMACSHA3384 HMACSHA3512 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

C V C. V is 440bits, C is d check selftest h AESCBC AESCCM AESCTR AESECB AESGCM AESOFB HMACSHA2256 HMACSHA2256 Table 16: SSP Table 1 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 17: SSP Table 2 * Per SP800-131Ar2 Section 3, Table 2, key sizes (1024-bit for RSA and 192-bit for ECC) are available for legacy use verification requirements when inter-oping with legacy systems. These key sizes shall not be used for signing operations.

wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

HMACSHA2-256 Table 18: Pre-Operational Self-Tests Each time the Module is powered on or loaded (equivalent to a power on) the integrity of the module is tested per ISO/IEC 19790:2012 Section 7.10.2.2. The very first step of the preoperational self-test (POST) is to force every Conditional Algorithm Self-Test to be in the FIPS_CAST_STATE_INIT mode meaning the CAST for a given algorithm has not run since power on and the CAST must run and pass prior to operational use of the algorithm. The integrity test uses HMAC-SHA2-256 to ensure the modules integrity therefore per AS 10.20 HMAC CAST is triggered prior to the integrity check. The HMAC CAST uses a known answer test per ISO/IEC 19790-2012 Section 7.10.3.2. The POST executes outside user control as the module is powering on or being loaded.

AESCBC AESCBC e T T s) AESECB, AESCBC, AESCTR, AESOFB, AESGCM, AESGMAC, AESCCM or AESCMAC wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

e AESGCM T AESGCM T HMACSHA1 length: 20bytes T HMACSHA2256 T s) AESECB, AESCBC, AESCTR, AESOFB, AESGCM, AESGMAC, AESCCM or AESCMAC s) AESGCM or AESGMAC s) AESGCM or AESGMAC or HMACSHA1 s) wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

e HMACSHA2512 T HMACSHA3256 T RSAPKCSv 1.5 T HMACSHA224 or HMACSHA256 s) HMACSHA384 or HMACSHA512 s) SHA3224, SHA3256, SHA3384 or SHA3512, HMACSHA3224, HMACSHA3256, HMACSHA3384 or HMACSHA3512 wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

RSAPKCSv 1.5 e T T DiffieHellman T T T HMACSHA2-256 T HMACSHA2-256 T n n DiffieHellman wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

e T RSAPCT ECCPCT DHPCT T with subelements: Table 19: Conditional Self-Tests Once the module is powered on and has passed the POST, calls to any cryptographic algorithm will trigger the CAST on first operational use of the algorithm. The POST and CASTS are available on demand after power on and can be executed by the cryptographic officer (CO) at any time. The CO may optionally invoke any CAST ahead of algorithm use at a more convenient time rather than letting it run automatically on first use. Regardless of the CAST running manually or automatically, once it has passed the CO may manually re-run any CAST at any time in a periodic fashion, a CAST will no longer run automatically after it has passed the first time. wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2512 HMAC-SHA3256 ECC DiffieHellman FFC DiffieHellman Table 20: Pre-Operational Periodic Information Table 21: Conditional Periodic Information wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 22: Periodic Method Descriptions

HMACSHA2256 AESCBC AESGCM HMACSHA1 HMACSHA2256 HMACSHA2512 HMACSHA3256 RSAPKCSv1 .5 DiffieHellman d (3) wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

DiffieHellman RSAConsistency Test ECCPCT Table 23: Error States d selftest selftest selftest wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

For calling applications the following is required:

1. Include the library configuration header wolfssl/options.h (or user_settings.h via wolfssl/wolfcrypt/settings.h) first.
2. After including the library configuration header, include wolfssl/wolfcrypt/fips_test.h then use the API specified below to execute a given self-test. CO may initiate all CAST self-tests in one-shot. The API wc_RunAllCast_fips() is provided as a public API to applications using the module that have included the headers above in proper order. CO may initiate CAST self-tests individually using the API wc_RunCast_fips(algorithm type) with any of the below “algorithm type” inputs: • • • • • • • • • • • • • • FIPS_CAST_AES_CBC FIPS_CAST_AES_GCM FIPS_CAST_HMAC_SHA1 FIPS_CAST_HMAC_SHA2_256 FIPS_CAST_HMAC_SHA2_512 FIPS_CAST_HMAC_SHA3_256 FIPS_CAST_DRBG FIPS_CAST_RSA_SIGN_PKCS1v15 FIPS_CAST_ECC_PRIMITIVE_Z FIPS_CAST_DH_PRIMITIVE_Z FIPS_CAST_ECDSA FIPS_CAST_KDF_TLS12 FIPS_CAST_KDF_TLS13 FIPS_CAST_KDF_SSH CO may re-run the POST at any time after power on using the public API wolfCrypt_IntegrityTest_fips(). This function always returns a value of zero regardless if the integrity check passed or failed so the CO shall then check the status of the module using the API wolfCrypt_GetStatus_fips(). The return value of the GetStatus API shall then be checked against the status indicators below: • • • FIPS_MODE_INIT status indicator value is
3. This indicator means then integrity test has not completed and is likely running in another thread (multi-threaded) FIPS_MODE_NORMAL status indicator value is
4. This indicator means the integrity test passed and the module is in a state without errors FIPS_MODE_FAILED status indicator value is
5. This indicator means the integrity test failed and the module is unusable. The CO shall power cycle or reloaded (equivalent to power cycle) to restore the module.

wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).

The CO shall use the provided wolfCrypt FIPS 140-3 User Guide hereafter referred to as [UG]. A common name for this document is also the Cryptographic Officer Guidance Manual [COGM]. [UG] and [COGM] are one and the same for this module and include all administrative guidance. The [UG] will have a section specific to each Operational Environment [OE] that appears on the modules FIPS certificate and/or in Table 6: Tested Operational Environments - Software, Firmware, Hybrid. The instructions provided in the [UG] shall be followed or the module will never have been properly initialized and built and therefore non-compliant. To create the compliant module, as per this Security Policy, the configuration steps shall be followed.

• [UG] will include library configuration settings that are: required, allowed and not allowed.
• For any setting that is not specifically covered the CO shall contact wolfSSL by emailing “support at wolfssl dot com” for clarification about that settings impact on compiling the compliant module.
• [UG] will include details about the toolchain, compiler, compiler configuration settings and methods to compile the source code into an executable form.
• While the module is not “open source” since it is only shipped under a commercial license, open source practice of source code delivery with a commercial license is standard for the module. As such the module (while not required to) will abide by ISO/IEC 19790:2012 B.2.5 “If the module is open source, specify the compilers and control parameters required to compile the code into an executable format” even though the module is not claiming “open source”. The following initialization instructions apply to all use-cases for the module generically by a consuming application. [OE] specific details will be covered in the [UG].
• When planning on using the module the CO shall first include the library settings headers so the application knows how the library was configured.
• On Unix or Linux like systems where auto-tools were used to configure the library (./configure && make) the CO shall include wolfssl/options.h as the very first header.
• When working with IDEs or Makefile setups the CO shall include wolfssl/wolfcrypt/settings.h as the very first header and ensure that the define WOLFSSL_USER_SETTINGS is set globally at the project level. No other wolfSSL specific build options should be set globally, all configurations will be managed by a custom user_settings.h header that is included anytime WOLFSSL_USER_SETTINGS is defined globally.  Once the library configuration settings have been included only then shall the CO include other wolfSSL headers as needed, any other headers shall always come after the configuration settings header.
• Upon entry into main() of an application the vendor recommends that the CO first register a fips callback. The fips callback will trigger anytime the module is in an unusable state. A sample of such a callback is provided below. static void myFipsCb(int ok, int err, const char* hash) { printf("in my Fips callback, ok = %d, err = %d\n", ok, err); wolfSSL Inc. Public Material
• May be reproduced only in its original entirety (without revision).

printf("message = %s\n", wc_GetErrorString(err)); printf("hash = %s\n", hash); if (err == IN_CORE_FIPS_E) { printf("In core integrity hash check failure," "copy above hash\n"); printf("into verifyCore[] in fips_test.c and rebuild\n"); } } Figure 2: Code Sample A If using a FIPS callback the CO will register the FIPS callback by passing the function pointer of the FIPS callback function to the following API like so: wolfCrypt_SetCb_fips(myFipsCb); Prior to operational use of the module the CO shall register an entropy callback to load entropy into the module from an external entropy source. A portable callback is available but must be registered by the application on startup since the entropy source is external to the module. To register the portable callback provided with the module the application will call “ret = wc_SetSeed_Cb(wc_GenerateSeed);” where “ret” is an integer to capture the status return of the call and should be checked against the value 0 for success or < 0 for failure. A successful register of any entropy callback function is considered the first operational use of the module outside of pre-operational tests and the DBRG CAST will run during registration of the callback. When working with a private key the application must programmatically unlock access to private key material with the API: wolfCrypt_SetPrivateKeyReadEnable_fips(true/false, key-type).

• To unlock key access pass true (1) as the first input. CO shall pass WC_KEYTYPE_ALL as the second input parameter.
• Once done working with the private key CO shall lock access to private key materials before resuming operations by calling the same API with input false (0) as the first parameter and WC_KEYTYPE_ALL as the second input parameter. o

The CO shall use the provided wolfCrypt FIPS 140-3 User Guide [UG].

The Module supports the Cryptographic Officer (CO) operator role and does not support nonadministrators or non-administrative roles.

Please defer to wolfCrypt FIPS 140-3 User Guide [UG].

The module does not claim mitigation of other attacks. wolfSSL Inc. Public Material

• May be reproduced only in its original entirety (without revision).