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.

FIPS 140-3 Security Policy wolfCrypt

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 ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6. [Number Below]

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 # Operating System Hardware Platform Processor PAA/ Acceleration

1 Linux 4.4 (Ubuntu 16.04 LTS) Intel Ultrabook 2 in 1 Intel® Core™ i5-5300U CPU @2.30GHz x 4 PAA

2 Linux 4.4 (Ubuntu 16.04 LTS) Intel Ultrabook 2 in 1 Intel® Core™ i5-5300U CPU @2.30GHz x 4 None

3 Windows 10 Intel Ultrabook 2 in 1 Intel® Core™ i5-5300U CPU @2.30GHz x 4 PAA

4 Windows 10 Intel Ultrabook 2 in 1 Intel® Core™ i5-5300U CPU @2.30GHz x 4 None

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 CAVP Algorithm and Mode/Method Description/Key Size(s)/ Use/Function Cert Standard Key Strength(s) A2461 AES AES-CBC, AES-CTR, AES-ECB, AES-128 (s = 128), Encryption, decryption [FIPS197], AES-OFB AES-192 (s = 192), [SP800-38A] AES-256 (s = 256) A2461 AES AES-CCM, AES-GCM AES-128 (s = 128), Authenticated encryption, [SP800-38C], AES-192 (s = 192), authenticated decryption, [SP800-38D] AES-256 (s = 256) message authentication A2461 AES AES-CMAC AES-128 (s = 128), Message authentication [SP800-38B] AES-192 (s = 192), generation, verification AES-256 (s = 256) A2461 AES AES-GMAC AES-192 (s = 192), Message authentication [SP800-38D] AES-256 (s = 256) generation, verification Vendor CKG §4: Using the Output of a N/A Cryptographic key Affirmed [SP800-133r2] Random Bit Generator generation §5: Generation of Key Pairs for Asymmetric-Key Algorithms §6.2: Derivation of Symmetric Keys A2461 DSA KeyGen FFC key generation L = 2048, N = 256 (s = 112) FFC key generation [FIPS186-4] See Note 4 and Note 7 A2461 ECDSA KeyGen Secret generation mode: Extra P-224 (s ~= 112), ECC key generation [FIPS186-4] Bits P-256 (s ~= 128), P-384 (s ~= 192), P-521 (s ~= 256) See Note 2 A2461 ECDSA KeyVer Public Key Validity P-192 (s < 112), ECC public key validation [FIPS186-4] P-224 (s ~= 112), (curve P-192 is for legacy P-256 (s ~= 128), use only) P-384 (s ~= 192), P-521 (s ~= 256) See Note 2 A2461 ECDSA SigGen SigGen (tested with SHA2-224, P-224 (s ~= 112), ECC signature generation [FIPS186-4] SHA2-256, SHA2-384, P-256 (s ~= 128), SHA2-512) P-384 (s ~= 192), P-521 (s ~= 256) See Note 2 A2461 ECDSA SigVer SigVer (tested with SHA-1, P-192 (s < 112), ECC signature verification. [FIPS186-4] SHA2-224, SHA2-256, P-224 (s ~= 112), (verification with SHA-1 SHA2-384, SHA2-512) P-256 (s ~= 128), and curve P-192 is for P-384 (s ~= 192), legacy use only) P-521 (s ~= 256) See Note 2 A2461 Hash DRBG No prediction resistance SHA2-256 (s = 256) Random bit generation [SP800-90Ar1] wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt CAVP Algorithm and Mode/Method Description/Key Size(s)/ Use/Function Cert Standard Key Strength(s) A2461 HMAC-SHA-1 Generate HMAC-SHA-1 MAC, SHA-1 (s = 160) Generation, verification, [FIPS198-1] with SHA-1 mode message authentication A2461 HMAC-SHA2 Generate HMAC-SHA2 MAC SHA2-224 (s = 224), Generation, verification, [FIPS198-1] with the listed SHA2 modes SHA2-256 (s = 256), message authentication SHA2-384 (s = 384), SHA2-512 (s = 512) A2461 HMAC-SHA3 Generate HMAC-SHA3 MAC SHA3-224 (s = 224), Generation, verification, [FIPS198-1] with the listed SHA3 modes SHA3-256 (s = 256), message authentication SHA3-384 (s = 384), SHA3-512 (s = 512) A2461 KAS-ECC-SSC Scheme: ephemeralUnified P-256 (s ~= 128), Shared secret [SP800-56Ar3] KAS Role: Initiator, responder P-384 (s ~= 192), computation P-521 (s ~= 256) See Note 2 and Note 3 A2461 KAS-FFC-SSC Scheme: dhEphem ffdhe2048 (s = 112), Shared secret [SP800-56Ar3] KAS Role: Initiator, responder ffdhe3072 (112 ≤ s ≤ 128), computation ffdhe4096 (112 ≤ s ≤ 152), ffdhe6144 (112 ≤ s ≤ 176), ffdhe8192 (112 ≤ s ≤ 200) See Note 5 CVL KDF SSH Derivation of key blocks for the AES-128 (s = 128), Key derivation for use A2461 [SP800-135r1] listed AES cipher key types and AES-192 (s = 192), with the SSH v2 protocol hash algorithms AES-256 (s = 256); SHA-1 (s = 160), SHA2-256 (s = 256), SHA2-384 (s = 384), SHA2-512 (s = 512) CVL KDF TLS TLS key derivation using the SHA2-256 (s = 256), Key derivation for use A2461 [SP800-135r1] listed hash algorithms SHA2-384 (s = 384), with the TLS v1.2 protocol SHA2-512 (s = 512) CVL RSA Decryption RSA primitive operations only k = 2048 (s ~= 112) Key transport primitive A2461 Primitive (no claims of key transport) See Note 6 RSADP [SP800-56Br2] Vendor RSA Encryption RSA primitive operations only k=2048 (s ~= 112), Key transport primitive Affirmed Primitive (no claims of key transport) k=3072 (s ~= 128), RSAEP [SP800-56Br2] k=4096 (s ~= 152) See Note 6 A2461 RSA KeyGen Key generation mode: B.3.3 k=2048 (s ~= 112), Key generation [FIPS186-4] Primality tests per Table C.2, k=3072 (s ~= 128), with listed moduli k=4096 (s ~= 152) See Note 4, Note 6, and Note 10 A2461 RSA SigGen Signature types: PKCS 1.5 and k=2048 (s ~= 112), Signature generation [FIPS186-4] PKCSPSS tested with the listed k=3072 (s ~= 128), moduli and the following hash k=4096 (s ~= 152) algorithms: SHA2-224, See Note 4, Note 6, and Note 10 SHA2-256, SHA2-384, SHA2-512 wolfSSL Inc. Public Material

• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt CAVP Algorithm and Mode/Method Description/Key Size(s)/ Use/Function Cert Standard Key Strength(s) Signature types: PKCS 1.5 and PKCSPSS with the listed moduli and the following hash algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512 (no ACVP testing is currently available, See Note

9. A2461 RSA SigVer Signature types: PKCS 1.5 and k=1024 (s ≤ 112), Signature verification [FIPS186-4] PKCSPSS tested with the listed k=2048 (s ~= 112), (verification with SHA-1 moduli and the following hash k=3072 (s ~= 128), and modulus length algorithms: SHA-1, SHA2-224, k=4096 (s ~= 152) k=1024 is for legacy use SHA2-256, SHA2-384, See Note 4 and Note 6 only) SHA2-512 Signature types: PKCS 1.5 and PKCSPSS with the listed moduli and the following hash algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512 (no ACVP testing is currently available, See Note
10. A2461 SHA-1 SHA-1 mode listed at right SHA-1 (s = 160) Message digest [FIPS180-4] See Note 1 generation A2461 SHA2 SHA2 modes listed at right SHA2-224 (s = 224), Message digest [FIPS180-4] SHA2-256 (s = 256), generation SHA2-384 (s = 384), SHA2-512 (s = 512) See Note 1 A2461 SHA3 SHA3 modes listed at right SHA3-224 (s = 224), Message digest [FIPS202] See Note 9 SHA3-256 (s = 256), generation SHA3-384 (s = 384), SHA3-512 (s = 512) See Note 1 CVL TLS v1.2 KDF TLS [RFC7627] key derivation SHA2-256 (s = 256), Key derivation for use A2461 [RFC7627] with Extended Master Secret SHA2-384 (s = 384), with the TLS v1.2 protocol (EMS) support, using the listed SHA2-512 (s = 512) hash algorithms CVL TLS v1.3 KDF KDF running modes: DHE, PSK, HMAC-SHA2-256 (s = 256), Key derivation for use A2461 [RFC8446] PSK-DHE, using the listed HMAC-SHA2-384 (s = 384) with the TLS v1.3 protocol HMAC algorithms Note 1: Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in [SP800-57P1r5] Table
11. 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
12. 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,
13. 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 Algorithm/Function Use/Function RSA SigGen using 1024 bit keys RSA Signature Generation 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 Physical Port Logical Interface Data that Passes over Port/Interface N/A: Internal (call stack) Control In API entry point: stack frame including non-sensitive parameters N/A: Internal (call stack) Control Out API call parameters passed by reference for structures allocated by wolfCrypt N/A: Internal (call stack) Data In API call parameters passed by reference or value for cryptographic service input N/A: Internal (call stack) Data Out API call parameters passed by reference for cryptographic service output N/A: Internal (call stack) Status Out API return value: enumerated status resulting from call execution

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 identified by the service requested. 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 Role Service Input Output CO Digital signature Sign: signing key; message Status return; Signature value Verify: signature value; flags; sizes Status return CO Generate key pair FFC, ECC: curve identifier Status return; general digital signature RSA: modulus size private and public keys CO Key agreement Key structs (key agreement keys); flags Status return; key agreement shared secret CO Key derivation Key agreement shared secret; flags Status return; derived keying material CO Key transport Decrypt primitive: Key structs; encapsulated Status return; keying material primitives keying material; flags CO Keyed hash Keyed hash key Status return; Tag value CO Message digest Message; flags Status return; Hash value CO Random DRBG struct (RGB_State); RBG_Seed Status return; Random value CO Self-test Flags Status return CO Show status None Status return (includes Module version) CO Symmetric cipher Encryption or decryption key; flags; plaintext or Status return; Plaintext or ciphertext ciphertext CO Zeroise FreeRNG destroys the DRBG struct (RGB_State), Status return and is used on module shutdown for the internal DRBG. Key structures allocated by the caller are zeroized by the Free call corresponding to the allocated structure. Table 7 describes Module service access to SSPs. In each cell below, the following annotations indicate the type of access by the Module service:
• 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.
• Z = Zeroise: The Module zeroises the SSP. 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)
• k
• return a size on success, or a negative value for error code. For k = 1024 for RSA SigGen, the module 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 Service Description Approved Security Keys and/or SSPs Roles Access Indicator Functions Rights to Keys and/or SSPs Digital Generate or verify ECDSA SigGen, ECDSA DS_SGK/ECC CO E,W k signature digital signatures SigVer, RSA SigGen, RSA DS_SVK/ECC E,W SigVer DS_SGK/IFC E,W DS_SVK/IFC E,W Generate key Generate ECDSA KeyGen, ECDSA GKP_Private/ECC CO G,W f pair† asymmetric key pairs KeyVer, RSA KeyGen, DSA GKP_Public/ECC G,W KeyGen GKP_Private/IFC G,W GKP_Public/IFC G,W GKP_Private/FFC G,W GKP_Public/FFS G,W Key DH key agreement KAS-ECC-SSC, KAS-FFC-SSC KAS_Private/ECC CO E,W f agreement† primitives KAS_Public/ECC E,W KAS_Private/FFC E,W KAS_Public/FFC E,W KAS_SS/ECC G,R KAS_SS/FFC G,R Key Derive keying KDF SSH, KDF TLS, KAS_SS/ECC CO E,W f derivation† material from a TLS v1.2 KDF RFC7627, KAS_SS/FFC E,W shared secret TLS v1.3 KDF KD_DKM, G,R KTS_SS/IFC E,W Key transport Encapsulate or RSA Decryption Primitive, KTS_KDK/IFC CO E, f primitives ‡ decapsulate key RSA Encryption Primitive KTS_KEK/IFC E, material on behalf of KTS_SS/IFC R the calling process Keyed hash Generate or verify AES-CMAC, AES-GMAC, KH_Key/AES-CMAC CO E,W f message integrity HMAC-SHA-1, KH_Key/AES-GMAC E,W HMAC-SHA2-224, KH_Key/HMAC E,W HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512 Message digest Generate a message SHA-1, SHA2-224, SHA2- -- CO -- f digest 256, SHA2-384, SHA2-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 Random Generate random CKG, Hash DRBG RBG_Seed CO E,W f bits using the DRBG RBG_State E,G Entropy Input E,W Self-test Perform the -- -- CO -- f designated self-test Show status Provide Module -- -- CO -- t status (includes Module version) wolfSSL Inc. Public Material
• May be reproduced in its original entirety without revision.

FIPS 140-3 Security Policy wolfCrypt Service Description Approved Security Keys and/or SSPs Roles Access Indicator Functions Rights to Keys and/or SSPs Symmetric Encrypt or decrypt AES-CBC, AES-CCM, SC_EDK/AES CO E,W f cipher data, including AEAD AES-CTR, AES-ECB, modes (CCM, GCM) AES-GCM, AES-OFB Zeroise wc_FreeRng_fips() -- Entropy Input CO Z f destroys RNG CSPs RBG_State Z All functions zeroise DS_SGK/ECC Z CSPs using function DS_SGK/IFC Z ForceZero() GKP_Private/ECC Z (overwriting with GKP_Private/IFC Z zeroes) within the KAS_Private/ECC Z function scope after KAS_Private/FFC Z use KAS_SS/ECC Z KAS_SS/FFC Z Caller stack cleanup KH_Key/AES-CMAC Z is the duty of the KH_Key/AES-GMAC Z application KH_Key/HMAC Z GPC restart/power- RBG_Seed Z cycle clears all CSPs SC_EDK/AES in RAM 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 Service Description Algorithms Accessed Role Indicator Digital Generate digital RSA SigGen using 1024 bit CO 1024 signature signatures keys

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 Key/SSP Security Function and Cert Strength1 Use & Related Keys Name/Type Number Storage DS_SGK/ECC 112, 128, 192, ECDSA SigGen #A2461 -- IE1 -- S1 Z1 SigGen (private) key; related to

256 DS_SVK/ECC

DS_SVK/ECC <112, 112, ECDSA SigVer #A2461 -- IE1 -- S1 Z1 SigVer (public) key, related to 128, 192, 256 DS_SGK/ECC; key type with security strength <112 bits (P-192) used only for legacy signature verification DS_SGK/IFC 112, 128, 152 RSA SigGen #A2461 -- IE1 -- S1 Z1 SigGen (private) key, related to DS_SVK/IFC DS_SVK/IFC <112, 112, RSA SigVer #A2461 -- IE1 -- S1 Z1 SigVer (public) key, related to 128, 152 DS_SGK/IFC; key type with security strength <112 bits (k=1024) used only for legacy signature verification GKP_Private/ECC 112, 128, 192, ECDSA KeyGen #A2461, G2 IE2 -- S1 Z1 General ECDSA (private) key, related to

256 ECDSA KeyVer #A2461 GKP_Public/ECC

GKP_Public/ECC <112, 112, ECDSA KeyGen #A2461, G2 IE2 -- S1 Z1 General ECDSA (public) key, related to 128, 192, 256 ECDSA KeyVer #A2461 GKP_Private/ECC; key type with security strength <112 bits (P-192) used only for legacy public key validation (KeyVer) GKP_Private/FFC 112 DSA KeyGen #A2461 G3 IE2 -- S1 Z1 General DSA (private) key, related to GKP_Public/FFC GKP_Public/FFC 112 DSA KeyGen #A2461 G3 IE2 -- S1 Z1 General DSA (public) key, related to GKP_Private/FFC GKP_Private/IFC 112, 128, 152 RSA KeyGen #A2461 G1 IE2 -- S1 Z1 General RSA (private) key, related to GKP_Public/IFC GKP_Public/IFC 112, 128, 152 RSA KeyGen #A2461 G1 IE2 -- S1 Z1 General RSA (public) key, related to GKP_Private/IFC KAS_Private/ECC 128, 192, 256 KAS-ECC-SSC #A2461 -- IE1 -- S1 Z1 Key pair component used for shared secret generation KAS_Public/ECC 128, 192, 256 KAS-ECC-SSC #A2461 -- IE1 -- S1 Z1 Peer key pair component used for shared secret generation KAS_Private/FFC 112 ≤ s ≤ 200 KAS-FFC-SSC #A2461 -- IE1 -- S1 Z1 Key pair component used for shared secret generation KAS_Public/FFC 112 ≤ s ≤ 200 KAS-FFC-SSC #A2461 -- IE1 -- S1 Z1 Peer key pair component used for shared secret generation KAS_SS/ECC 128, 192, 256 KAS-ECC-SSC #A2461 -- -- E2 S1 Z1 Shared secret calculation z output value (for KDF) KAS_SS/FFC 112 ≤ s ≤ 200 KAS-FFC-SSC #A2461 -- -- E1 S1 Z1 Shared secret calculation z output value (for KDF) 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 Key/SSP Security Function and Cert Strength1 Use & Related Keys Name/Type Number Storage KD_DKM 160, 128, 192, KDF SSH #A2461, -- -- E3 S1 Z1 Key Derivation derived keying material2 256, 384, 512 KDF TLS #A2461, TLS v1.2 KDF RFC7627 #A2461, TLS v1.3 KDF #A2461 KH_Key/ 128, 192, 256 AES-CMAC #A2461 -- IE1 -- S1 Z1 Keyed Hash key AES-CMAC KH_Key/ 128, 192, 256 AES-GMAC #A2461 -- IE1 -- S1 Z1 Keyed Hash key AES-GMAC KH_Key/HMAC 112 to 1024 in HMAC SHA-1 -- IE1 -- S1 Z1 Keyed Hash key 8-bit HMAC SHA2-224 increments HMAC SHA2-256 HMAC SHA2-384 HMAC SHA2-512 HMAC SHA3-224 HMAC SHA3-256 HMAC SHA3-384 HMAC SHA3-512 #A2461 KTS_KDK/IFC 112, 128, 152 RSA Decryption Primitive -- IE1 -- S1 Z1 RSA key de-encapsulation Key (for KDF) #A2461 KTS_KEK/IFC 112, 128, 152 RSA Encryption Primitive -- IE1 -- S1 Z1 RSA key encapsulation Key (for KDF) KTS_SS/IFC 112, 128, 152 RSA Decryption Primitive -- IE1 -- S1 Z1 RSA key transport shared secret (for #A2461, RSA Encryption KDF) Primitive Entropy Input 112 External source (see Table -- IE1 -- S1 Z1, Entropy input string 9) Z2 RBG_Seed 112 Hash DRBG #A2461 G4 -- -- S1 Z1, DRBG seed used for DRBG instantiate Z2 and reseed RBG_State 256 Hash DRBG #A2461 G5 -- E4 S1 Z1, Hash DRBG (SHA2-256) state: V (440) Z2 and C (440) SC_EDK/AES 128, 192, 256 AES-CBC #A2461, -- IE1 -- S1 Z1 AES key used for symmetric encryption AES-CCM #A2461, and decryption (including AES AES-CTR #A2461, authenticated encryption and AES-ECB #A2461, decryption) AES-GCM #A2461, AES-OFB #A2461 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) The Module:

• 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 Entropy Sources Minimum Number Details of Bits of Entropy Calling application 112 to 256 inclusive The Module passively obtains entropy via callback functions outside the Module boundary, while exercising no control over the amount or quality of the obtained entropy; the following caveat is applicable to this scenario: No assurance of the minimum strength of generated SSPs (e.g., keys)

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 Module. 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.