ZPE Systems FIPS Provider for OpenSSL 3

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for ZPE Systems FIPS Provider for OpenSSL 3
  %% 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>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Unauth<br/>Status Output</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 ZPE Systems FIPS Provider for OpenSSL 3
  %% 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>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Unauth<br/>Status Output</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

ZPE Systems ZPE Systems FIPS Provider for OpenSSL 3 FIPS 140‐3 Non‐Proprietary Security Policy Document Version 1.0 October 22, 2024 Prepared for: Prepared by: ZPE Systems KeyPair Consulting Inc.

Fremont, CA 94538 San Luis Obispo, CA 93401 zpesystems.com keypair.us +1 510.298.3022 +1 805.316.5024 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table of Contents This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 List of Tables List of Figures This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

This document defines the Non‐Proprietary Security Policy for the ZPE Systems FIPS Provider for OpenSSL 3 cryptographic module by ZPE Systems, hereafter denoted the Module. The Module meets FIPS 140‐3 overall Level 1 requirements, with security levels as shown in Section 1.2. In accordance with AS02.05, ISO/IEC 19790:2012 §7.7 Physical Security is optional and does not apply to the Module.

Purpose and Use: The Module is a cryptographic software library, intended for use by US and Canadian Federal agencies and other markets that require FIPS 140‐3 validated cryptographic functionality. The Module design corresponds to the Module security rules. Security rules enforced by the Module are described in the appropriate context of this document. Module Embodiment: MultiChipStand This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Cryptographic Boundary: Figure 1 depicts the Module operational environment, with the cryptographic boundary highlighted in red inclusive of all Module entry points (API calls). The Module is defined as a Software module per AS02.03. The pre‐operational approved integrity test is performed over all components within the cryptographic boundary. Tested Operational Environment’s Physical Perimeter (TOEPP): The General Purpose Computer is the TOEPP. Figure 1: Block Diagram This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Operating System ZPE Systems' Nodegrid OS version 6.0 ZPE Systems' Nodegrid OS version 6.0

Hardware Platform Net Services Router (NSR) Net Services Router (NSR)

Processors Intel® Atom™ CPU C3758 (Denverton) Intel® Atom™ CPU C3758 (Denverton)

PAA/PAI Yes No

Hypervisor or Host OS

Version(s) 3.0.10 with KP_1.2 3.0.10 with KP_1.2

Mode Name Nominal

Description Approved mode of operation

Type Approved

Status Indicator

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments ‐ Software, Firmware, Hybrid: Table 3: Tested Operational Environments ‐ Software, Firmware, Hybrid Vendor‐Affirmed Operational Environments ‐ Software, Firmware, Hybrid: Table 4: Vendor‐Affirmed Operational Environments ‐ Software, Firmware, Hybrid CMVP makes no statement as to the correct operation of the Module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

N/A for this Module. Modes List and Description: Table 5: Modes List and Description This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 The Module only supports an Approved mode of operation. The conditions for using the Module in the Approved mode of operation are:

1. Installation of the Module as described in Section 11.1 results in the settings described below, which are required for operation in the Approved mode: a. security‐checks = 1 Enforce minimum key strengths and approved curve names. b. allow‐plaintext‐csp‐output = 1 Enforce the AS09.16 and AS09.17 requirement for a second independent action to output CSPs as a result of calls that produce CSPs, such as key generation, key unwrap (or decapsulate) and shared secret calculation. c. conditional‐errors = 1 Enforce the Module entering the error state on conditional test errors such as PCT failure.
2. The Module is a cryptographic library used by a calling application. The calling application is responsible for: a. Use of the primitives in the correct sequence. b. Use of keys in accordance with SP 800‐140D Rev. 2 (as the keys used by the Module for cryptographic purposes are provided over the call stack by the calling application). c. Use of a SP 800‐90B compliant entropy source outside the Module boundary with at least 256 bits of security strength. Entropy is supplied to the Module via callback functions. The callback functions shall return an error if the minimum entropy strength cannot be met.

Approved Algorithms: Cipher This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 6: Approved Algorithms ‐ Cipher Key agreement Table 7: Approved Algorithms ‐ Key agreement This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Key derivation Table 8: Approved Algorithms ‐ Key derivation Key management This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 9: Approved Algorithms ‐ Key management Table 10: Approved Algorithms ‐ Key transport Message authentication This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 11: Approved Algorithms ‐ Message authentication Message digest This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 12: Approved Algorithms ‐ Message digest Random Table 13: Approved Algorithms ‐ Random Signature This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name CKG Section 4 CKG Section 5 CKG Section 6.2 Hash DRBG with SHA3‐256, SHA3‐512 HMAC DRBG with SHA3‐256, SHA3‐512

Properties

Implementation KeyPair FIPS Provider for OpenSSL 3 KeyPair FIPS Provider for OpenSSL 3 KeyPair FIPS Provider for OpenSSL 3 KeyPair FIPS Provider for OpenSSL 3 KeyPair FIPS Provider for OpenSSL 3

Reference NIST, SP 800‐133 Rev. 2 NIST, SP 800‐133 Rev. 2 NIST, SP 800‐133 Rev. 2 NIST, SP 800‐90A Rev. 1 NIST, SP 800‐90A Rev. 1

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 14: Approved Algorithms ‐ Signature Vendor‐Affirmed Algorithms: Table 15: Vendor‐Affirmed Algorithms Non‐Approved, Allowed Algorithms: N/A for this module. Non‐Approved, Allowed Algorithms with No Security Claimed: N/A for this Module. Non‐Approved, Not Allowed Algorithms: N/A for this Module. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name KTS (AES KW, KWP) MAC AES (CMAC, GMAC) MAC HMAC MAC KMAC (XOF) Message Digest Message Digest (XOF SHAKE) Random

Type BC‐Auth MAC MAC XOF SHA XOF DRBG

Description

Properties KTS:128, 192 or 256‐bit keys provide between 128 and 256 bits of encryption strength

Algorithms HMAC‐SHA3‐384 HMAC‐SHA3‐512 KMAC‐128 KMAC‐256 AES‐KW AES‐KWP AES‐GMAC AES‐CMAC HMAC‐SHA‐1 HMAC‐SHA2‐224 HMAC‐SHA2‐256 HMAC‐SHA2‐384 HMAC‐SHA2‐512 HMAC‐SHA2‐512/224 HMAC‐SHA2‐512/256 HMAC‐SHA3‐224 HMAC‐SHA3‐256 HMAC‐SHA3‐384 HMAC‐SHA3‐512 KMAC‐128 KMAC‐256 SHA‐1 SHA2‐224 SHA2‐256 SHA2‐384 SHA2‐512 SHA2‐512/224 SHA2‐512/256 SHA3‐224 SHA3‐256 SHA3‐384 SHA3‐512 SHAKE‐128 SHAKE‐256 Counter DRBG Hash DRBG HMAC DRBG

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name Signature DSA Signature ECDSA Signature EDDSA Signature RSA

Type DigSig‐SigGen DigSig‐SigVer DigSig‐SigGen DigSig‐SigVer DigSig‐SigGen DigSig‐SigVer DigSig‐SigGen DigSig‐SigVer

Description

Properties

Algorithms DSA SigGen (FIPS186‐4) DSA SigVer (FIPS186‐4) ECDSA SigGen (FIPS186‐4) ECDSA SigVer (FIPS186‐4) EDDSA SigGen EDDSA SigVer RSA SigGen (FIPS186‐4) RSA SigGen (FIPS186‐5) RSA Signature Primitive RSA SigVer (FIPS186‐4) RSA SigVer (FIPS186‐5)

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 16: Security Function Implementations

AES‐GCM: The Module supports internal IV generation using the Approved DRBG. The IV is at least 96 bits in length per SP 800‐38D Section 8.2.2, and the Approved DRBG generates outputs such that the (key, IV) pair collision probability is less than 2‐32 per SP 800‐38D Section 8. AES‐GCM IVs shall be used in compliance with FIPS 140‐3 IG C.H scenario 1a (TLS/DTLS 1.2, per RFC 5288), 1d (SSHv2, per RFC 5647) and 5 (TLS 1.3, per RFC 8446). The Module is compatible with TLS/DTLS 1.2 protocol and provides the primitives to support the AES GCM ciphersuites from SP 800‐52 Rev. 1 Section 3.3.1. The Module’s implementation of AES‐GCM is used together with one or more applications outside the Module’s cryptographic boundary that implement the specified protocols; these protocols have not been reviewed or tested by the CAVP and CMVP. In each of the protocols, 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 re‐connection can occur without a fresh key establishment operation and the associated SSPs. The Module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 264‐1 for a given session key. If this exhaustion condition is observed, the Module returns an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. XTS‐AES: In accordance with SP 800‐38E, the XTS‐AES algorithm is to be used for confidentiality on storage devices. The Module complies with FIPS 140‐3 IG C.I by:  Generating Key_1 and Key_2 independently according to the rules for component symmetric keys from SP 800‐133 Rev. 2, Section 6.3.  Explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS‐AES algorithm to process data with them. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

The strength of the Data Protection Key is based on the strength of the Password and/or Passphrase used in key derivation. SP 800‐132 does not impose

any strictly defined requirements on the strength of a password. It says that “passwords should be strong enough so that it is infeasible for attackers to

get access by guessing a password.”

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Key Agreement: The Module implements the following Approved key agreement methods which have been CAVP tested and validated:  KAS‐ECC‐SSC per SP 800‐56A Rev. 3 (FIPS 140‐3 IG D.F Scenario 2, path 1).  KAS‐FFC‐SSC per SP 800‐56A Rev. 3 (FIPS 140‐3 IG D.F Scenario 2, path 1).  KAS‐IFC‐SSC per SP 800‐56B Rev. 2 (FIPS 140‐3 IG D.F Scenario 1, path 1). The Module obtains the FIPS 140‐3 IG D.F required key agreement assurances:  SP 800‐56A Rev. 3 in accordance with Section 5.6.2.  SP 800‐56B Rev. 2 in accordance with Section 6.4. PBKDF: The implemented PBKDF uses Option 1a specified in SP 800‐132 Section 5.4. The choice to use the PBKDF with a password or passphrase is entirely outside the scope of the Module, managed by the calling application

• and potentially would need to accommodate not only application‐level considerations, but end use environment considerations and policies as well. As examples, the end use environment may impose policies to reject words found in a dictionary, to use specific types of characters (upper case, lower case, punctuation) and so on. The Module does not enforce a reduced character space (referring to the set of allowed characters), and as such, any policy to restrict the character space weakens the potential strength of the derived Data Protection Key (KD_PW_PBKDF). In the summary of password strength guidance below, the term useful refers to characters which are not simply padding the string, for example with some combination of repetitive characters
• such means of skirting organizational policies are not recommended. The phrase character space refers to the set of characters that a password or passphrase is constrained to. The printable character space is assumed to be 95 printable characters. Integrators making use of PBKDF with this Module shall determine password policy and input length based on the intended output key size and strength, taking into consideration the probability of guessing KD_PW_PBKDF. The following examples are provided to guide parameter selection:  1/(2256) = 8.6E‐78 for a 32‐byte KD_PW_PBKDF field with no character space restriction (equivalent to a 256‐bit symmetric key).  1/(9518) = 2.5E‐36 for KD_PW_PBKDF with 18 useful printable characters (better than a 112‐bit symmetric key, i.e. 1/(2112) = 1.9E‐34).  1/(9520) = 3.4E‐48 for KD_PW_PBKDF with 20 useful printable characters (better than a 128‐bit symmetric key, i.e. 1/(2128) = 2.9E‐39).  1/(9540) = 7.8E‐80 for KD_PW_PBKDF with 40 useful printable characters (better than a 256‐bit symmetric key, i.e. 1/(2256) = 8.6E‐78). In accordance with SP 800‐132 and FIPS 140‐3 IG D.N, keys derived from passwords are only to be used in storage applications. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The Module enforces the following SP 800‐132 compliance checks:  The iteration count is at least 1000.  The salt length is at least 128 bits.  The derived key length is at least 112 bits. RSA: The Module complies with FIPS 140‐3 IG C.F as follows:  RSA Key Generation, Signature Generation and Signature Verification have been tested and validated with all implemented modulus lengths for which CAVP testing is available: k = 1024 (legacy Signature Verification only), k = 2048, k = 3072, and k = 4096.  The Module also supports RSA Key Generation, Signature Generation and Signature Verification with modulus lengths for which CAVP testing is not available: k > 4096. SHA‐3 and SHAKE: The Module complies with FIPS 140‐3 IG C.C as follows:  All implemented SHA‐3 and SHAKE functions have been tested and validated on all of the Module’s operating environments.  Vendor affirmation is claimed for use of the SHA3‐256 and SHA3‐512 hash functions as part of the Hash DRBG and HMAC DRBG, for which CAVP testing with SHA‐3 is not available.

N/A for this Module. The calling application is responsible for use of a SP 800‐90B compliant entropy source outside the Module boundary providing at least 256 bits of security strength. Entropy is supplied to the Module via callback functions. The following caveat applies per FIPS 140‐3 IG 9.3.A: No assurance of the minimum strength of generated SSPs (e.g., keys).

The Module:  Produces random values in accordance with SP 800‐133 Rev. 2 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 SP 800‐133 Rev. 2 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 SP 800‐133 Rev. 2 Section 6.2, using the approved and CAVP listed KDF algorithms. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name CO

Type Role

Operator Type CO

Authentication Methods

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

The Module implements key agreement methods compliant with FIPS 140‐3 IG D.F and key transport methods compliant with FIPS 140‐3 IG D.G. Strengths are provided in Section 2.6.

The Module conforms to FIPS 140‐3 IG D.C References to the Support of Industry Protocols: while it provides SP 800‐56A Rev. 3 conformant schemes and API entry points oriented to TLS usage, the Module does not contain the full implementation of TLS. The following caveat is required: No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 17: Ports and Interfaces The Module does not interact with physical ports. The Control Output interface is not applicable, as the Module does not control other components.

Table 18: Roles The Module supports the mandatory Cryptographic Officer (CO) operational role only (implicitly identified), and does not support a maintenance role or a bypass capability. The Module does not provide an authentication or identification method of its own. The CO role is assumed by meeting the conditions of Section 11 of this document and in associated Guidance Documentation. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 G,R W,E This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 W,E ‐ Z This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access ‐ GKP_Public_ECC: Z ‐ GKP_Public_Edwards: Z ‐ GKP_Public_FFC: Z ‐ GKP_Public_IFC: Z ‐ KAS_Private_ECC: Z ‐ KAS_Private_FFC: Z ‐ GKP_Private_ECC: Z ‐ KAS_Private_IFC: Z ‐ KAS_Public_ECC: Z ‐ KAS_Public_FFC: Z ‐ KAS_Public_IFC: Z ‐ KAS_SS_ECC: Z ‐ KD_DKM_KDF: Z ‐ KD_DKM_PBKDF: Z ‐ KD_SK: Z ‐ KH_Key_AES‐CMAC: Z ‐ KH_Key_AES‐GMAC: Z ‐ KH_Key_HMAC: Z ‐ KH_Key_KMAC: Z ‐ KTS_KDK_IFC: Z ‐ KTS_KEK_IFC: Z ‐ KTS_SS_IFC: Z ‐ KAS_SS_ECC: Z ‐ SC_EDK_AES: Z ‐ SC_EDK_XTS: Z

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Z Table 19: Approved Services All services implemented by the Module correspond to the functionality described by the fips_query function, which returns available services based on an operation_id input. The fips_get_params function provides access to the current status of the Module as well as the name and version; this information correlates to the validation listing. A 1 value returned in status indicates the Module is running without error (FIPS_OK); a 0 return indicates an error (with additional error details indicated as described in the release specific API documentation). Services are only operational in the running state. Any attempts to access services in any other state will result in an error being returned. If the integrity test or any CAST fails then any attempt to access any service will result in an error being returned. The OpenSSL toolkit OSSL_PROVIDER_get_params function is used to invoke fips_get_params, when called with the Module’s global handle and a pointer to a parameter structure (initialized using provider_gettable_params or the equivalent). This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Regarding the Indicator of approved security services, the Module conforms to FIPS 140‐3 IG 2.4.C Approved Security Service Indicator, similar to example 2. Each service provides context sensitive status responses as described in the OpenSSL 3 API manual pages; generally, functions of return type int return the value 1 for success with other error codes as appropriate for the call (described in API documentation). The Module’s name and version parameters (as cited in Section 2) along with the Module’s internal indicators of the security‐check and conditional‐errors settings are used to confirm the Module is the validated Module operating in the approved mode with only approved security services. Note that the caller provides the KAS_Private and KAS_Public keys for shared secret computation; the caller’s exchange and assurance of PSPs with the remote participant is outside the scope of the Module.

The Module uses HMAC‐SHA2‐256 as the approved integrity technique; the file fips.so.mac contains the integrity reference value. The Module is provided in an executable form (as fips.so shared object for use in Linux environments).

The operator can initiate the integrity test on demand by calling fips_self_test (invoked using OSSL_PROVIDER_self_test called with the Module’s global handle) or reloading the Module.

In accordance with ISO/IEC 19790:2012 Annex B, as the Module is open source, the tools used to build the Module as tested are:  gcc version 9.3.0  perl v5.30.0  gnu make v4.2.1 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name I O

From Calling process Call stack (API) output parameters

To Call stack (API) input parameters Calling process

Format Type Plaintext Plaintext

Distribution Type Manual Manual

Entry Type Electronic Electronic

SFI or Algorithm

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

Type of Operational Environment: Modifiable No operational environment restrictions are required for operation in the approved mode. All conditions for operation of the Module in the approved mode are given in Section 2.4. The Module conforms to FIPS 140‐3 IG 2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI). The AES‐NI functions are identified by FIPS 140‐3 IG 2.3.C as a known PAA.

Table 21: SSP Input‐Output Methods

Table 22: SSP Zeroization Methods This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name DRBG_C DRBG_EI DRBG_Key DRBG_Seed DRBG_V DS_SGK_ECC DS_SGK_Edwards DS_SGK_FFC DS_SGK_IFC

Description Element of Hash DRBG state. Entropy input from an external source used for DRBG seeding. Element of CTR DRBG or HMAC DRBG state. Seed used for DRBG Instantiation and Reseed. Element of CTR, Hash or HMAC DRBG state. SigGen (private) key. SigGen (private) key. SigGen (private) key. SigGen (private) key.

Size ‐ Strength Size: 440‐888 ‐ Strength: 160 ≤ s ≤ 256 Size: 128‐2^35 ‐ Strength: 128 ≤ s ≤ 256 Size: 128‐256, 128‐256 ‐ Strength: 128 ≤ s ≤ 256, 160 ≤ s ≤ 256 Size: 128‐256 ‐ Strength: 128 ≤ s ≤ 256 Size: 128‐256, 128‐256, 128‐256 ‐ Strength: 128 ≤ s ≤ 256, 128 ≤ s ≤ 256, 128 ≤ s ≤ 256 Size: 233, 283, 409, 571, 233, 283, 409, 571, 224, 256, 384, 521 ‐ Strength: s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256 Size: 255, 448 ‐ Strength: s = 128, s = 224 Size: 2048, 2048, 3072 ‐ Strength: s = 112, s = 112, s = 128 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, s = 128, s = 152, s = 176, s = 200

Type ‐ Category Hash_DRBG_C ‐ CSP Other ‐ CSP CTR_DRBG_Key, HMAC_DRBG_Key ‐ CSP Other ‐ CSP CTR_DRBG_Key, Hash_DRBG_Key, HMAC_DRBG_Key ‐ CSP B‐233, B‐283, B‐409, B‐571, K‐ 233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521 ‐ CSP Edwards25519, Edwards448 ‐ CSP L=2048/N=224, L=2048/N=256, L=3072/N=256 ‐ CSP k=2048, k=3072, k=4096, k=6144, k=8192 ‐ CSP

Generated By Random Random Random Random

Established By

Used By Random Random Random Random Random Signature ECDSA Signature EDDSA Signature DSA Signature RSA

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 All SSPs are zeroized (overwritten with 0s) when they are no longer needed:

• CSPs and PSPs with a lifetime associated with an OpenSSL object (e.g., EVP_PKEY) are zeroized when freed or reinitialized. The OPENSSL_cleanse function is used to zeroize CSPs and PSPs owned by the caller.
• CSPs with a lifetime associated with the Module are zeroized on Module uninstantiation (the Teardown operation).

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name DS_SVK_ECC DS_SVK_Edwards DS_SVK_FFC DS_SVK_IFC GKP_Private_ECC GKP_Private_Edwards GKP_Private_FFC GKP_Private_IFC GKP_Public_ECC

Description SigVer (public) key. SigVer (public) key. SigVer (public) key. SigVer (public) key. General ECDSA (private) key. General EdDSA (private) key. General FFC (private) key. General RSA (private) key. General ECDSA (public) key.

Size ‐ Strength Size: 163, 233, 283, 409, 571, 163, 233, 283, 409, 571, 192, 224, 256, 384, 521 ‐ Strength: s < 112, s = 112, s = 128, s = 192, s = 256, s < 112, s = 112, s = 128, s = 192, s = 256, s < 112, s = 112, s = 128, s = 192, s = 256 Size: 255, 448 ‐ Strength: s = 128, s = 224 Size: 1024, 2048, 2048, 3072 ‐ Strength: s < 112, s = 112, s = 112, s = 128 Size: 1024, 2048, 3072, 4096, 6144, 8192 ‐ Strength: s ≤ 112, s = 112, s = 128, s = 152, s = 176, s = 200 Size: 233, 283, 409, 571, 233, 283, 409, 571, 224, 256, 384, 521 ‐ Strength: s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256 Size: 255, 448 ‐ Strength: s = 128, s = 224 Size: 2048, 2048, 3072 ‐ Strength: s = 112, s = 112, s = 128 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, s = 128, s = 152, s = 176, s = 200 Size: 233, 283, 409, 571, 233, 283, 409, 571, 224, 256, 384, 521 ‐ Strength: s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s

Type ‐ Category B‐163, B‐233, B‐283, B‐409, B‐ 571, K‐163, K‐233, K‐283, K‐409, K‐571, P‐192, P‐224, P‐256, P‐ 384, P‐521 ‐ PSP Edwards25519, Edwards448 ‐ PSP L=1024/N=160, L=2048/N=224, L=2048/N=256, L=3072/N=256 ‐ PSP k=1024, k=2048, k=3072, k=4096, k=6144, k=8192 ‐ PSP B‐233, B‐283, B‐409, B‐571, K‐ 233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521 ‐ CSP Edwards25519, Edwards448 ‐ CSP L=2048/N=224, L=2048/N=256, L=3072/N=256 ‐ CSP k=2048, k=3072, k=4096, k=6144, k=8192 ‐ CSP B‐233, B‐283, B‐409, B‐571, K‐ 233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521 ‐ PSP

Generated By Key management ECC Key management Edwards Key management FFC Key management IFC Key management ECC

Established By

Used By Signature ECDSA Signature EDDSA Signature DSA Signature RSA Key management ECC Key management Edwards Key management FFC Key management IFC Key management ECC

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name GKP_Public_Edwards GKP_Public_FFC GKP_Public_IFC KAS_Private_ECC KAS_Private_FFC KAS_Private_IFC KAS_Public_ECC KAS_Public_FFC

Description General EdDSA (public) key. General FFC (public) key. General RSA (public) key. Key pair component used for shared secret generation. Key pair component used for shared secret generation. Key pair component used for shared secret generation. Peer key pair component used for shared secret generation. Peer key pair component used for shared secret generation.

Size ‐ Strength = 192, s = 256, s = 112, s = 128, s = 192, s = 256 Size: 255, 448 ‐ Strength: s = 128, s = 224 Size: 2048, 2048, 3072 ‐ Strength: s = 112, s = 112, s = 128 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, s = 128, s = 152, s = 176, s = 200 Size: 233, 283, 409, 571, 233, 283, 409, 571, 224, 256, 384, 521 ‐ Strength: s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, 112 ≤ s ≤ 128, 112 ≤ s ≤ 152, 112 ≤ s ≤ 176, 112 ≤ s ≤ 200 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, s = 128, s = 152, s = 176, s = 200 Size: 233, 283, 409, 571, 233, 283, 409, 571, 224, 256, 384, 521 ‐ Strength: s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256, s = 112, s = 128, s = 192, s = 256 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, 112 ≤ s ≤ 128,

Type ‐ Category Edwards25519, Edwards448 ‐ PSP L=2048/N=224, L=2048/N=256, L=3072/N=256 ‐ PSP k=2048, k=3072, k=4096, k=6144, k=8192 ‐ PSP B‐233, B‐283, B‐409, B‐571, K‐ 233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521 ‐ CSP ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 ‐ CSP k=2048, k=3072, k=4096, k=6144, k=8192 ‐ CSP B‐233, B‐283, B‐409, B‐571, K‐ 233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521 ‐ PSP ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 ‐ PSP

Generated By Key management Edwards Key management FFC Key management IFC

Established By

Used By Key management Edwards Key management FFC Key management IFC Key agreement Key agreement Key agreement Key agreement Key agreement

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name KAS_Public_IFC KAS_SS_ECC KAS_SS_FFC KAS_SS_IFC KD_DKM_KDF KD_DKM_PBKDF KD_PW_PBKDF KD_SK KH_Key_AES‐CMAC KH_Key_AES‐GMAC KH_Key_HMAC KH_Key_KMAC KTS_KDK_IFC

Description Peer key pair component used for shared secret generation. Shared secret calculation z output value (for KDF). Shared secret calculation z output value (for KDF). Shared secret calculation z output value (for KDF). Key derivation derived keying material. PBKDF derived key material PBKDF password input. Key derivation source key material. Keyed Hash key. Keyed Hash key. Keyed Hash key. Keyed Hash key. RSA key de‐ encapsulation Key (key transport).

Size ‐ Strength 112 ≤ s ≤ 152, 112 ≤ s ≤ 176, 112 ≤ s ≤ 200 Size: 2048, 3072, 4096, 6144, 8192 ‐ Strength: s = 112, s = 128, s = 152, s = 176, s = 200 Size: 112 ‐ 256 ‐ Strength: 112 ‐ 256 Size: 112 ‐ 256 ‐ Strength: 112 ‐ 200 Size: 112 ‐ 256 ‐ Strength: 112 ‐ 200 Size: 128 ‐ 256 ‐ Strength: 128 ‐ 256 Size: 128 ‐ Strength: 128 Size: 128 ‐ Strength: 128 Size: 128 ‐ 256 ‐ Strength: 128 ‐ 256 Size: 128, 192, 256 ‐ Strength: s = 128, s = 192, s = 256 Size: 128, 192, 256 ‐ Strength: s = 128, s = 192, s = 256 Size: 112 ‐ 2048 ‐ Strength: 112 ‐ 256 Size: 128, 256 ‐ Strength: 112 ≤ s ≤ 128, 112 ≤ s ≤ 256 Size: 2048, 3072, 4096, 6144 ‐ Strength: s = 112, s = 128, s = 152, s = 176

Type ‐ Category k=2048, k=3072, k=4096, k=6144, k=8192 ‐ PSP Other ‐ CSP Other ‐ CSP Other ‐ CSP Other ‐ CSP Other ‐ CSP Other ‐ CSP Other ‐ CSP AES‐128, AES‐192, AES‐256 ‐ CSP AES‐128, AES‐192, AES‐256 ‐ CSP Other ‐ CSP KMAC128, KMAC256 ‐ CSP Other ‐ CSP

Generated By Key derivation Key derivation Key derivation

Established By Key agreement Key agreement Key agreement

Used By Key agreement Key agreement Key agreement Key agreement Key derivation Key derivation Key derivation Key derivation MAC AES (CMAC, GMAC) MAC AES (CMAC, GMAC) MAC HMAC MAC KMAC (XOF) Key transport

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Name KTS_KEK_IFC KTS_SS_IFC SC_EDK_AES SC_EDK_XTS

Description RSA key encapsulation Key (key transport). RSA key transport shared secret. Symmetric encryption and decryption. Symmetric encryption and decryption.

Size ‐ Strength Size: 2048, 3072, 4096, 6144 ‐ Strength: s = 112, s = 128, s = 152, s = 176 Size: 112 ‐ 256 ‐ Strength: s = 112 ‐ s = 176 Size: 128, 192, 256 ‐ Strength: s = 128, s = 192, s = 256 Size: 256, 512 ‐ Strength: s = 128, s = 256

Type ‐ Category Other ‐ PSP Other ‐ CSP AES‐128, AES‐192, AES‐256 ‐ CSP XTS‐128, XTS‐256 ‐ CSP

Generated By

Established By Key transport

Used By Key transport Key transport Cipher (Unauth) Cipher (Auth) Cipher (Unauth)

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 23: SSP Table 1 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 24: SSP Table 2 Keys used for CASTs and the temporary value used in the integrity test are not SSPs; however, the latter is deleted after use as required by AS05.10. The Module maintains only the Counter DRBG state used for key generation as a persistent CSP; this DRBG instance is used exclusively for approved services. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

Key/Algorithm Type Equivalent Strengths: Reference sources for the strengths provided in SSP Table 1 are specified below. Equivalent strength is given for each key or algorithm type (as some algorithms do not use or produce keys). Block Cipher (and related functions):  AES (AES‐128, AES‐192, AES‐256): SP 800‐57 Part 1 Rev. 5 Table

2. Digital Signature:  ECC (B‐163, B‐233, B‐283, B‐409, B‐571, K‐163, K‐233, K‐283, K‐409, K‐571, P‐192, P‐224, P‐256, P‐384, P‐521): SP 800‐186 Table 1 (provides approximate elliptic curve security strengths). SP 800‐186 and FIPS 140‐3 IG C.K indicate that the Binary (B‐) and Koblitz (K‐) curves are deprecated.  EdDSA (ED‐25519, ED‐448): SP 800‐186 Table 1.  FFC (DSA: L=1024/N=160, L=2048/N=224, L=2048/N=256, L=3072/N=256): SP 800‐57 Part 1 Rev. 5 Table
3. Security strength for L=2048/N=256 is determined in accordance with FIPS 140‐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.  IFC (RSA: k=1024, k=2048, k=3072, k=4096): SP 800‐57 Part 1 Rev. 5 Table
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. Secure Hash (and related functions):  SHA‐1, SHA2 (SHA2‐224, SHA2‐256, SHA2‐384, SHA2‐512, SHA2‐512/224, SHA2‐512/256): SP 800‐107 Rev. 1 Table 1.  SHA3 (SHA3‐224, SHA3‐256, SHA3‐384, SHA3‐512): SP 800‐57 Part 1 Rev. 5 Table 3.  SHAKE (SHAKE128, SHAKE256): SP 800‐185 Section 8.1. Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in SP 800‐57 Part 1 Rev. 5 Table
5. Message Authentication:  KMAC (KMAC128, KMAC256): SP 800‐56C Rev. 2 Table
6. Key Agreement:  KAS‐ECC‐SSC (B‐233, B‐283, B‐409, B‐571, K‐233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521): SP 800‐56A Rev. 3 Table 24.  KAS‐FFC‐SSC (FB, FC, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, modp‐2048, modp‐3072, modp‐4096, modp‐6144, modp‐8192): SP 800‐56A Rev. 3 Tables 25 and 26.  KAS‐IFC‐SSC (k=2048, k=3072, k=4096, k=6144, k=8192): SP 800‐56B Rev. 2 Table 4 (provides approximate security strengths). Key Agreement Key Derivation:  KDA OneStep: SP 800‐56C Rev. 2 Table 1 (hash), Table 2 (HMAC) and Table 3 (KMAC). This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

Algorithm or Test SW Integrity

Test Properties HMAC‐SHA2‐256 #A4481

Test Method HMAC over the complete module file image

Test Type SW/FW Integrity

Indicator FIPS_OK or PROV_R_FIPS_MODULE_IN_ERROR_STATE

Details

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

Table 25: Pre‐Operational Self‐Tests

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 26: Conditional Self‐Tests The intended usage of asymmetric key pairs generated by the Module is not known at the time when the key pair is generated and the pairwise consistency test (PCT) is performed. In all cases, a sign and verify PCT is performed.

Table 27: Pre‐Operational Periodic Information This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3 Table 28: Conditional Periodic Information This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

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‐test and all CASTs. All KATs must complete successfully prior to any other use of cryptography by the Module. The fips_self_test function (inclusive of software integrity verification) can also be called on demand, fulfilling AS05.11.

During the manufacturing process, ZPE Systems executes the build and installation instructions for the Module. The Module is pre‐installed and configured in supported ZPE Systems solutions. The approved mode is enabled by default. There are no additional installation, configuration, or usage instructions for operators intending to use the Module.

Guidance Documentation is inclusive of all information required per ISO/IEC 19790:2012 Section 7.11.9.

The inherent properties of the Module are:

1. Manual key entry is not supported.
2. Data output is inhibited during self‐tests, zeroization, SSP generation, and error states.
3. The Module does not perform any cryptographic function if any self‐test has failed. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy ZPE Systems FIPS Provider for OpenSSL 3

The Module implements mitigations for constant‐time implementations and blinding attacks.

Constant‐time implementations protect cryptographic implementations in the Module against timing analysis since such attacks exploit differences in execution time depending on the cryptographic operation, and constant‐time implementations ensure that the variations in execution time cannot be traced back to the key, CSP or secret data. Numeric blinding protects the RSA, DSA and ECDSA algorithms from timing attacks. These algorithms are vulnerable to such attacks since attackers can measure the time of signature operations or RSA decryption. To mitigate this, the Module generates a random blinding factor which is provided as an input to the decryption/signature operation and is discarded once the operation has completed and resulted in an output. This makes it difficult for attackers to attempt timing attacks on such operations without the knowledge of the blinding factor, and therefore the execution time cannot be correlated to the RSA/DSA/ECDSA key.

The mitigation mechanisms described in Section 12.2 are inherent within the validated algorithms. No other guidance or constraints are specified. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.