wolfCrypt

Certificate

Approved Algorithms (42)

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"]
    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>Show Status<br/>Self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>DTLS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</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 wolfCrypt
  %% 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>Show Status<br/>Self-test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>DTLS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

wolfCrypt Document Version 1.0 July 9, 2025 wolfSSL Inc.

Suite C-300 Edmonds, WA 98020 wolfssl.com +1 425-245-8247 wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Table of Contents wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt List of Tables List of Figures wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

This document defines the Security Policy for the wolfCrypt cryptographic module by wolfSSL Inc., hereafter denoted the Module. The Module meets FIPS 140-3 overall Level 1 requirements, with security levels as described below.

The Module is a cryptography software library, defined as a software module per AS02.03 with a multi-chip standalone embodiment. The Module is intended for use by U.S. and Canadian Federal agencies in addition to other markets that require FIPS 140-3 validated cryptographic functionality. The Module version under validation is Software Version v5.2.0.1. The package/file name is wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z. Table 1

• Security Levels In accordance with AS02.05, [ISO19790] §7.7 Physical Security is optional and does not apply to the Module. In accordance with current CMVP policy, Non-Invasive Security is not applicable. The Module does not implement attack mitigations outside the scope of [FIPS140-3]. The Module conforms to [FIPS140-3_IG] §D.C References to the Support of Industry Protocols: while it provides [SP800-56Ar3] 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 caveat is required: No parts of the TLS and SSH protocols, other than the approved cryptographic algorithms and KDFs, have been tested byt the CAVP or 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 in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

Figure 1 depicts the Module operational environment with the cryptographic boundary highlighted in red inclusive of all Module entry points (API calls). The physical perimeter of the module is the general purpose computer on which the software module resides. No components are excluded from [FIPS140-3] requirements. The pre-operational approved integrity test is performed over all components of the cryptographic boundary. Figure 1

• Module Block Diagram The source code files listed below 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 the environments.
• aes.c: AES algorithm
• aes_asm.s: AES assembler optimizations (Linux)
• aes_asm.asm: AES assembler optimizations (Windows 10)
• cmac.c: CMAC algorithm
• dh.c: Diffie-Hellman
• ecc.c: Elliptic curve cryptography
• fips.c: Pre-operational entry point and API calls
• fips_test.c: Power on self-tests
• hmac.c: HMAC algorithm
• kdf.c: TLS v1.2, v1.3, and SSH v2 KDFs
• random.c: DRBG algorithm wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy                                                                                wolfCrypt •   rsa.c: RSA algorithm •   sha.c: SHA algorithm •   sha256.c: SHA2-256 algorithm •   sha256_asm.s: SHA2-256 assembler optimizations (Linux) •   sha512_asm.s: SHA2-512 assembler optimizations (Linux) •   sha512.c: SHA2-512 algorithm •   sha3.c: SHA-3 algorithm •   wolfcrypt_first.c: First function marking start of cryptographic boundary •   wolfcrypt_last.c: Last function marking end of cryptographic boundary

The Module supports an Approved mode of operation and a non-Approved mode of operation. Approved algorithms are listed in Table

3. Non-Approved algorithms are listed in Table
4. The Module is a cryptographic library providing primitives used by a calling application. The conditions for using the Module in the Approved mode of operation are:
5. 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.
6. 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 [SP800-140Dr2], and to destroy the key structures via the corresponding Free calls after use.
7. With the Module installed and configured in accordance with [UG] instructions and Section 11 of this document, only the algorithms listed in Table 3 (Approved algorithms) and Table 4 (non-Approved algorithms) are available. The Approved mode of operation is invoked by calling the services listed in Table 7 below. The module operates in the non-Approved mode when the service in Table 8 is invoked. The Module is in the Approved mode if the following conditions for algorithm use are met: a. Adherence to [FIPS140-3_IG] §C.H Key/IV Pair Uniqueness Requirements from SP 800-38D. The Module supports both internal IV generation (for use with the [SP800-56Ar3] compliant KAS API entry points) and external IV generation (for TLS KAS usage). For internal IV generation, the Module complies with C.H scenario 2: users MUST specify an IV length of GCM_NONCE_MID_SZ or greater for internal IV generation (specifying any length less than 96 bits means the Module is no longer in an approved mode of operation). For internal IV generation, C.H requires the calling application to use the Module’s internal approved DRBG to generate the random IV. For external IV generation, the Module complies with C.H scenario 1(a), tested per option (ii) under C.H TLS/DTLS 1.2 protocol IV generation. The Module performs a check for nonce_explicit rollover, returning an error if that condition is encountered. The module is compatible with TLS/DTLS 1.2 protocol and provides the primitives to support the AES-GCM ciphersuites from [SP800-52r2] Section 3.3.1. If the module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re-distributed. This condition is not enforced by the module but is met implicitly. The module does not retain any state across reset or power-cycles: AES-GCM key/IVs are not stored in non-volatile persistent memory (i.e., disk), hence no reconnection can occur without a fresh key establishment operation and the associated SSPs. 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, 3072 or

4096 bits or greater. If RSA uses keys with k < 2048, the module enters the non-Approved mode.

d. The calling process shall adhere to all current [SP800-131Ar2] algorithm usage restrictions. 4. Manual key entry is not supported. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

5. The module does not support a non-compliant state. Once the module is compiled per the build instructions defined in the wolfCrypt FIPS 140-3 User Guide, it is not possible for the module to be in a non-compliant state.
6. Data output and control output are inhibited during self-tests, zeroisation, and error states. The Module obtains the [FIPS140-3_IG] §D.F required key agreement assurances in accordance with [SP80056Ar3] Section 5.6.2. The module complies to [FIPS140-3_IG] §D.F Scenario 2, path 1.

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. The 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 the degraded mode of operation and any algorithms that depend on that algorithm will also be unavailable for use. To recover from the degraded mode operation, the CO shall power cycle or reload the Module (equivalent to a power cycle).

The TOEPP is the General Purpose Computer on which the module is running on. Operational testing was performed for the following modifiable Operational Environments (with no restrictions on operational environments configuration): Table 2

• Tested Operational Environments A unique set of object files was compiled for each operating environment listed above, with a total of four (4) sets. The Module conforms to [FIPS140-3_IG] §2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI). The Intel Processor AES-NI functions are identified by [FIPS140-3_IG] §2.3.C as a known PAA. No vendor affirmed operational environments are claimed for this validation of the Module. wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

The Module implements the Approved and allowed cryptographic functions listed in the table below. Equivalent strength in bits is given for each key or algorithm type (as some algorithms do not use or produce keys). The term s is used throughout to indicate security strength, following the notation used in the majority of the sources (refer to the notes below Table 3). This table is referenced by Table 9 (SSPs). Table 3

• Approved Algorithms wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Note 1: Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in [SP800-57P1r5] Table

3. Note 2: Elliptic curve strengths are annotated as approximate (i.e., s ~=) since [SP800-186] Table 1 provides approximate security strengths. Note 3: Approved elliptic curves for ECC key agreement are given in [SP800-56Ar3] Table
4. Note 4: In Digital Signature applications, security strength is primarily associated with the asymmetric key pair specification. The hash function used must have equivalent strength equal to or greater than the security strength of the associated key pair. Note 5: Approved key types for FFC key agreement are given in [SP800-56Ar3] Tables 25,
5. The group notation of Table 26 is used for consistency with CAVP algorithm listings and ACVP capability registration. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Note 6: Estimated security strengths of common RSA moduli are given in [SP800-56Br2] Table

4. IFC key types approved for Digital Signature Generation and Verification are given also in [SP800-57P1r5] Table
5. Equivalent strengths are annotated as approximate (i.e., s ~=) since [SP800-56Br2] Table 4 provides approximate security strengths. Note 7: Security strength for L=2048/N=256 is determined in accordance with [FIPS140-3_IG] D.B Strength of SSP Establishment Methods as y = min(x, N/2), where x is 112 and therefore y = min(112, 128) = 112. Note 8: The Module is compliant with [FIPS140-3_IG] C.F. extending prime generation and signature generation techniques to the RSA modulus sizes not listed in [FIPS186-4]. With regards to primality testing the Module tests p and q (no auxiliary primes) with 8 rounds of MR Test Only regardless of p and q size. 8 Rounds is three more rounds than the minimum required when p and q are 1024-bits respectively and double the rounds required when p and q are 1536-bits (or greater) respectively. The minimum requirements come from in [FIPS186-5] Table B.1 as related to using a prime generation method that does not rely on the use of auxiliary primes. The Module does more than the minimum required rounds in all cases of p and q size. Note 9: SHA3 was CAVP tested as standalone functions. SHA3 has not been CAVP tested with ECDSA or RSA as no CAVP testing is currently available. This meets the use and testing requirements in [FIPS140-3_IG] C.C. Note 10: The Module cannot generate signatures in the Approved mode using a 1024-bit key and cannot generate 1024-bit keys. The Module can verify signatures signed with a 1024-bit key. Reference sources for the strengths provided in Table 3 are as follows: • AES (AES-128, AES-192, AES-256): [SP800-57P1r5] Table 2. • ECC (P-192, P-224, P-256, P-384, P-521): [SP800-186] Table 1. • FFC (L=1024/N=160, L=2048/N=224, L=2048/N=256, L=3072/N=256): [SP800-57P1r5] Table 2. • FFC (ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192): [SP800-56Ar3] Table 26. • IFC (k=1024, k=2048, k=3072, k=4096): [SP800-56Br2] Table 4. • SHA-1, SHA2 (SHA2-224, SHA2-256, SHA2-384, SHA2-512): [SP800-107] Table 1. • SHA3 (SHA3-224, SHA3-256, SHA3-384, SHA3-512): [SP800-57P1r5] Table
6. Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation The Module does not implement the following: • Non-Approved Algorithms Allowed in the Approved Mode of Operation. • Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed.

Table 5 defines the Module’s [FIPS140-3] logical interfaces; the Module does not interact with physical ports. Table 5 – Ports and Interfaces

The Module supports the Cryptographic Officer (CO) operator role, and does not support multiple concurrent operators, a maintenance role or bypass capability. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt The Module does not provide an authentication or identification method of its own. The CO role is implicitly The cryptographic module does not support loading software from an external source.

All services implemented by the Module are listed in Table 6. 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; the return code FIPS_MODE_DEGRADED means a CAST has failed

• see also §2.3 above. See [UG] for additional information on the cryptographic services listed in this section. Table 6
• Roles, Service Commands, Input and Output Table 7 describes Module service access to SSPs. In each cell below, the following annotations indicate the type
• G = Generate: The Module generates or derives the SSP.
• R = Read: The SSP is read from the Module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the Module.
• E = Execute: The Module uses the SSP in performing a cryptographic operation. The text ‘--’ indicates the table cell contents are intentionally not present.
• f
• return a zero on success, or a negative value for error code.
• t - returns FIPS_MODE_INIT (0), FIPS_MODE_NORMAL (1), or FIPS_MODE_FAILED (3) is in the non-Approved mode. wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Table 7

• Approved Services wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Note that the caller provides the KAS_Private and KAS_Public keys for shared secret computation; the caller’s exchange and assurance of SSPs with the remote participant is outside the scope of the Module. † Consistent with [FIPS140-3_IG] §9.5.A, available only if the private_key_read_enable property is set to TRUE. ‡ Not claiming key transport, but the RSADP and RSAEP are available for interoperation with peers using the TLS protocol stack without an approved cryptography implementation. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Table 8 – Non-Approved Services

The Module uses HMAC-SHA2-256 with a 256-bit key (HMAC Cert. #A2461) as the approved integrity technique. The object files from section 2 are linked into the library. The code section is delimited by two functions that do not perform any actions; they are used only for their addresses. The constant data section is delimited by two constant arrays of unused data; they are only used for their addresses. The code is first added to the hash, then the constant data is added to the hash. The verify hash stored in the code is excluded from the HMAC-SHA2-256 calculation. The calculated HMAC is compared to the HMAC stored in the constant data section. Before the integrity technique is executed, the Module performs an HMAC-SHA2-256 KAT.

The operator can initiate the integrity test on demand by reloading the Module.

While the Module is not “open-source” since it is only shipped under a commercial license, the open-source practice of source code delivery with a commercial license is standard for the Module. While not required to do so, the Module will abide by [ISO19790] §B.2.5. Please see details in the wolfCrypt FIPS 140-3 User Guide [UG] for the OEs listed on the validation certificate. Details will include information about compiler, compiler configuration settings and methods to compile the source code into an executable form in an approved mode of operation. See also §11.1 below.

Table 2 lists the operational environments on which the Module was tested. The module runs on a modifiable operating environment. The operational environment that is designed to accept functional changes that may contain non-controlled software. For Linux builds, the configure script provided with the package detects the environment and sets the required flags. On Windows, a header file is provided to set the required flags.

N/A. The Module does not implement physical security.

N/A. The Module does not implement non-invasive security mechanisms. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

All Sensitive Security Parameters (SSPs) used by the Module are described in this section, arranged for consistency with Table 7. The text ‘--’ indicates the table cell contents are intentionally not present. Table 9

• SSPs Generation Import/Export Establishment Zeroisation Storage Strength is provided in bits. Please refer to Table 3 and the notes below it for the strength provenance (traceability to applicable standards and special publications). wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy                                                                                                                                          wolfCrypt Generation   Import/Export   Establishment             Zeroisation Storage Legend Generation                                    Establishment                                                                      Storage G1: [FIPS186-4] RSA keypair generation,       E1: [SP800-56Ar3] §5.7.1.1 FFC DH                                                  S1: RAM in plaintext [SP800-133r2] Section 5 compliant             E2: [SP800-56Ar3] §5.7.1.1 ECC CDH G2: [FIPS186-4] ECDSA keypair generation      E3: [SP800-56Cr2] Extract-then-expand                                              Zeroisation [SP800-133r2] Section 5 compliant             KDF                                                                                Z1: Cleared after use via Free, or as part of G3: [FIPS186-4] DSA keypair generation,       E4: [SP800-90Ar1] Hash_df; Instantiate;                                            function cleanup before return. [SP800-133r2] Section 5 compliant.            Generate; Reseed                                                                   Z2: the internal RBG is zeroized upon G4: [SP800-90B] DRBG seed material,                                                                                              module shutdown. [SP800-133r2] Section 4 compliant The separation into specific keys is done outside the scope of the module but must be conformant to [SP800-56Cr2]. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt G5: [SP800-90Ar1] DRBG state Import/Export (instantiation or update); [SP800-133r2] IE1: Call stack (API) input parameters Section 4 compliant. (electronic entry) IE2: Call stack (API) output parameters (electronic entry)

• Produces random values in accordance with [SP800-133r2] Section 4, in that the DRBG output is provided directly as the random output.
• Does not provide any service beyond random value generation for symmetric key generation. SSPs used with symmetric key algorithms are provided by the calling application.
• Produces asymmetric keys in accordance with [SP800-133r2] Section 5, in that all asymmetric keys generated by the module (the Key management service) provide the output of the approved key generation algorithm with no post-processing or manipulation of the generated key pairs. As noted in the previous item, random values used in the asymmetric key generation algorithms are direct outputs of the DRBG. Keys produced by the module use an internal Counter DRBG for which the minimum key size and equivalent security strength is 128 bits.
• Supports symmetric key derivation in accordance with [SP800-133r2] Section 6.2, using the approved and CAVP listed KDF algorithms. Table 10
• Non-Deterministic Random Number Generation Specification

Each time the Module is powered up, it tests that the cryptographic algorithms still operate correctly, and that sensitive data has not been damaged. The pre-operational self-tests are available on demand by reloading the On instantiation, the Module performs the pre-operational self-tests described below. All cryptographic functions include a check of a self-test flag; a self-test will be invoked if it has not yet been performed. All KATs must complete successfully prior to any other use of cryptography by the Module. The error state is persistent, and no services are available. All attempts to use the Module’s services result in the return of a non-zero error code, FIPS_NOT_ALLOWED_E (-197). To recover from an error state, reload the Module into memory. The module error state is called “Err”. Once the Module is powered on and has passed the pre-operational self-tests, calls to any cryptographic algorithm will trigger the CAST on first operational use of the algorithm. The 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 in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt wolfSSL Inc. highly recommends a periodic power cycle or reload of the Module (once in a 24-hour period) as a best security practice. If a periodic power cycle is not possible, a periodic call to the function wc_RunAllCast_fips() is recommended as an alternative (at least once in a 24-hour period). See §10.2 below for details on proper use of the API from a calling application. Pre-Operational Self-Tests

• Software Integrity: HMAC-SHA2-256 (#A2461) with a 256-bit key. Conditional Cryptographic Algorithm Self-Tests (CASTs)
• AES-CBC #A2461: Encryption KAT, CBC mode, 128-bit key. Covers self-test requirements for the Table 3 Algorithm and Standard entry AES [FIPS197], [SP800-38A].
• AES-CBC #A2461: Decryption KAT, CBC mode, 128-bit key. Covers self-test requirements for the Table 3 Algorithm and Standard entry AES [FIPS197], [SP800-38A].
• AES-GCM #A2461: Authenticated encryption KAT, GCM mode, 128-bit key. Covers self-test requirements for the Table 3 Algorithm and Standard entries AES [SP800-38B], [SP800-38C], [SP800-38D].
• AES-GCM #A2461: Authenticated decryption KAT, GCM mode, 128-bit key. Covers self-test requirements for the Table 3 Algorithm and Standard entries AES [SP800-38B], [SP800-38C], [SP800-38D].
• ECDSA SigGen #A2461: ECDSA signature generation KAT using the P-256 curve.
• ECDSA SigVer #A2461: ECDSA signature verification KAT using the P-256 curve.
• Hash DRBG #A2461: [SP800-90Ar1] §11.3 Instantiate, Generate, Reseed health tests for SHA2-256 Hash DRBG.
• HMAC-SHA-1 #A2461: HMAC-SHA-1 (160-bit key) KAT. Per [FIPS140-3_IG] §10.3.A and §10.3.B, inclusive of corresponding SHA-1 CAST.
• HMAC-SHA2-256 #A2461: HMAC-SHA2-256 (256-bit key) KAT. Per [FIPS140-3_IG] §10.3.A and §10.3.B, inclusive of corresponding SHA2 CAST. Performed prior to its use in the integrity test as required by AS10.20.
• HMAC-SHA2-512 #A2461: HMAC-SHA2-512 (512-bit key) KAT. Per [FIPS140-3_IG] §10.3.A and §10.3.B, inclusive of corresponding SHA2 CAST.
• HMAC-SHA3 #A2461: HMAC-SHA3-256 (256-bit key) KAT. Per [FIPS140-3_IG] §10.3.A and §10.3.B, inclusive of corresponding SHA3 CAST.
• KAS-ECC-SSC #A2461: [SP800-56Ar3] Section 5.7.1.2 primitive “Z” computation KAT, per [FIPS140-3_IG] §D.F, using P-256.
• KAS-FFC-SSC #A2461: [SP800-56Ar3] Section 5.7.1.1 primitive “Z” computation KAT, per [FIPS140-3_IG] §D.F, using L = 2048 N = 256.
• KDF SSH #A2461: [SP800-135r1] SSH v2 KDF KAT. Hash type SHA2-256.
• KDF TLS #A2461: [SP800-135r1] TLS v1.2 KDF KAT. Covers self-test requirements for TLS v1.2 KDF RFC7627. Hash type SHA2-256.
• RSA SigGen #A2461: Signature generation KAT (k = 2048), inclusive of the embedded SHA2-256 self-test.
• RSA SigVer #A2461: Signature verification KAT (k = 2048), inclusive of the embedded SHA2-256 self-test.
• TLS v1.3 KDF #A2461: TLS v1.3 KDF KAT. Conditional Pairwise Consistency Tests (PCTs)
• DSA KeyGen #A2461: FFC Key Generation Pairwise Consistency Test, performed on FFC key pair generation. FFDHE 2048, FFDHE 3072, FFDHE 4096. [RFC7919] wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

• ECDSA KeyGen #A2461: ECC Key Generation Pairwise Consistency Test, performed on ECC (ECDSA, KASECC-SSC) key pair generation. Covers self-test requirements for the Table 3 Algorithm and Standard entry ECDSA KeyVer [FIPS186-4]. Curves: NIST P-224, NIST P-256, NIST P-384, NIST P-521.
• RSA KeyGen #A2461: RSA Key Generation Pairwise Consistency Test, performed on RSA key pair generation.Key size 2048, 3072, 4096.

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. The CO may initiate all CASTs at once. The API wc_RunAllCast_fips() is provided as a public API to applications using the Module that have included the headers above in the proper order. The CO may initiate CASTs 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_CDH • 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 The CO may re-run the pre-operational self-tests 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 wolfCrypt_GetStatus_fips() API shall then be checked against the status indicators below: • FIPS_MODE_INIT status indicator value is
3. This indicator means the 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 reload (equivalent to power cycle) to restore the Module. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

The CO shall use the provided 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. The [UG] has a section specific to each Operational Environment (OE), also referred to as the “Tested Configuration”, that appears on the Module’s certificate and in the above Table 2

• Tested Operational Environments. The instructions provided in the [UG] shall be followed or the Module will not be considered a FIPS 140-3 validated module.
• The [UG] includes 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. The [UG] includes 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 [ISO19790] §B.2.5: “If the module is open source, specify the compilers and control parameters required to compile the code into an executable format.” The following initialization instructions apply to all use-cases for the Module generically by a consuming application. OE-specific details are 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 Linux systems where autotools was 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. static void myFipsCb(int ok, int err, const char* hash) { printf("in my Fips callback, ok = %d, err = %d\n", ok, err); 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
• Callback Example wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

• If using an informational callback function, the CO shall register the function by passing the function pointer to the API as follows: “wolfCrypt_SetCb_fips(myFipsCb);”.
• Prior to operational use of the Module, the CO shall register an entropy callback function 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 as the entropy source is external to the Module. To register the portable callback function 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 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 via the function call “wolfCrypt_SetPrivateKeyReadEnable_fips(1, WC_KEYTYPE_ALL);”. Once done working with the private key, it is recommended that the application then lock access to private key materials before resuming operations with the function call: “wolfCrypt_SetPrivateKeyReadEnable_fips(0, WC_KEYTYPE_ALL);”.
• The module will operate in the Approved mode of operation as long as only the Approved services listed in Table 7 are invoked. The module transitions to the non-Approved mode when the service in Table 8 is invoked. When using the non-Approved service, no SSPs from the Approved mode are being used.

Operation of wolfCrypt in the FIPS 140-3 Approved Mode requires the wolfCrypt library version 5.2.0.1. To verify the fingerprint of the package, calculate the SHA2-256 sum using a FIPS 140-2 or FIPS 140-3 validated cryptographic module. The following command serves as an example: $ shasum -a 256 wolfssl-5.2.0.1-commercial-fips-linuxv5.7z 746341ac6d88b0d6de02277af5b86275361ed106c9ec07559aa57508e218b3f5 Compare the sum to the sum provided with the package. If the sums do not match stop using the Module and contact wolfSSL. To unpack the bundle: $ 7za x wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z 7-Zip... Extracting archive: wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z ... Enter password (will not be echoed): When prompted, enter the password. The password is provided in the distribution email. To build and install wolfCrypt in Approved mode: $ ./configure --enable-fips=v5 $ ./wolfcrypt/test/testwolfcrypt $ sudo make install If you have not received the library with FIPS 140-3 support the ./configure step will fail. Please contact wolfSSL. The enable and disable options required for running in the Approved Mode are automatically set by the FIPS enable option. Any encryption algorithms that are not enabled by the configuration must not be enabled separately. Options affecting wolfSSL usage are still allowed. make check will verify the build and that the library is operating correctly. If make check fails this probably means the In Core Integrity check has failed, which is expected. To verify this do: $ ./wolfcrypt/test/testwolfcrypt wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt ... in my Fips callback, ok = 0, err = 203 message = In Core Integrity check FIPS error hash = 622B4F8714276FF8845DD49DD3AA27FF68A8226C50D5651D320D914A5660B3F5 In core integrity hash check failure, copy above hash into verifyCore[] in fips_test.c and rebuild Copy the value given for the hash in the output, and replace the value of verifyCore[] in ./wolfcrypt/src/fips_test.c with this new value. After updating verifyCore[], recompile the wolfSSL library by running make check again. The In Core Integrity checksum will vary with compiler versions, runtime library versions, target hardware, and build type.

Operation of wolfCrypt in the FIPS 140-3 Approved Mode requires the wolfCrypt library version 5.2.0.1. To verify the fingerprint of the package, calculate the SHA2-256 sum using a FIPS 140-2 or FIPS 140-3 validated cryptographic module. The following command serves as an example: % shasum –a 256 wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z 02da35d0a4d6b8e777236fe30da7a6ff93834fb16939ea16da663773f1b34cf0 And compare the sum to the sum provided with the package. If for some reason the sums do not match stop using the Module and contact wolfSSL. A GUI-based 7-zip extraction may be used. To unpack the bundle from a command shell: % 7za x wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z 7-Zip... Extracting archive: wolfssl-5.7.2-commercial-fips-linuxv5.2.0.1.7z ... Enter password (will not be echoed): When prompted, enter the password. The password is provided in the distribution email. To build and install wolfCrypt for use in a FIPS 140-3 approved mode:

1. In Visual Studio open IDE\WIN10\wolfssl-fips.sln.
2. Select the Release DLL and x64 as the build type and target.
3. Build the solution
4. The library should be in the directory IDE\WIN10\DLL Release\x64 as a pair of files: wolfssl-fips.lib is the linking library and wolfssl-fips.dll is the shared library proper, it can be added to your project.
5. In your application project, add a preprocessor macro for HAVE_FIPS. This will ensure the compiler is loading all the correct settings from the user_settings.h header file in the library.
6. Build the solution.
7. Run the code from the DLL Release\x64 directory, the default check failure should be output in the shell. The enable and disable options required for Approved mode are automatically set in the user settings file mentioned in step 5 above. Any encryption algorithms that are not enabled by the Approved mode must not be enabled separately. Options affecting wolfSSL usage are still allowed. The first run should indicate the In Core Integrity check has failed: in my Fips callback, ok = 0, err = -203 message = In Core Integrity check FIPS error hash = 622B4F8714276FF8845DD49DD3AA27FF68A8226C50D5651D320D914A5660B3F5 In core integrity hash check failure, copy above hash into verifyCore[] in fips_test.c and rebuild wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt The In Core Integrity checksum will vary with compiler versions, runtime library versions, target hardware, and build type.

The library uses an allocator method to initialize itself after loading, without programmer interaction. The library will perform its own self-test in a thread safe manner.

The library uses the DllMain() function to initialize itself after loading, without programmer interaction. The library will perform its own self-test in a thread safe manner.

The CO shall use the provided [UG].

The Module supports the Cryptographic Officer (CO) operator role and does not support non-administrators.

N/A. The Module does not claim mitigation of other attacks. wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt References

• [FIPS140-3]: FIPS 140-3, Security Requirements for Cryptographic Modules, 3/22/2019
• [SP800-140_DTR]: NIST SP 800-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [SP800-140A]: NIST SP 800-140A, CMVP Documentation Requirements: CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [SP800-140B]: NIST SP 800-140B, CMVP Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B, 3/20/2020
• [SP800-140Cr2]: NIST SP 800-140C Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Security Functions: CMVP Validation Authority Updates to ISO/IEC 24759, 7/25/2023 Supplemental Information: SP 800-140C: Approved Security Functions, 7/25/2023
• [SP800-140Dr2]: NIST SP 800-140D Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Sensitive Security Parameter Generation and Establishment Methods: CMVP Validation Authority Updates to ISO/IEC 24759, 7/25/2023 Supplemental Information: SP 800-140D: Approved SSP Generation and Establishment Methods, 25-Jul2023
• [SP800-140F]: NIST SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics: CMVP Validation Authority Updates to ISO/IEC 24759, 3/20/2020
• [FIPS140-3_IG]: Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program, 8/1/2023
• [ISO19790]: ISO/IEC 19790:2012 Information technology
• Security techniques
• Security requirements for cryptographic modules, 11/1/2015
• [ISO24759]: ISO/IEC 24759:2017 Information technology
• Security techniques
• Test requirements for cryptographic Modules, 3/1/2017
• [FIPS180-4]: FIPS 180-4, Secure Hash Standard (SHS), 8/4/2015
• [FIPS186-4]: FIPS 186-4, Digital Signature Standard (DSS), 7/19/2013
• [FIPS186-5]: FIPS 186-5, Digital Signature Standard (DSS), 2/3/2023
• [FIPS197]: FIPS 197, Advanced Encryption Standard (AES), 5/09/2023
• [FIPS198-1]: FIPS 198-1, The Keyed Hash Message Authentication Code (HMAC), 7/16/2008
• [FIPS202]: FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, 8/4/2015
• [SP800-38A]: NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, 12/1/2001
• [SP800-38B]: NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, 10/6/2016
• [SP800-38C]: NIST SP 800-38C, Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality, 7/20/2007
• [SP800-38D]: NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 11/28/2007 wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt

• [SP800-52r2]: NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, 8/29/2019
• [SP800-56Ar3]: NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, 4/16/2018
• [SP800-56Br2]: NIST SP 800-56B Rev. 2, Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography, 3/21/2019
• [SP800-56Cr2]: NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in KeyEstablishment Schemes, 8/18/2020
• [SP800-57P1r5]: NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1
• General, 5/4/2020
• [SP800-90Ar1]: NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, 6/24/2015
• [SP800-90B]: NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, 1/10/2018
• [SP800-107r1]: NIST SP 800-107 Rev. 1, Recommendation for Applications Using Approved Hash Algorithms, 8/24/2012
• [SP800-131Ar2]: NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, 3/21/2019
• [SP800-133r2]: NIST SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, 6/4/2020
• [SP800-135r1]: NIST SP 800-135 Rev. 1, Recommendation for Existing Application-Specific Key Derivation Functions, 12/23/2011
• [SP800-186]: NIST SP 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, 2/3/2023
• [RFC7627]: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension, 9/16/2015
• [RFC7919]: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS), 8/10/2016
• [RFC8446]: The Transport Layer Security (TLS) Protocol Version 1.3, 8/10/2018
• [UG]: wolfCrypt FIPS 140-3 User Guide, 4/19/2021 wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy                                                                             wolfCrypt Acronyms and Definitions •   AES: Advanced Encryption Standard •   AES-NI: Advanced Encryption Standard New Instructions •   API: Application Programming Interface •   CAST: Cryptographic Algorithm Self-Test •   CAVP: Cryptographic Algorithm Validation Program •   CBC: Cipher-Block Chaining •   CCM: Counter with CBC-MAC •   CMAC: Cipher-based Message Authentication Code •   CMVP: Cryptographic Module Validation Program •   CO: Cryptographic Officer •   CPU: Central Processing Unit •   CSP: Critical Security Parameter •   CTR: Counter-mode •   CVL: Component Validation List •   DH: Diffie-Hellman •   DRBG: Deterministic Random Bit Generator •   DSA: Digital Signature Algorithm •   ECB: Electronic Code Book •   ECC: Elliptic Curve Cryptography •   ECC-CDH: Elliptic Curve Cryptography Cofactor Diffie-Hellman •   ECDH: Elliptic Curve Diffie-Hellman •   ECDSA: Elliptic Curve Digital Signature Algorithm •   EMC: Electromagnetic Compatibility •   EMI: Electromagnetic Interference •   FFC: Finite Field Cryptography •   FIPS: Federal Information Processing Standard •   GCM: Galois/Counter Mode •   GMAC: Galois Message Authentication Code •   GPC: General-Purpose Computer •   HMAC: Keyed-Hash Message Authentication Code •   IG: Implementation Guidance •   IV: Initialization Vector •   KAS: Key Agreement Scheme •   KAT: Known Answer Test •   KDF: Key Derivation Function •   LTS: Long Term Support •   NIST: National Institute of Standards and Technology •   PAA: Processor Algorithm Accelerators •   PCT: Pair-wise Consistency Test •   PSP: Public Security Parameter •   RAM: Random Access Memory wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy                                                                             wolfCrypt •   RNG: Random Number Generator •   RSA: Rivest, Shamir, and Adleman Algorithm •   RSADP: RSA Decryption Primitive •   RSAEP: RSA Encryption Primitive •   SHA: Secure Hash Algorithm •   SHS: Secure Hash Standard •   SSC: Shared Secret Computation •   SSP: Sensitive Security Parameter •   TLS: Transport Layer Security wolfSSL Inc. Public Material – May be reproduced in its original entirety without revision.