SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700

Certificate

Approved Algorithms (27)

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

flowchart LR
  %% Deterministic review-risk graph for SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700
  %% 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>upgrade<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<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 SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700
  %% 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>upgrade<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<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

SonicWall, Inc. SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, NSsp 13700 Firmware Version: SonicOS/X 7.0.1 Date: March 18th, 2025 Prepared for: Prepared by: SonicWall, Inc. Acumen Security, LLC.

Suite 395 Milpitas, CA 95035 Rockville, MD 20850 United States of America United States of America Phone: Phone: +1 703 375 9820 www.sonicwall.com www.acumensecurity.net Public Material

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

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This FIPS 140-3 non-proprietary Cryptographic Module Security Policy for the SonicWall, Inc. SonicWALL NSa 4700, Nsa 5700, NSa 6700, NSsp 10700, NSsp 11700 and NSsp 13700 models provides an overview of the product and a high-level description of how it meets the overall Level 2 security requirements of FIPS 140-3. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. SonicWall, Inc. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material
• May be reproduced only in its original entirety (without revision).

List of Figures Figure 10. Tamper-evident seal placements for NSa 4700/5700/6700 and NSsp 10700/11700/13700 ... 35 Public Material

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

1. General This document describes the cryptographic module security policy for the SonicWall, Inc. SonicWALL NSa 4700, Nsa 5700, NSa 6700, NSsp 10700, NSsp 11700 and NSsp 13700 models (FW version: SonicOS/X 7.0.1) cryptographic module (also referred to as the “module” hereafter). It contains the specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The Module, a hardware cryptographic module, meets the overall security level 2 requirements. The following table lists the level of validation for each area in FIPS 140-3: ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6. [Number Below]

1 General 2

2 Cryptographic module specification 2

3 Cryptographic module interfaces 2

4 Roles, services, and authentication 3

5 Software/Firmware security 2

6 Operational environment N/A

7 Physical security 2

8 Non-invasive security N/A

9 Sensitive security parameter management 2

10 Self-tests 2

11 Life-cycle assurance 2

12 Mitigation of other attacks 2

Table 1 - Security Levels Public Material

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

2. Cryptographic Module Specification The module is an Internet security appliance, which provides stateful packet filtering firewall, deep packet inspection, virtual private network (VPN), and traffic shaping services. The module is intended for use by US Federal agencies and other markets that require FIPS 140-3 validated cryptographic modules. The appliance Encryption technology uses Suite B algorithms. Suite B algorithms are approved by the U.S. government for protecting both Unclassified and Classified data. Module Description and Cryptographic Boundary The cryptographic module is defined as a multi-chip standalone hardware module. The cryptographic boundary of the module is the surfaces and edges of the device enclosure, inclusive of the physical ports. The physical form of the Module is depicted below. Figure
3. Front view of the NSa 4700 Figure
4. Front view of the NSa 5700 Figure
5. Rear view of the NSa 4700/NSa 5700 Figure
6. Front view of the NSa 6700 Public Material – May be reproduced only in its original entirety (without revision).

Figure

5. Rear view of the NSa 6700 Figure
6. Front view of the NSsp 10700 Figure
7. Front View of the NSsp 11700 Figure
8. Front View of the NSsp 13700 Figure
9. Rear View of the NSsp 10700/NSsp 11700/NSsp 13700 Public Material – May be reproduced only in its original entirety (without revision).

The cryptographic module tested configurations can be found in the table below: Model Hardware Firmware Version Distinguishing Features [Part Number and Version] NSa 4700 101-500668-55 (Rev A) SonicOS/X 7.0.1 Optional add in 1TB storage and redundant power supply, field replacement power supply and fan modules Nsa 5700 101-500667-52 (Rev A) SonicOS/X 7.0.1 Optional add in 1TB storage and redundant power supply, field replacement power supply and fan modules NSa 6700 101-500685-55 (Rev A) SonicOS/X 7.0.1 Optional add in 1TB storage and redundant power supply, field replacement power supply and fan modules NSsp 10700 101-500684-51 (Rev B) SonicOS/X 7.0.1 Field replacement power supply and fan modules NSsp 11700 101-500683-51 (Rev B) SonicOS/X 7.0.1 Field replacement power supply and fan modules NSsp 13700 101-500647-54 (Rev B) SonicOS/X 7.0.1 Field replacement power supply and fan modules Table 2 - Cryptographic Module Tested Configuration Public Material

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

Cryptographic Algorithms The Module implements the Approved and Non-Approved but Allowed cryptographic functions listed in the tables below. CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) AES FIPS 197 Key Sizes: 128, 192, A6598 CBC Encrypt, Decrypt SP800-38A 256 AES Authenticated FIPS 197 Key Sizes: 128, 192, Encrypt, A6598 SP800-38D GCM [38D]1 256 Authenticated Tag Len: 128 Decrypt, Message Authentication A2138 AES Conditioning Conditioning Key Size: 128 FIPS 197 Component CBC- component used Payload Length: 128 SP800-90B MAC in Entropy Source The module’s AES-GCM implementation conforms to IG C.H scenario #1 following RFC 5288 for TLS. The module is compatible with TLSv1.2 (RFC 7627) and provides support for the acceptable GCM cipher suites from Section 3.3.1 of SP 800-52 Rev1 or SP 800-52 Rev2. The counter portion of the IV is set by the module within its cryptographic boundary. The construction of the 64-bit nonce_explicit part of the IV is deterministic via a monotonically increasing counter. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established. The module’s AES GCM implementation also conforms to IG C.H Scenario #5 following RFC 8446 for TLS 1.3 and provides support for the acceptable GCM cipher suites from Section B.4 of RFC 8446 and confirms that the IV is generated and used within the protocol’s implementation. Public Material

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

CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) Vendor CKG Affirmed NIST SP 800133rev2 Section 4 Key Generation N/A CVL KDF TLS v1.3 A6598 RFC 8446 (as per Section 7.1 of SHA2-256, SHA2- Key Derivation RFC 8446) 384 CVL IKEv1 A6598 NIST SP 800- SHA2-256, SHA2- Key Derivation Digital Signature and 135rev1 384, SHA2-512 PSK CVL IKEv2 SHA2-256, SHA2A6598 NIST SP 800- Key Derivation DH 224-521 bits 384, SHA2-512 135rev1 CVL SHA2-256, SHA2A6598 NIST SP 800- TLS v1.2 (RFC 7627) Key Derivation 384, SHA2-512 135rev1 P-224, P-256, P-384, A6598 ECDSA (FIPS186-5) SigGen Signature P-521 Generation A6598 ECDSA (FIPS186-5) SigVer P-256, P-384, P-521 Signature Verification Deterministic A6598 DRBG Mode: SHA2-256 Random Bit SP800-90Arev1 Hash DRBG Entropy Input: 256 Generation Nonce: 128 Public Material

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

CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A6598 ECDSA P-224, P-256, P-384, Key Pair KeyGen FIPS PUB 186-5 P-521 Generation A6598 ECDSA P-224, P-256, P-384, Key Pair KeyVer FIPS PUB 186-5 P-521 Validation MAC: 32-160 Message HMAC Increment 8 Authentication, A6598 FIPS PUB 198-1 HMAC-SHA-1 Key Length: 8- KDF Primitive

MAC: 32-256 A6598 HMAC Increment 8 FIPS PUB 198-1 HMAC-SHA-256 Key Length: 8-

MAC: 32-384 A6598 HMAC Increment 8 FIPS PUB 198-1 HMAC-SHA-384 Key Length: 8-

MAC: 32-512 A6598 HMAC Increment 8 FIPS PUB 198-1 HMAC-SHA-512 Key Length: 8-

Domain Parameter KAS-FFC-SSC (SP 800- Generation 56Arev3 Shared Methods: FB, FC, A6598 KAS-1 Secret Computation, ffdhe2048, MODP- Key Agreement [IG D.F] Per Scenario 2 of IG 2048; provides 112 D.F) bits of encryption strength Domain Parameter KAS-ECC-SSC (SP 800- Generation 56Arev3 Shared Methods: P-256, PA6598 KAS-2 Secret Computation, 384, P-521; provides Key Agreement [IG D.F] Per Scenario 2 of IG between 128 and D.F) 256 bits of encryption strength Public Material

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

CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) AES-CBC (Key Sizes: Key Transport/ A6598 KTS-1 AES-CBC with HMAC- 128, 256); HMAC- Authentication [IG D.G] SHA-1 SHA-1; provides 128 (TLS 1.2) or 256 bits of encryption strength AES-CBC (Key Sizes: Key Transport/ A6598 KTS-2 AES-CBC with HMAC- 128, 256); HMAC- Authentication [IG D.G] SHA2-256 SHA2-256; provides (TLS 1.2)

encryption strength AES-GCM (Key Sizes: Key Transport A6598 KTS-3 AES-GCM 128, 256); provides (TLS 1.3) [IG D.G] 128 or 256 bits of encryption strength A6598 RSA KeyGen Mod: 2048, 3072, Key Generation (FIPS 186-5) 4096 A6598 RSA Mod: 2048, 3072, Signature SigGen: PKCS 1.5 (FIPS 186-5) 4096 Generation A6598 RSA Mod: 2048, 3072, Signature SigVer: PKCS 1.5 (FIPS 186-5) 4096 Verification Safe Prime Groups: NIST SP 800-56A, A6598 Safe Primes ffdhe2048, MODP- Key Generation Rev3 2048 Safe Prime Groups: NIST SP 800-56A, A6598 Safe Primes ffdhe2048, MODP- Key Verification Rev3 2048 SHA-1 Message Length: 0- Message Digest A6598 SHS SHA-256 65536 Increment 8 Generation FIPS PUB 180-4 SHA-384 SHA-512 Intel entropy source For seeding DRBG N/A SP 800-90B N/A is used and meets SP800-90B and IG D.K compliance Table 3

• Approved Algorithms Note: There are some algorithms, modes, moduli and key sizes that have been CAVP tested but are not implemented/used by the module. Only the algorithms, modes, and key sizes shown in this table are implemented by the module. Public Material
• May be reproduced only in its original entirety (without revision).

Algorithm Caveat Use / Function DSA Allowed per I.G. C.K resolution #3. Used as part of SP 800-56Ar3 key (PQGGen and KeyGen tests agreement performed) Table 4

• Non-Approved Algorithms Allowed in the Approved Mode of Operation The module supports the following non-Approved but allowed algorithms with no security claimed: Algorithm Caveat Use / Function Triple-DES No security claimed Associated with the configuration setting. Used to encrypt/decrypt Gateway Anti-Virus (GAV) signature files (internal to the module only) (This function is considered obfuscation and cannot be used to store or transmit sensitive information) MD5 No security claimed Used to obfuscate RADIUS and TACACS+ (always encapsulated using IPsec) PBKDF (non- No security claimed Associated with RADIUS (always compliant) encapsulated using IPsec) Table 5
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The module supports the following Non-Approved Algorithms Not Allowed in the Approved Mode of Operation: Algorithm/Function Use / Function KDF-SSH Used for SSH operations in the non-approved mode KDF-SNMP Used for SNMP operations in the non-approved mode Table 5a
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Public Material
• May be reproduced only in its original entirety (without revision).

Protocol2 Key Exchange Auth Cipher Integrity IKEv1 DH Group 14, 19, 20, 21 RSA and ECDSA AES CBC HMAC-SHA-256-128 digital signature 128/192/256 HMAC-SHA-384-192 HMAC-SHA-512-256 IKEv2 DH Group 14, 19, 20, 21 RSA and ECDSA AES CBC HMAC-SHA-256-128 Digital Signature 128/192/256 HMAC-SHA-384-192 HMAC-SHA-512-256 Shared Key Message Integrity Code IPsec ESP IKEv1 or IKEv2 with optional: IKEv1, AES CBC HMAC-SHA-256-128 Diffie-Hellman (L=2048, IKEv2 128/192/256 HMAC-SHA-384-192 N=224, 256) HMAC-SHA-512-256 EC Diffie-Hellman P-256, P-

TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS 1.3 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 Table 6 - Security Relevant Protocols Used in Approved Mode Modes of Operation Approved Mode of Operation The Approved mode configuration can be determined by the operator, by checking the state of the “Approved Mode” checkbox on the System/Settings page over the web interface or issuing “show fips” command over the console. When the “Approved mode” checkbox is selected, the module executes a compliance checking procedure, examining all settings related to the security rules described below. The operator is responsible for appropriately updating these settings during setup and will be prompted by the compliance tool if a setting has been modified taking the module out of compliance. The “Approved mode” checkbox and corresponding system flag (“fips”), which can be queried over the console, will not be set unless all settings are compliant. The “Approved mode” checkbox and fips system flag are indicators that the module is running in the Approved mode of operation. No parts of the TLS or IKE protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Public Material

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

The module is not configured to operate in Approved mode by default. The following steps shall be taken during set-up of the module to enable Approved mode of operation:

1. The default Administrator and User passwords shall be immediately changed and be at least eight (8) characters.
2. The RADIUS/TACACS+ shared secrets shall be at least eight (8) characters.
3. Traffic between the module and the RADIUS/TACACS+ server shall be secured via an IPsec tunnel. *Note: This step only needs to be performed if RADIUS or TACACS+ is supported. • LDAP cannot be enabled in Approved mode without being protected by TLS • LDAP cannot be enabled in Approved mode without selecting 'Require valid certificate from server' • LDAP cannot be enabled in Approved mode without valid local certificate for TLS
4. IKE shall be configured with 3rd Party Certificates or Preshared key for IPsec Keying Mode when creating VPN tunnels. o RSA Certificates lengths shall be 2048-bit or greater in size. o ECDSA Certificates curves shall be P-256, P-384 or P-521 only. or o Preshared key lengths shall be no less than 8 characters.
5. When creating VPN tunnels, ESP shall be enabled for IPSec.
6. Approved algorithms shall be used for encryption and authentication when creating VPN tunnels.
7. Group 14, 19, 20 or 21 shall be used for IKE Phase 1 DH Group. SHA-256 and higher shall be used for Authentication 8. “Advanced Routing Services” shall not be enabled. 9. “Group VPN management” shall not be enabled.
8. SNMP or SSH shall not be enabled.
9. The “SonicWALL Read-Only Admins,” group, satisfies neither the Cryptographic Officer nor the User Role and shall not be used in the Approved mode operation. Note: Once the Approved mode of operation is enabled, SonicOSX enforces all of the above items. (Operators will not be allowed to change these features while in Approved mode of operation.) Additionally: The operator shall not enable the following : • USB interface(s) • Wireless interface • 802.11i wireless security Public Material – May be reproduced only in its original entirety (without revision).

Non-Approved Mode of Operation The Cryptographic Module provides the same set of services in the non-Approved mode as in the Approved mode but allows the following additional administration options and non-approved services which are not used in the Approved mode of operation. The following services shall be disabled before placing the module in Approved mode. The module does not transition to Approved mode until the following services are disabled. • AAA server authentication (the Approved mode requires operation of RADIUS or TACACS+ only within a secure VPN tunnel) • SSH • SNMP Security Rules and Guidance This section documents the security rules for the secure operation of the cryptographic module to implement the security requirements of FIPS 140-3.

1. The module provides two distinct operator roles: User and Crypto Officer.
2. The module provides identity-based authentication for the Crypto Officer and for the User.
3. The module clears previous authentications on power cycle.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The module allows the operator to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by power cycling or resetting the module.
6. Self-tests do not require any operator action.
7. Data output is inhibited during, pre-operational self-tests, zeroization, and error states.
8. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the module.
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The module does not support a maintenance interface or role.
11. The module does not support manual key entry.
12. The module does not have any proprietary external input/output devices used for entry/output of data.
13. The module does not enter or output plaintext SSPs.
14. The module does not output intermediate key values.
15. The module does not support a bypass capability.
16. Firmware upgraded in the non-approved mode cannot be used in the approved mode. (The module enforces the deletion of any firmware upgrade before the approved mode can be entered.) Public Material – May be reproduced only in its original entirety (without revision).

Applicable Implementation Guidance 2.4.B Tracking the Component Validation List The key derivation functions for IKEv1, IKEv2, TLS v1.2 RFC7627, and TLS v1.3 are only used in the context of their respective protocols. C.B Validation Testing of Hash Algorithms and Higher Cryptographic Algorithm Using Hash Algorithms Every approved hash algorithm implementation has been CAVP tested as shown in Table

3. C.F RSA Approved Parameter Sizes in FIPS 186-5 The RSA modulus lengths supported by the module for RSA signature generation are 2048, 3072, and 4096 bits. CAVP testing was performed for the implemented RSA signature algorithm implementation. For FIPS 186-5 signature verification, the module supports the allowed mod sizes of 2048, 3072, 4096. The MillerRabin testing rounds are consistent with Table B.1 of FIPS 186-5. C.H Key/IV Pair Uniqueness Requirements from SP 800-38D Please see Footnote #1. D.C References to the Support of Industry Protocols The KDFs implemented are those described in SP 800-135rev1. (IKEv1, IKEv2, TLS v1.2 RFC7627, and TLS v1.3). All implemented KDFs have been CAVP tested under Cert. #A6598. No parts of the protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. D.H Requirements for Vendor Affirmation to SP 800-133r2 The relevant sections of SP 800-133r2 are Section
4. Self-Initiated Cryptographic Output The module implements a self-initiated cryptographic output capability for IPSec VPN. As part of enabling the service, the Crypto Officer shall configure the IPSec VPN client policy and enable it. Following this, the Crypto Officer shall turn on the "Enable Keep Alive" switch under the "Advanced" tab in the VPN Policy settings. Public Material – May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The module’s ports and associated FIPS 140-3 defined logical interface categories are listed in the tables in this section: Physical Port Logical Interface3 Data that passes over port/interface MGMT Port Data Input, Unit administration data Data Output, Status Output and Control Input Status LEDs Status Output Status Serial Console Port Status Output and Unit administration data Control Input Ethernet Ports Data Input, Network connection data Data Output, Status Output and Control Input (via the external GUI Administration interface) Safe Mode Control Input Used to manually reset (bootloader)/Reset the appliance Button Power Interface N/A N/A Table 7 – Ports and Interfaces
4. Roles, Services, and Authentication Assumption of Roles The cryptographic module provides the roles of Crypto Officer and User. The cryptographic module does not provide a Maintenance role. The built-in “Administrator” is a member of “SonicWALL Administrators” group on the module, and the name used to login may be configured by the Cryptographic Officer role; the default username for the “Administrator” is “admin”. The User role is authenticated using the credentials of a member of the “Limited Administrators” group. The configuration settings required to enable the Approved mode of operation is specified in Section
5. The built-in administrator for which the default username is “admin” which is a member of “SonicWALL Administrators” group has full control privilege to query status and configure all firewall configurations including configure other user privilege. Other members of “SonicWALL Administrators” group have the same full control privilege as built-in administrator (part of “SonicWALL Administrators” group). There is another group called “Limited Administrators”. Members of “Limited Administrators” group can query Control Output Interface is omitted as it is Not Applicable. Public Material – May be reproduced only in its original entirety (without revision).

status and non-critical configuration. An operator is granted privilege by the membership of a particular group after login. Role Service Input Output CO (referred to as Show Status Command Command Response “SonicWALL Show Non-critical Command Command Response Administrators” group) Configuration Monitor Network Command Command Response Status Log On Username and Successful completion Password or public key of service Log Off Command Command Response Clear Log Command Command Response Export Log Command Command Response Import/Export Commands and Public Public Key Certificates Key Filter Log Command Command Response Setup DHCP Server Command Command Response Generate Log Reports Command Command Response Configure VPN Settings Commands, Preshared Command Response Key IPsec VPN SSPs and Encrypted SSPs and Encrypted Data Data TLS SSPs and Encrypted SSPs and Encrypted Data Data Set Content Filter Command Command Response Configure DNS Settings Command Command Response Configure Access Command Command Response Zeroize Command Status Output indicating the completion of service. Perform Self-tests on- Command Output display on each demand algorithm running selftest and pass or fail Self-Initiate SSPs and Encrypted SSPs and Encrypted Cryptographic Output Data Data User (referred to as Show Status Command Command Response “Limited Show Non-critical Command Command Response Administrators” group) Configuration Monitor Network Command Command Response Status Log On Username and Successful completion Password or public key of service Log Off Command Command Response Export Log Command Command Response Filter Log Command Command Response Generate Log Reports Command Command Response Public Material

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

Role Service Input Output TLS SSPs and Encrypted SSPs and Encrypted Data Data Configure DNS Settings Command Command Response Unauthenticated Module Reset Command Command Response No Auth Function Command Command Response Show Status N/A N/A (LED/Console) Perform Self-tests on- Power Cycle Output display on each demand algorithm running selftest and pass or fail Table 8 – Roles, Service Commands, Input and Output The Module supports concurrent operators. Separation of roles is enforced by requiring operators to authenticate using either a username and password, or digital signature verification. The User role requires the use of a username and password or possession of the private key of a user entity belonging to the “Limited Administrators” group. The Crypto Officer role requires a username and password for authentication. Multiple users may be logged in simultaneously, but only a single user-session can have full configuration privileges at any time, based upon the prioritized preemption model described below:

1. The Admin user (SonicWALL Administrators) has the highest priority and can preempt any users.
2. The additional operators who are members of the “SonicWALL Administrators” group can preempt any users except for the Admin user.
3. An operator that is a member of the “Limited Administrators” group can only preempt other members of the “Limited Administrators” group. Session preemption may be handled in one of two ways, configurable from the System > Administration page, under the “On admin preemption” setting: 1. “Drop to non-config mode” – the preempting operator will have three choices: a. “Continue” – this action will drop the existing administrative session to a “non-config mode” and will impart full administrative privileges to the preempting user. b. “Non-Config Mode” – this action will keep the existing administrative session intact and will login the preempting user in a “non-config mode”. c. “Cancel” – this action will cancel the login and will keep the existing administrative session intact. 2. “Log-out” – the preempting user will have three choices: a. “Continue” – this action will log out the existing administrative session and will impart full administrative privileges to the preempting user. b. “Non-Config Mode” – this action will keep the existing administrative session intact and will login the preempting user in a “non-config mode”. c. “Cancel” – this action will cancel the login and will keep the existing administrative session intact. “Non-config mode” administrative sessions will have no privileges to cryptographic functions making them functionally equivalent to User role sessions. The ability to enter “Non-config mode” may be disabled altogether from the System > Administration page, under the “On admin preemption” setting by selecting “Log out” as the desired action. Public Material – May be reproduced only in its original entirety (without revision).

Authentication Methods The cryptographic module provides authentication relying upon username/passwords or an RSA 2048-bit (at a minimum) digital signature verification. Role Authentication Method Authentication Strength CO and User password Username and Password The probability is 1 in 96^8, which is less than one in (Identity-based) (Passwords shall be at least 1,000,000 that a random eight (8) characters long, and attempt will succeed, or a false the password character set is acceptance will occur for each ASCII characters 32-127, which attempt (This is also valid for is 96 ASCII characters, hence, RADIUS shared secret keys). the probability is 1 in 96^8) After three (3) successive unsuccessful password verification tries, the cryptographic module pauses for one second before additional password entry attempts can be reinitiated This makes the probability approximately 180/96^8 = 2.5E14, which is less than one in 100,000 that a random attempt will succeed, or a false acceptance will occur in a oneminute period User RSA 2048-bit (minimum) Digital Signature The probability that a random digital signature attempt will succeed, or a false (Identity-based) (A 2048-bit RSA digital signature acceptance will occur is has a strength of 112-bits; 1/2^112, which is less than 1 in hence the probability is 1,000,000. Due to processing 1/2^112) and network limitations, the module can verify at most 300 signatures in a one-minute period. Thus, the probability that a random attempt will succeed, or a false acceptance will occur in a one-minute period is 300/2^112 = 5.8E-32, which is less than 1 in 100,000 Unauthenticated N/A N/A Table 9

• Roles and Authentication Public Material
• May be reproduced only in its original entirety (without revision).

Services Crypto Officer Services The Crypto Officer role is authenticated using the credentials of the “Administrator” user, which is the member of “SonicWALL Administrators” group (also referred to as “Admin”), or the credentials of other members (users) of the “SonicWALL Administrators” group. The use of “SonicWALL Administrators” provides identification of specific users (i.e., by username) upon whom is imparted full administrative privileges. The Cryptographic Officer role can show all status and configure cryptographic algorithms, cryptographic keys, certificates, and servers used for VPN tunnels. The Crypto Officer sets the rules by which the module encrypts, and decrypts data passed through the VPN tunnels. The authentication mechanisms are discussed in Table 9. The modes of access shown in the table is defined as:

• 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 Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Show Status Monitoring, N/A N/A Crypto Officer, N/A Approved pinging, User, Mode traceroute, Unauthenticated Checkbox viewing logs (LED Checked activity/Console) in WebUI, Show Status = “FIPS” Show Non- “Show” N/A N/A Crypto Officer, N/A Approved critical commands User Mode Configuration that enable Checkbox the operator Checked to view VPN in tunnel status WebUI, and network Show configuration Status = parameters “FIPS” The same services are available in the non-Approved mode of operation. In the non-Approved mode of operation, the non-Approved functions listed in Tables 4 and 5 can be utilized. Public Material
• May be reproduced only in its original entirety (without revision).

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs N/A Approved N/A N/A Crypto Officer, Mode User Checkbox Monitor Monitor the Checked Network network in Status status WebUI, Show Status = “FIPS” Crypto Officer Logs the CO N/A Password Crypto Officer E Approved Log On into the Mode module Checkbox Checked in WebUI User Log On Logs the User RSA Authentication User E Approved into the Public Key Mode module Checkbox Checked in WebUI, Show Status = “FIPS” Crypto Officer Logs the CO N/A N/A Crypto Officer E Approved Log Off off the Mode module Checkbox Checked in WebUI, Show Status = “FIPS” User Log Off Logs the User N/A N/A User E Approved off the Mode module Checkbox Checked in WebUI, Show Status = “FIPS” Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Clear Log Clears session N/A N/A Crypto Officer N/A Approved log Mode Checkbox Checked in WebUI, Show Status = “FIPS” Export Log Export N/A N/A Crypto Officer, N/A Approved session log User Mode Checkbox Checked in WebUI, Show Status = “FIPS” Import/Export Session key RSA, Root CA Public Crypto Officer E, R Approved Certificates management ECDSA Key Mode Checkbox Checked in WebUI, Show Status = “FIPS” Filter Log Session log N/A N/A Crypto Officer, N/A Approved management User Mode Checkbox Checked in WebUI, Show Status = “FIPS” Setup DHCP Setup and N/A N/A Crypto Officer N/A Approved Server5 configure a Mode DHCP Server Checkbox Checked Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs in WebUI, Show Status = “FIPS” Generate Log Generate Log N/A N/A Crypto Officer, N/A Approved Reports Reports User Mode Checkbox Checked in WebUI, Show Status = “FIPS” Configure System Shared Preshared Crypto Officer G, W Approved VPN Settings configuration, Secret, Key, IKE Mode network RSA or Private Key, Checkbox configuration, ECDSA Root CA Public Checked Security Key, IKE Public in services Key WebUI, including Show initiating Status = encryption, “FIPS” key management, and VPN tunnels IPsec VPN Network Shared IKE Shared Crypto Officer, G, W, Approved traffic over Secret, Secret, User E Mode an IPsec VPN AES, SKEYID, Checkbox HMAC, SKEYID_d, Checked RSA or SKEYID_a, in ECDSA, SKEYID_e, WebUI, KAS-FFC- Preshared Show SSC, KAS- Key, IKE Status = ECC-SSC, Session “FIPS” DRBG Encryption Key, IKE Session Authentication Key, IKE Private Key, Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs IPsec Session Encryption Key, Ipsec Session Authentication Key, DH/ECDH Private Key, DRBG V and C values, DRBG seed, Entropy Input, RADIUS Shared Secret, Storage Key TLS TLS used for DRBG, TLS Master Crypto Officer, G, W, Approved the https RSA or Secret, TLS User E Mode configuration ECDSA, Premaster Checkbox tool or AES, Secret, TLS Checked network HMAC, Extended in traffic over a KAS-FFC- Master Secret WebUI, TLS VPN SSC, KAS- (TLS 1.2), TLS Show ECC-SSC Private Key, Status = TLS Session “FIPS” Key, TLS Integrity Key, ECDH Private Key, DRBG V and C values, DRBG seed, Entropy Input, TLS Public Key, ECDH Public Key Set Content Network N/A N/A Crypto Officer N/A Approved Filter configuration Mode settings Checkbox Checked in WebUI, Show Status = “FIPS” Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Configure Configure N/A N/A Crypto Officer, N/A Approved DNS Settings DNS Settings User Mode Checkbox Checked in WebUI, Show Status = “FIPS” Configure Configure Password Password Crypto Officer W Approved Access User and Mode Crypto Checkbox Officer access Checked in WebUI, Show Status = “FIPS” Zeroize Zeroize SSPs N/A All SSPs Crypto Officer Z Approved Mode Checkbox Checked in WebUI, Show Status = “FIPS” Perform Self Perform Self N/A N/A Crypto Officer, N/A Approved tests on- tests on- Unauthenticated Mode demand demand (power-cycle) Checkbox Checked in WebUI, Show Status = “FIPS” Self-Initiated This service is Shared IKE Shared Crypto Officer G, E Approved Cryptographic enabled for Secret, Secret, Mode Output IPSec VPN. As HMAC, SKEYID, Checkbox part of AES, RSA SKEYID_d, Checked enabling this or ECDSA, SKEYID_a, in Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs service, the KAS-FFC- SKEYID_e, WebUI, CO must SSC, KAS- Preshared Show configure and ECC-SSC, Key, IKE Status = enable the DRBG Session “FIPS” IPSec VPN Encryption client policy, Key, IKE and then turn Session on the Authentication "Enable Keep Key, IKE Alive" switch Private Key, under the IPsec Session "Advanced" Encryption tab in the Key, Ipsec VPN Policy Session settings. Authentication Key, DH/ECDH Private Key, DRBG V and C values, DRBG seed, Entropy Input, Root CA Public Key, IKE Public Key, Peer IKE Public Key, DH/ECDH Public Key Module Reset Firmware N/A N/A Unauthenticated Z Approved removal with Mode configuration Checkbox returned to Checked factory state in WebUI, Show Status = “FIPS” Public Material

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

Service4 Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs No Auth Power Cycle, N/A N/A Unauthenticated N/A Approved Function Cable Plugin, Mode View LEDs Checkbox Checked in WebUI, Show Status = “FIPS” Table 10

• Approved Services Algorithms Service Description Role Indicator Accessed Approved Mode Crypto Officer, User, Monitoring, pinging, Checkbox Unauthenticated Show Status traceroute, viewing Unchecked in (LED logs WebUI, Show Status activity/Console) = “NO FIPS” “Show” commands that enable the Approved Mode operator to view Checkbox Show Non-critical VPN tunnel status Crypto Officer, User Unchecked in Configuration and network WebUI, Show Status configuration = “NO FIPS” parameters Approved Mode Checkbox Monitor Network Monitor the Crypto Officer, User Unchecked in Status network status WebUI, Show Status = “NO FIPS” Crypto Officer Log Logs the CO into the Approved Mode Crypto Officer Checkbox On module Unchecked in Public Material
• May be reproduced only in its original entirety (without revision).

Algorithms Service Description Role Indicator Accessed WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Crypto Officer Log Logs the CO off the Crypto Officer Unchecked in Off module WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Clear Log Clears session log Crypto Officer Unchecked in WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Export Log Export session Log Crypto Officer, User Unchecked in WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Import/Export Session key RSA or DSA Crypto Officer Unchecked in Certificates management WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Session log Filter Log Crypto Officer, User Unchecked in management WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Setup and configure Setup DHCP Server Crypto Officer Unchecked in a DHCP Server WebUI, Show Status = “NO FIPS” Public Material

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

Algorithms Service Description Role Indicator Accessed Approved Mode Checkbox Generate Log Generate Log Crypto Officer Unchecked in Reports Reports WebUI, Show Status = “NO FIPS” System configuration, network Approved Mode configuration, Checkbox Configure VPN Security services RSA or ECDSA Crypto Officer Unchecked in Settings including initiating WebUI, Show Status encryption, key = “NO FIPS” management, and VPN tunnels. Approved Mode AES, HMAC, RSA or Checkbox Network traffic over ECDSA, KAS-FFCIPsec VPN Crypto Officer Unchecked in an IPsec VPN SSC, KAS-ECC-SSC, WebUI, Show Status DRBG = “NO FIPS” TLS used for the Approved Mode DRBG, RSA or https configuration Checkbox ECDSA, AES, HMAC, TLS tool or network Crypto Officer, User Unchecked in KAS-FFC-SSC, KAStraffic over a TLS WebUI, Show Status ECC-SSC VPN = “NO FIPS” Approved Mode Network Checkbox Set Content Filter configuration Crypto Officer Unchecked in settings WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Configure DNS Configure DNS Crypto Officer, User Unchecked in Settings Settings WebUI, Show Status = “NO FIPS” Public Material

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

Algorithms Service Description Role Indicator Accessed Approved Mode Checkbox Configure User and Configure Access Crypto Officer Unchecked in CO access WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Zeroize Zeroize SSPs Crypto Officer Unchecked in WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Perform Self tests Perform Self tests Crypto Officer, Unchecked in on-demand on-demand Unauthenticated WebUI, Show Status = “NO FIPS” This service is enabled for IPSec VPN. As part of enabling this service, the CO Approved Mode must configure and HMAC, AES, RSA or Self-Initiated Checkbox enable the IPSec ECDSA, KAS-FFCCryptographic Crypto Officer Unchecked in VPN client policy, SSC, KAS-ECC-SSC, Output WebUI, Show Status and then turn on DRBG = “NO FIPS” the Enable Keep Alive switch under the Advanced tab in the VPN Policy settings Approved Mode Checkbox Logs the User into User Log On RSA User Unchecked in the module WebUI, Show Status = “NO FIPS” Public Material

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

Algorithms Service Description Role Indicator Accessed Approved Mode Checkbox Logs the User off User Log Off User Unchecked in the module WebUI, Show Status = “NO FIPS” Approved Mode Firmware removal Checkbox with configuration Module Reset Unauthenticated Unchecked in returned to factory WebUI, Show Status state = “NO FIPS” Approved Mode Checkbox Power Cycle, Cable No Auth Function Unauthenticated Unchecked in Plugin, View LEDs WebUI, Show Status = “NO FIPS” Approved Mode Checkbox Upgrade Module Firmware Update Crypto Officer Unchecked in Firmware WebUI, Show Status = “NO FIPS” SSH-KDF, SHA2-256, Approved Mode SHA2-512, Checkbox SSH SSH Service Hash_DRBG, KAS- Crypto Officer Unchecked in ECC-SSC, AES-GCM, WebUI, Show Status RSA SigGen = “NO FIPS” Approved Mode Checkbox SNMP SNMP Service SNMP-KDF Crypto Officer Unchecked in WebUI, Show Status = “NO FIPS” Table 11

• non-Approved Services Public Material
• May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The module is a hardware module with firmware (SonicOS/X 7.0.1) running on it. The Module uses SHA2-

256 (Cert. #A6598) performed over all module firmware as the integrity technique/EDC. The operator can

initiate the integrity test on demand by power cycling the module. The temporary values generated during the integrity test are cleared automatically by the module from the memory after the test is completed. The module does not support the external loading of firmware in the Approved mode of operation.

6. Operational Environment The module operates in a non-modifiable operational environment per FIPS 140-3 specifications, as the module does not support external firmware loading.
7. Physical Security The chassis of the multi-chip standalone cryptographic modules are opaque within the visible spectrum, and direct observation of the modules' internal components is not possible. The chassis are sealed with either 1 or 2 tamper-evident seals (depending on model), applied during manufacturing. The physical security of the module is intact if there is no evidence of tampering with the tamper-evident seal(s). Physical Security Mechanism Recommended Frequency of Inspection Guidance Details Inspection Tamper-evident seals Periodic inspection of tamper- If evidence of tamper is found, evident seals once every 6 months the Cryptographic Officer is requested to follow their internal IT policies, which may include contacting SonicWALL for replacing the unit Table 12 – Physical Security Inspection Guidelines Table 13 below lists the number of tamper-evident seals applied per model: # Model Number of tamper-evident seals(s)/module

1 NSa 4700 341-000041-51 (1pcs) and 341-000029-51 (1pcs)

2 NSa 5700 341-000041-51 (1pcs) and 341-000029-51 (1pcs)

3 NSa 6700 341-000041-51 (1pcs) and 341-000029-51 (1pcs)

4 NSsp 10700 341-000041-51 (1pcs) and 341-000029-51 (2pcs)

5 NSsp 11700 341-000041-51 (1pcs) and 341-000029-51 (2pcs)

6 NSsp 13700 341-000041-51 (1pcs) and 341-000029-51 (2pcs)

Table 13

• Number of Tamper-Evident Seals Public Material
• May be reproduced only in its original entirety (without revision).

The locations of the tamper-evident seals (highlighted by red rectangles) are indicated in Figure 10 (below): Figure 10. Tamper-evident seal placements for NSa 4700/5700/6700 and NSsp 10700/11700/13700 Public Material

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

8. Non-Invasive Security Not Applicable. The module does not implement non-invasive security measures. Public Material

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

9. Sensitive Security Parameter Management All SSPs used by the Module are described in this section. Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number IKE Shared String: 32 - Shared Generated Internally Neither Established as a Temporarily Zeroize Shared secret Secret 256 bytes Secret Input nor part of IKE in Service, used during A6598 Output exchange RAM Power Cycle IKE Phase 1 process (Plaintext) or IKE session termination SKEYID 256, 384 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Secret value 512-bits HMAC Input nor part of IKE in Service, used to derive A6598 Output exchange RAM Power Cycle other IKE process (Plaintext) or IKE secrets session termination SKEYID_d 256, 384 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Secret value 512-bits HMAC Input nor part of IKE in Service, used to derive A6598 Output exchange RAM Power Cycle keys for process (Plaintext) or IKE security session associations termination SKEYID_a 256, 384 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Secret value 512-bits HMAC Input nor part of IKE in Service, used to derive A6598 Output exchange RAM Power Cycle keys to process (Plaintext) or IKE authenticate session IKE messages termination SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number SKEYID_e 256, 384 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Secret value 512-bits HMAC Input nor part of IKE in Service, used to derive A6598 Output exchange RAM Power Cycle keys to encrypt process (Plaintext) or IKE IKE messages session termination Preshared Key A minimum IKE KDF Not Applicable Input Not Applicable Flash Zeroize Used to of A6598 electronically (Encrypted Service authenticate

8 characters by AES CBC the module to

256-bit) a peer during IKE IKE Session 128, 192 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Used to Encryption Key 256-bit AES (CBC) during SSP Input nor part of IKE in Service, establish A6598 establishment Output exchange RAM Power Cycle phase 2 tunnel process (SP800- (Plaintext) or IKE 56a rev3 and session SP800-135 KDF) termination IKE Session 256, 384 or IKE KDF Generated Internally Neither Established as a Temporarily Zeroize Used to Authentication 512-bits HMAC during SSP Input nor part of IKE in Service, establish phase Key A6598 establishment Output exchange RAM Power Cycle 2 tunnel process (SP800- (Plaintext) or IKE 56a rev3 and session SP800-135 KDF) termination IKE Private Key 2048-bit RSA Generated as per Neither Not Applicable Flash Zeroize Used as a part or or SP800-90A DRBG and Input nor (Plaintext) Service of IKE process P-256, P-384 ECDSA FIPS 186-5 compliant Output or P-521 CKG RSA or ECDSA key A6598 generation SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number IPsec Session 128, 192 or AES (CBC) Generated Internally Neither Established as a Temporarily Zeroize Used to Encryption Key 256-bit A6598 during SSP Input nor part of IKE in Service, encrypt data establishment Output - exchange RAM Power Cycle process (SP800- (Plaintext) or 56a rev3 and IPsec session SP800-135 KDF) termination IPsec Session 256, 384 or HMAC Generated Internally Neither Established as a Temporarily Zeroize Used for data Authentication 512-bits A6598 during SSP Input nor part of IKE in Service, authentication Key establishment Output exchange RAM Power Cycle for IPsec traffic process (SP800- (Plaintext) or 56a rev3 and IPsec session SP800-135 KDF) termination TLS Master 384-bits TLS Generated Internally Neither Established as a Temporarily Zeroize Used for the Secret A6598 during TLS handshake Input nor part of TLS in Service, generation of process Output handshake RAM Power Cycle TLS Session process (Plaintext) or the TLS Keys and TLS session Integrity Key termination TLS Extended 384-bits TLS 1.2 Generated Internally Neither Established as a Temporarily Zeroize Binds the Master Secret A6598 during TLS handshake Input nor part of TLS in Service, master secret process Output handshake RAM Power Cycle to the full process (Plaintext) or the TLS handshake session context termination TLS Premaster 384-bits TLS Generated Internally Neither Established as a Temporarily Zeroize Used for the Secret A6598 during TLS handshake Input nor part of TLS in Service, generation of process Output handshake RAM Power Cycle Master Secret process (Plaintext) or the TLS SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number session termination TLS Session TLS 1.2: TLS 1.2: Generated Internally Neither Established as a Temporarily Zeroize Used to Key 128 or 256- AES CBC during SSP Input nor part of TLS in Service, protect TLS 1.2 bit and establishment Output exchange RAM Power Cycle connection

128 or 256- AES GCM process (SP800- (Plaintext) or the TLS

bit 56a rev3 and session Used to TLS 1.3: SP800-135 termination protect TLS 1.3 TLS 1.3: AES-GCM KDF/TLS 1.3 KDF) connection

bit A6598 TLS Integrity TLS 1.2: TLS 1.2/ TLS Generated Internally Neither Established as a Temporarily Zeroize Used to check Key 160/256/384 1.3 during SSP Input nor part of TLS in Service, the integrity of -bit HMAC establishment Output exchange RAM Power Cycle TLS 1.2 A6598 process (SP800- (Plaintext) or the TLS connection TLS 1.3: 56a rev3 and session 256/384-bit SP800-135 termination Used to check KDF/TLS 1.3 KDF) the integrity of TLS 1.3 connection TLS Private Key 2048-bit RSA Generated as per Neither Input Not Applicable Flash Zeroize Used in the TLS or or SP800-90A DRBG and nor Output (Plaintext) Service 1.2/TLS 1.3 P-256, P-384 ECDSA FIPS 186-5 compliant signature or P-521 CKG RSA or ECDSA key algorithm A6598 generation Diffie- IKE: Diffie- KAS-SSC Generated as per Neither Not Applicable Temporarily Zeroize Used within Hellman/EC Hellman CKG SP800-90A DRBG and Input nor in Service, IKE key Private Key A6598 FIPS 186-4 compliant Output RAM Power agreement SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number Diffie-Hellman (N = 224, DSA or 186-5 (Plaintext) Cycle or the Private Key 256) or EC compliant ECDSA key TLS/IKE DH P-256/P- generation session Used within 384/P-521 termination TLS key agreement TLS: EC DH P256/P384/P-521 DRBG Internal 256-bits Hash_DRBG Generated Internally Neither Not Applicable Temporarily Zeroize The values of V State A6598 Input nor in Service or and C are the Output RAM Power “secret values” (Plaintext) Cycle of the internal state DRBG Seed 256-bits Hash_DRBG Intel® Digital Random Neither Not Applicable Temporarily Zeroize Used to seed A6598 Number Generator Input nor in Service or the Approved SP800-90B Output RAM Power DRBG (Plaintext) Cycle Entropy Input 256-bits Hash_DRBG Intel® Digital Random Neither Not Applicable Temporarily Zeroize Entropy (min) security A6598 Number Generator Input nor in Service or input used to strength SP800-90B Output RAM Power instantiate the (Plaintext) Cycle DRBG RADIUS SharedA minimum Shared Not Applicable Input Not Applicable Flash Zeroize Used for Secret of 8 Secret electronically (Encrypted Service authenticating characters A6598 and output by AES CBC the RADIUS for RADIUS via IPsec 256-bit) server to the authenticati module and on vice versa via IPSec SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number Passwords A minimum Not Not Applicable Entered Not Applicable Flash Zeroize Authentication (hashed) of 8 ASCII Applicable electronically (Encrypted Service data characters. by AES CBC 256-bit) Storage Key 256-bit Key AES CBC Generated as per Neither Input Not Applicable Flash Zeroize For encrypting CKG SP800-90A DRBG nor Output (Plaintext) Service RADIUS Shared A6598 Secret, Passwords and Preshared Key Public Keys Root CA Public 2048-bit RSA Not Applicable Input Not Applicable Flash Zeroize Used for Key or or electronically (Plaintext) Service verifying a P-256, P- ECDSA via IPsec. Not chain of trust

384 or P- A6598 output for receiving

521 certificates

Peer IKE Public 2048-bit RSA Not Applicable Input During IKE RAM Zeroize Used for Key or or electronically negotiation (Plaintext) Service, verifying P-256, P- ECDSA Not output Power Cycle digital

384 or P- or IKE signatures

521 A6598 session from a peer

termination device IKE Public Key 2048-bit RSA Generated as per Not Input. During IKE Flash Zeroize Used for or or SP800-90A DRBG and Output negotiation (Plaintext) Service verifying P-256, P- ECDSA FIPS 186-5 compliant electronically digital

384 or P- A6598 RSA or ECDSA key during IKE signatures

521 generation negotiation from a peer

device SonicWall, Inc. © 2025 Version 0.1 Public Material

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

Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function Export keys and Cert. Number Diffie- IKE: Diffie- KAS-SSC Generated as per Not Input. During IKE Temporarily Zeroize Used within Hellman/EC Hellman A6598 SP800-90A DRBG and Electronic negotiation in Service, IKE key Diffie-Hellman Public Key (N FIPS 186-4 compliant output RAM Power agreement Public Key = 224, 256) DSA or 186-5 compliant during IKE (Plaintext) Cycle or the or EC DH P- ECDSA key generation negotiation TLS/IKE 256/P- session 384/P-521 termination Used within TLS: EC DH TLS key P-256/P- agreement 384/P-521 Authentication 2048-bit RSA Not Applicable Input Not Applicable Temporarily Zeroize Used to Public Key A6598 electronically in Service authenticate over CLI. No RAM the User output (Plaintext) TLS Public Key 2048-bit RSA Generated as per Electronically During TLS Flash Zeroize Used in the TLS or or SP800-90A DRBG and Output Handshake (Plaintext) Service handshake P-256, P- ECDSA FIPS 186-5 compliant during TLS

Table 14

• SSPs Note: The keys are explicitly zeroized by the module when the zeroize service is executed and are implicitly zeroized when power cycling or the termination of the IPsec, IKE, and/or TLS sessions. SonicWall, Inc. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Entropy sources Minimum number of bits of Details entropy Intel® Digital Random Number 0.6 The module supports the Intel® Generator SP800-90B Digital Random Number Generator SP800-90B as the ESV Certificate: E164 module’s noise source, outputting full entropy. (The entropy source supports a vetted conditioning component consistent with NIST SP 80090B, Section 3.1.5.1.1.) The noise source is the root of security for the entropy source and for the DRBG as a whole The noise source (internal to the Intel CPUs) is a circuit that employs a feedback-stabilized metastable latch to generate entropic binary data by measuring the resolution state of the latch after exiting metastability. The feedback is used to keep the metastable latch balanced so that thermal noise will drive the resolution process Table 15

• Non-Deterministic Random Number Generator Specification Public Material
• May be reproduced only in its original entirety (without revision).

10. Self-Tests The module performs self-tests to ensure the proper operation of the module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. The pre-operational self-tests are performed and shall pass successfully prior to the module providing any data output via the data output interface. CASTs are performed on the condition that the pre-operational self-test complete successfully. Other conditional self-tests are performed when an applicable security function or process is invoked. If the module fails a self-test, the module enters the error state and outputs the error message. The module does not perform any cryptographic operations, and data output is inhibited while in the error state. Self–tests (CASTs) are available on demand by power cycling the module. Pre-Operational Self-Tests

• Firmware Integrity Test: SHA2-256 (256-bit EDC) Conditional Self-Tests Cryptographic Algorithm Self Tests
• AES-CBC Decrypt CAST
• AES GCM Encrypt CAST
• AES GCM Decrypt CAST
• CVL: IKEv1 KDF CAST
• CVL: IKEv2 KDF CAST
• CVL: TLS 1.2 KDF CAST
• CVL: TLS 1.3 KDF CAST
• DRBG: SP 800-90A Section 11.3 Health Tests (Instantiate, Generate, Reseed)
• DSA CAST (Pairwise Consistency Test)
• ECDSA Signature Generation CAST
• ECDSA Signature Verification CAST
• HMAC-SHA-1 CAST
• HMAC-SHA2-256 CAST
• HMAC-SHA2-384 CAST
• HMAC-SHA2-512 CAST
• KAS-FFC-SSC Primitive “Z” CAST (SP 800-56Arev3)
• KAS-ECC-SSC Primitive “Z” CAST (SP 800-56Arev3)
• RSA Signature Generation CAST (Key size: 2048)
• RSA Signature Verification CAST (Key size: 2048)
• SHA-1 CAST
• SHA2-256 CAST
• SHA2-384 CAST
• SHA2-512 CAST
• NIST SP 800-90B Start-Up Health Tests
• NIST SP 800-90B Continuous Health Tests Public Material
• May be reproduced only in its original entirety (without revision).

Conditional Pairwise Consistency Tests • ECDSA Pairwise Consistency Test • DSA Pairwise Consistency Test • RSA Pairwise Consistency Test If any of the tests described above fail, the cryptographic module enters the error state. No security services are provided in the error state. No cryptographic output is started until all tests are successfully completed. This effectively inhibits the data output interface. When all tests are completed successfully, the Test LED is turned off.

11. Life-Cycle Assurance Crypto Officer Guidance The following steps shall be performed by the Crypto Officer (CO) to configure the required roles and place the module in the Approved mode of operation:
12. Apply power to the module. On a GPC, connect to the module’s console using the serial port. The network interface drivers/login prompt will only be available once all power-up self-tests have completed successfully.
13. Login using the vendor provided default login and password. The default password and login shall be changed/updated.
14. Configure management IP address and Gateway.
15. Over the web interface, proceed to system settings and update the settings to be consistent with Section 2 of this document with the assistance of compliance checking procedure and then enabling Approved mode using the checkbox. The FIPS checkbox does not place the module in Approved mode until the settings in the Modes of Operation Section are met. Then click OK. The system automatically restarts.
16. Observe that the module self-tests execute automatically before a log in is possible. Observe that the “FIPS enabled checkbox” is checked/enabled to indicate that the module is in the Approved mode of operation. This can be verified in the system/settings page. In addition, on the dashboard, the operator can verify the version of the module.
17. Proceed to create the roles specified in Section 4 of this document. Passwords and Digital signatures required for authentication to each role should be configured or installed as appropriate. *Note 1: When the "Approved mode" checkbox is selected, the module executes a compliance checking procedure, examining all settings related to the security rules described previously in this document. The operator is responsible for updating these settings appropriately during setup and will be prompted by the compliance tool if a setting has been modified, taking the module out of compliance. The "Approved mode" checkbox and corresponding system flag ("fips") which can be queried over the console will not be Public Material – May be reproduced only in its original entirety (without revision).

set unless all settings are compliant. The "Approved mode" checkbox and “fips” system flag are indicators that the module is running in the Approved mode of operation. *Note 2: The keys and SSPs generated in the cryptographic module during Approved mode of operation shall not be used when the module transitions to non-Approved mode and vice versa. While the module transitions from Approved to non-Approved mode or from non-Approved to Approved mode, all SSPs shall be zeroized by the Crypto Officer using the “Zeroize” service. If transitioning from the non-Approved to Approved mode, the CO shall zeroize all plaintext keys and SSPs by issuing “Zeroize” service and then the CO shall follow the CO Guidance (above) in this section to place the module in Approved mode of operation. Configuration Management SonicWall uses Perforce software for the management of source code artifacts and for hardware and documentation version control. KlocWork is used for static code analysis. The module is developed using high level programming languages C++ and C. Assembly code is only used for select performance enhancements. The module is securely delivered from Sonicwall to customers via the mechanism specified by the customer. FedEx, UPS, or any other freight forwarder of their choice can be utilized. Tracking numbers are used to track and confirm delivery to the authorized operator. The Crypto Officer should check the package for any irregular tears or openings. If the Crypto Officer suspects tampering has occurred, they should immediately contact Sonicwall, Inc. The end of life for the module meets the FIPS 140-3 requirements. The sanitization requirements are met by zeroising the module. Public Material

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

12. Mitigation of Other Attacks The SonicWall NSa 4700, NSa 5700, NSa 6700, NSsp 10700, NSsp 11700, and NSsp 13700 are capable of mitigating other attacks using the following features (dependent on licensing). Capture ATP The Capture ATP Service revolutionizes advanced threat detection and sandboxing with a cloud-based, multi-engine solution for stopping unknown and zero-day attacks at the gateway. Capture ATP blocks zero-day attacks before they enter your network. It lets you establish advanced protection against the changing threat landscape and analyze a broad range of file types. Gateway Anti-Virus ICSA-certified Gateway Anti-Virus protection combines network-based anti-malware with a dynamically updated cloud database of tens of millions of malware signatures. Dynamic spyware protection blocks the installation of malicious spyware and disrupts existing spyware communications. IPS Cutting-edge IPS technology protects against worms, trojans, software vulnerabilities and other intrusions by scanning all network traffic for malicious or anomalous patterns, thereby increasing network reliability and performance. Comprehensive Anti-Spam Service SonicWall Comprehensive Anti-Spam Service offers small-to medium sized businesses >99% effectiveness against spam, dropping >80% of spam at the gateway, while utilizing advanced anti-spam techniques like Adversarial Bayesian™ and machine-learning filtering. DNS Filtering DNS filtering blocks malicious websites or applications at the DNS layer to filter out harmful or inappropriate content without enabling TLS decryption and adversely affecting performance. Network Access Control Network access control integration provides network access control for SonicWall customers by integrating with Aruba ClearPass, giving you comprehensive and precise profiling, authentication, and authorization for systems and devices trying to access your IT resources. SonicOS provides a RESTful API that will support Aruba ClearPass as NAC to integrate with SonicWall NGFW. This architecture will turn static security into contextual security to provide more flexible and advanced security protection. Content Filtering Service Content Filtering Services (CFS) lets you enforce Internet use policies and control internal access to inappropriate, unproductive and potentially illegal web content with comprehensive content filtering. Reputation-based CFS 5.0 provides a reputation score that forecasts the security risk of a URL across 93 web categories. Public Material

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

Other The modules also include basic DNS security, deep packet inspection for SSL, and a botnet service. Public Material

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

References and Definitions The following standards are referred to in this Security Policy. Abbreviation Full Specification Name [FIPS140-3] Security Requirements for Cryptographic Modules, March 22, 2019 [IG] Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program [108] NIST Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions (Revised), October 2009 [131Arev2] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019 [132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, Part 1: Storage Applications, December 2010 [133rev2] NIST Special Publication 800-133rev2, Recommendation for Cryptographic Key Generation, June 2020 [135rev1] National Institute of Standards and Technology, Recommendation for Existing Application-Specific Key Derivation Functions, Special Publication 800-135rev1, December 2011. [186-4] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-4, July, 2013. [186-5] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-5, February 2023 [186-2] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2, January 2000. [197] National Institute of Standards and Technology, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 26, 2001 [198] National Institute of Standards and Technology, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Processing Standards Publication 198-1, July, 2008 [180-4] National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards Publication 180-4, August, 2015 [202] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, FIPS PUB 202, August 2015 [38A] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation, Methods and Techniques, Special Publication 800-38A, December 2001 Public Material

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

Abbreviation Full Specification Name [38B] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Special Publication 800-38B, May 2005 (Updated 10/6/2016) [38C] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, Special Publication 800-38C, May 2004 (Updated 7/20/2007) [38D] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, Special Publication 80038D, November 2007 [56Arev3] NIST Special Publication 800-56A (rev3), Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 [56Br2] NIST Special Publication 800-56B Revision 1, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography, March 2019 [67rev2] National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Special Publication 800-67, November 2017 [90Arev1] National Institute of Standards and Technology, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Special Publication 800-90A, June 2015. [90B] Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018 Table 16

• References Acronym Definition AES Advanced Encryption Standard CBC Cipher Block Chaining DH Diffie-Hellman DRBG Deterministic Random Bit Generator FIPS Federal Information Processing Standard GUI Graphical User Interface HMAC Hashed Message Authentication Code IKE Internet Key Exchange IPSec Internet Protocol Security RADIUS Remote Authentication Dial-In User Service RSA Rivest, Shamir, Adleman asymmetric algorithm SHA Secure Hash Algorithm Public Material
• May be reproduced only in its original entirety (without revision).

Acronym Definition SSP Sensitive Security Parameter TACACS+ Terminal Access Controller Access-Control System Plus Triple-DES Triple Data Encryption Standard VPN Virtual Private Network Table 17

• Acronyms and Definitions Public Material
• May be reproduced only in its original entirety (without revision).