sonicwall sma v11.4 sma 7200 fips policy - nist · sonicwall, inc. sonicwall sma series v11.4 fips...
TRANSCRIPT
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 1 of 20
SonicWALL SMA Series v11.4
EX6000, EX7000, EX9000, SMA 6200, SMA 7200
FIPS 140‐2 Non‐Proprietary Security Policy
Document Version: 1.4
Date: May 4, 2017
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 2 of 20
Contents 1 Introduction ............................................................................................................................................ 4
1.1 Hardware ..................................................................................................................................... 5 1.2 Modes of Operation ..................................................................................................................... 6
2 Cryptographic Functionality ................................................................................................................... 6 2.1 Critical Security Parameters ....................................................................................................... 10 2.2 Public Keys ................................................................................................................................. 10
3 Roles, Authentication and Services ...................................................................................................... 11 3.1 Assumption of Roles .................................................................................................................. 11 3.2 Authentication Methods ............................................................................................................ 11 3.3 Services ...................................................................................................................................... 12
4 Self‐tests ............................................................................................................................................... 14 5 Physical Security Policy ......................................................................................................................... 15
5.1 SRA EX6000 and SRA EX7000 Tamper Seal Placement .............................................................. 16 5.2 SRA EX9000 Tamper Seal Placement ......................................................................................... 16 5.3 SMA 6200 and SMA 7200 Tamper Seal Placement .................................................................... 17
6 Operational Environment ..................................................................................................................... 18 7 Mitigation of Other Attacks Policy ....................................................................................................... 18 8 Security Rules and Guidance ................................................................................................................ 18 References and Definitions ......................................................................................................................... 19
Tables Table 1 – Cryptographic Module Configurations .......................................................................................... 4
Table 2 – Security Level of Security Requirements ....................................................................................... 4
Table 3 – Ports and Interfaces ..................................................................................................................... 5
Table 4 – Management Console and VPN session TLS Ciphersuites used in the Approved mode ............... 6
Table 5 – TLS Ciphersuites used in the non‐Approved mode ....................................................................... 6
Table 6 – SSH Security Methods Available (Approved and non‐Approved modes) ..................................... 7
Table 7 – IPsec ESP Cipher and Digest Methods Available ........................................................................... 7
Table 8 – Approved algorithms (Implementations: [ A]=avcrypto; [L]= libcrypto; [O] = ojdk) ................... 8
Table 9 ‐ Allowed Algorithms ........................................................................................................................ 9
Table 10 ‐ Non‐Approved Algorithms (Used only in the non‐Approved Mode) ........................................... 9
Table 11 – Critical Security Parameters (CSPs) ........................................................................................... 10
Table 12 – Public Keys ................................................................................................................................. 10
Table 13 – Roles Description ....................................................................................................................... 11
Table 14 – Authenticated Services .............................................................................................................. 12
Table 15 – Unauthenticated Services ......................................................................................................... 13
Table 16 – CSP Access Rights within Services ............................................................................................. 13
Table 17 – Power Up Self‐tests ................................................................................................................... 14
Table 18 – Conditional Self‐tests ................................................................................................................ 15
Table 19 – Physical Security Inspection Guidelines .................................................................................... 15
Table 20 – References ................................................................................................................................. 19
Table 21 – Acronyms and Definitions (for terms not defined in FIPS 140‐2 and associated documents) . 20
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 3 of 20
Figures Figure 1 – Physical form of all Module configurations ................................................................................. 5
Figure 2 ‐ Tamper Seal #1 – Left Side .......................................................................................................... 16
Figure 3 ‐ Tamper Seal #2 ‐ Bottom Cover .................................................................................................. 16
Figure 4 – Tamper Seal #3 – Expansion Bay ................................................................................................ 16
Figure 5 – SRA EX9000 Tamper Seal #1 ‐ Right Side ................................................................................... 16
Figure 6 –SRA EX9000 Underside Tamper Seals #2, #3 and #4 .................................................................. 16
Figure 7 – SRA EX9000 Tamper Seal #5 ‐ Rear Fans .................................................................................... 16
Figure 8 –SRA CBCCSPs and EX9000 Tamper Seals #6 and #7 ‐ Front Drive Bays ...................................... 16
Figure 9 ‐ SMA 6200 / SMA 7200 Tamper Seal #1 ‐ Chassis Seam .............................................................. 17
Figure 10 ‐ SMA 6200 / SMA 7200 Tamper Seal #2 (over drive bay protected plate) ................................ 17
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 4 of 20
1 Introduction The SonicWALL SMA Series v11.4, also referred to as “the Module”, are multi‐chip standalone cryptographic modules enclosed in hard, commercial grade metal cases. The cryptographic boundary for these modules is the enclosure. The primary purpose of these modules is to provide secure remote access to internal resources via the Internet Protocol (IP). The modules provide network interfaces for data input and output. The appliance encryption technology uses FIPS approved algorithms. FIPS approved algorithms are approved by the U.S. government for protecting Unclassified data.
The Module is designated as a limited operational environment under the FIPS 140‐2 definitions. The Module includes a firmware load service to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140‐2 CMVP. Any other firmware loaded into this module is out of the scope of this validation and require a separate FIPS 140‐2 validation.
Module HW P/N and Version FW Version
1 SRA EX6000 101‐500210‐78 Rev A 11.4.0‐512
2 SRA EX7000 101‐500188‐79 Rev A 11.4.0‐512
3 SRA EX9000 101‐500352‐62 Rev A 11.4.0‐512
4 SMA 6200 101‐500399‐61 Rev B 11.4.0‐512
5 SMA 7200 101‐500398‐61 Rev B 11.4.0‐512
Table 1 – Cryptographic Module Configurations The FIPS 140‐2 security levels for the module are as follows:
Security Requirement Security Level
Cryptographic Module Specification 2
Cryptographic Module Ports and Interfaces 2
Roles, Services, and Authentication 2
Finite State Model 2
Physical Security 2
Operational Environment N/A
Cryptographic Key Management 2
EMI/EMC 2
Self‐Tests 2
Design Assurance 3
Mitigation of Other Attacks N/A
Table 2 – Security Level of Security Requirements
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 5 of 20
1.1 Hardware The physical forms of each configuration of the module are depicted in Figure 1.
SRA EX6000 (Front)
SRA EX6000 (Rear)
SRA EX7000 (Front)
SRA EX7000 (Rear)
SRA EX 9000 (Front)
SRA EX 9000 (Rear)
SMA 6200 (Front)
SMA 6200 (Rear)
SMA 7200 (Front)
SMA 7200 (Rear)
Figure 1 – Physical form of all Module configurations
Port Description Logical Interface Type
Console Serial (all configurations) and DisplayPort (SMA 6200/7200 only) command line interface
Control in, Status out
DIAG Ethernet port for manufacturing: EX9000, SMA 6200 and SMA 7200 only.
N/A: Used only during manufacturing process; disabled prior to product delivery.
eSATA Disk interface. N/A: Not used in approved mode. The hardware platform design is common with other configurations that use this port.
Ethernet
Network traffic connections.EX6000: 4 ports SMA 6200: 6 portsEX7000: 6 ports SMA 7200: 8 portsEX9000: 12 ports
Control in, Data in, Data out, Status out
Display buttons Four (4) buttons used to navigate LCD displays. Control in
Display LCD display for basic status information. Status out
LEDs Unit level: Disk Activity, Test, Alarm and Power (1 or 2 LEDs). Ethernet: Link and Activity LEDs.
Status out
Power AC power, inclusive of switch. EX9000, EX7000 and SMA 7200 have dual (redundant) power supplies.
Power
USB Two (2) USB ports, used for disaster recovery only. N/A: Not for use in approved mode
Table 3 – Ports and Interfaces
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 6 of 20
1.2 Modes of Operation The module’s Management Console provides the mechanism to configure the module for the Approved mode of operation, found in General Settings > Configure FIPS Security. Attempts to check the Enable FIPS mode checkbox execute a FIPS Approved mode compliance checking tool, which enforces the use of only the FIPS Approved mode ciphers listed in Table 4 below, and provides clearly visible warnings if any of the the following configuration conditions are not met:
The following authentication servers may be used, if connected using only FIPS approved ciphers:
o LDAP
o Active Directory single domain
o RSA Authentication Manager
Use of RADIUS authentication servers is not permitted in the Approved mode.
Clustering (High Availability) is not supported in FIPS mode.
Configured connections with SonicWALL GMS or Viewpoint servers are not permitted in the Approved mode.
In the non‐Approved mode, the additional ciphersuites shown in Table 5 are available for use by the AMC Interface and VPN Network Traffic services, and the features cited in the bullets above are available for use. See Section 8, Security Rules and Guidance for additional Approved mode operation guidance.
2 Cryptographic Functionality The cryptographic protocols and primitves implemented and used by the modules are listed in this section. Table 4 and 5 list the TLS ciphersuites available in the Approved and non‐Approved modes, respectively. Table 6 lists the SSH security methods; unlike TLS ciphersuites, SSH methods are independently selectable and may be used in any combination.
Cipher Suite String (IETF enumeration) TLS Key Exchange Cipher Auth
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 1.2 ECDH_P384 AES‐128 GCM
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 1.2 ECDH_P384 AES‐256 GCM
TLS_RSA_WITH_3DES_EDE_CBC_SHA 1.2, 1.1, 1.0 RSA Triple‐DES SHA‐1
TLS_RSA_WITH_AES_128_CBC_SHA 1.2, 1.1, 1.0 RSA AES‐128 SHA‐1
TLS_RSA_WITH_AES_128_CBC_SHA256 1.2 RSA AES‐128 SHA‐256
TLS_RSA_WITH_AES_256_CBC_SHA 1.2, 1.1, 1.0 RSA AES‐256 SHA‐1
TLS_RSA_WITH_AES_256_CBC_SHA256 1.2 RSA AES‐256 SHA‐256
Table 4 – Management Console and VPN session TLS Ciphersuites used in the Approved mode
Cipher Suite String (IETF enumeration) TLS Key Exchange Cipher Auth
SSL_RSA_WITH_RC4_128_SHA 1.2, 1.1, 1.0 RSA RC4 SHA‐1
TLS_RSA_WITH_AES_128_CBC_SHA 1.2, 1.1, 1.0 RSA AES‐128 SHA‐1
TLS_RSA_WITH_AES_256_CBC_SHA 1.2, 1.1, 1.0 RSA AES‐256 SHA‐1
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA2561 1.2 ECDHE_P384 AES‐128 GCM
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA3841 1.2 ECDHE_P384 AES‐256 GCM
Table 5 – TLS Ciphersuites used in the non‐Approved mode
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 7 of 20
Key Exchange
ecdh‐sha2‐nistp256
ecdh‐sha2‐nistp384
Server Host Key (Authentication)
ecdsa‐sha2‐nistp384
ssh‐rsa
Digest
hmac‐sha2‐256
hmac‐sha1
Encryption
aes256‐gcm
aes256‐cbc
aes128‐cbc
Table 6 – SSH Security Methods Available (Approved and non‐Approved modes)
The module uses IPsec ESP mode only over UDP for data transport, using AES‐128 and AES‐256 in CBC or
GCM mode. IKE is not used; rather, the keys and IVs are generated by the module and provided to the
peer over an out‐of‐band TLS tunnel.
Cipher Suite String (IETF enumeration) Cipher Auth
AES128‐CBC‐SHA AES‐128 SHA‐1
AES128‐CBC‐SHA256 AES‐128 SHA256
AES128‐GCM AES‐128 GCM
AES256‐CBC‐SHA AES‐256 SHA‐1
AES256‐CBC‐SHA256 AES‐256 SHA256
AES256‐GCM AES‐256 GCM
Table 7 – IPsec ESP Cipher and Digest Methods Available
1 Uses the secp160k1 Koblitz curve defined by secg.org, with strength below the minimum required by FIPS 140‐2
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 8 of 20
CAVP Algorithm Mode/Method Strength2 Useage
4044 AES [197],[38A], [38D] CBC, ECB, GCM 128, 256 Data Encryption/ Decryption [A].
4045 AES [197],[38A], [38D] CBC, ECB, GCM 128, 256 Data Encryption/ Decryption [O].
4046 AES [197],[38A], [38D] CBC, ECB, GCM 128, 256 Data Encryption/ Decryption [L].
869 CVL‐SNMP3 KDF [135] SHA‐1 SNMP AES key KDF.
870 CVL‐TLS3 KDF [135] TLS 1.0/1.1/1.2 (SHA‐256) TLS session keys KDF [L]
871 CVL‐SSH3 KDF [135] SHA‐1, SHA‐256 SSH v2 session key KDF
872 CVL‐TLS3 KDF [135] TLS 1.0/1.1/1.2 (SHA‐256) TLS session keys KDF. [O]
1211 DRBG4 [90A] CTR_DRBG {128}, 256 Random Bit Generation [A].
906 ECDSA [186] P‐256 (SHA‐256) P‐384 (SHA‐384)
ECC Key Generation; Digital Signature Generation, Verification [O].
907 ECDSA [186] P‐256 (SHA‐256) P‐384 (SHA‐384)
ECC Key Generation; Public Key Validation; Digital Signature Generation, Verification [L].
2639 HMAC [198] HMAC‐SHA‐1 HMAC‐SHA‐256
128 256
Message Authentication [A].
2640 HMAC [198] HMAC‐SHA‐1 HMAC‐SHA‐256
128 256
Message Authentication. [O]
2641 HMAC [198] HMAC‐SHA‐1 HMAC‐SHA‐256
128 256
Message Authentication. [L]
2076 RSA [186] n=1024 n=2048 (SHA‐256, SHA‐384) n=3072 (SHA‐256, SHA‐384)
RSA Key generation; Digital Signature Generation and Verification [O]. 1024 bit keys are used for firmware signature verification only, in a fallback scenario.
2077 RSA [186] {n=1024} n=2048 (SHA‐256, SHA‐384) n=3072 (SHA‐256, SHA‐384)
RSA Key generation; Digital Signature Generation and Verification. [L]
3333 SHS [180] SHA‐1, SHA‐256, SHA‐384 Message Digest generation. [A]
3334 SHS [180] SHA‐1, SHA‐256, SHA‐384 Message Digest generation. [O]
3335 SHS [180] SHA‐1, SHA‐256, SHA‐384 Message Digest generation. [L]
2211 Triple‐DES [67] TCBC 3‐Key (112) Data Encryption/ Decryption [A]
2212 Triple‐DES [67] TCBC 3‐Key (112) Data Encryption/ Decryption [O]
2213 Triple‐DES [67] TCBC 3‐Key (112) Data Encryption/ Decryption [L]
Table 8 – Approved algorithms (Implementations: [ A]=avcrypto; [L]= libcrypto; [O] = ojdk) References to standards are given in square bracket [ ]; see the References table. Items enclosed in curly brackets { } are CAVP tested but not used by the module in the Approved mode. The module uses only the RSA functions shown above in the Approved mode under 186‐4.
2 Strength indicates DRBG Strength, Key Lengths, Curves or Moduli 3 The TLS, SSH, and SNMP protocols have not been reviewed or tested by the CAVP and CMVP 4 No prediction resistance; block_cipher_df used for instantiation.
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 9 of 20
Algorithm (Establishment) Strength Use
Elliptic Curve Diffie‐Hellman
Provides 128 or 192 bits of encryption strength. Key establishment
HMAC‐SHA‐1‐96 The underlying HMAC‐SHA‐1 uses a 160 bit key; per SP 800‐157, this corresponds to 128 bits of strength.
SNMP message authenticity.
MD5 TLS 1.0/1.1, password obfuscation.
NDRNG Internal entropy source with rationale to support the claimed DRBG security strength.
Entropy input to Cert. #1211 DRBG.
RSA Signature verification using legacy (n=1024) key. Legacy firmware signature verification, fallback use only.
RSA Key Wrapping Provides 112 or 128 bits of encryption strength. Key establishment
Table 9 ‐ Allowed Algorithms
Algorithm Use
RC4 Element of TLS ciphersuite allowed only in non‐approved mode.
Elliptic Curve Diffie‐Hellman And ECDSA using P‐160
Element of TLS ciphersuite allowed only in non‐approved mode.
Table 10 ‐ Non‐Approved Algorithms (Used only in the non‐Approved Mode)
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 10 of 20
2.1 Critical Security Parameters All CSPs used by the module are described in this section.
Table 11 – Critical Security Parameters (CSPs)
2.2 Public Keys
Table 12 – Public Keys
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 11 of 20
3 Roles, Authentication and Services
3.1 Assumption of Roles The module supports the operator roles and associated authentication methods listed in Table 13.
The Module does not support a maintenance role or bypass capability. The Module supports concurrent users, enforcing separation of roles by the partitioning of major subsystems (such as VPN traffic vs. shell or AMC administrative functions), and by partitioning of the administrative interfaces (e.g.,. by organization of the AMC web GUI pages). Authentication status does not persist across module power cycles. The module does not permit multiple concurrent operators in the same role: to change roles, an operator must first log out, then log in using another role. Table 13 lists the available roles.
Role Authentication
ID Description Type Data
CO Cryptographic Officer – Has full access to administer and configure the module as well as delegate admin access control rights to Admin users.
Identity‐based (using Local password verification)
or
role‐based (using Transitive trust with authentication) dependent on configured policy.
Username
and PIN
or
X.509 certificate
User Admin User – Configure and administer the module per the delegated access rights assigned by the CO.
VPN Typical end user accessing the virtual private network resources via an encrypted connection.
SNMP SNMP agent and trap – provides module status via SNMP messages
Identity‐based (using SNMP authentication)
SNMP‐SMAC
Table 13 – Roles Description
3.2 Authentication Methods
The Local password verification method requires an 8 character minimum password using characters in the printable character set. The maximum rate for local password authentication is conservatively estimated to be approximately one (1) attempt per microsecond.
Hence the probability of false authentication is: 1/(8^96) = 2.0E‐87 And the probability of false authentication in a one minute period is (60*10^6)/(8^96) = 1.2E‐79
The Transitive trust with authentication method first establishes a secure connection to an external authentication server, which authenticates to the module using X.509 certificates. Subsequent interaction with the authentication server determines the applicable access rights; as such, this method is a role‐based authentication method.
Based on the minimum strength SAML key (RSA 2048) security strength of 112 bits, the probability of false authentication is: 1/(2^112) = 1.9E‐34 And the probability of false authentication in a one minute period is: (60*10^6)/(2^112) = 1.2E‐26
SNMP authentication method: communications established with an SNMP client include verification of a initial message, confirming a 96‐bit truncated HMAC‐SHA‐1 value calculated using the SNMP‐SMAC key and a designated message , with maximum processing rate measured on the fastest configuration as requiring at minimum one microsecond:
Hence the probability of false authentication is: 1/(2^96) = 1.3E‐29 And the probability of false authentication in a one minute period is (60*10^6)/(2^96) = 7.6E‐22
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 12 of 20
3.3 Services All services implemented by the module are listed in the tables below.
Table 14 – Authenticated Services
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 13 of 20
Table 15 – Unauthenticated Services Table 16 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as:
G = Generate: The module generates the CSP.
R = Read: The module reads the CSP. The read access is typically performed before the module uses the CSP.
E = Execute: The module executes using the CSP.
W = Write: The module writes the CSP. The write access is typically performed after a CSP is imported into the module, when the module generates a CSP, or when the module overwrites an existing CSP.
Z = Zeroize: The module zeroizes the CSP.
Table 16 – CSP Access Rights within Services
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 14 of 20
4 Self‐tests
Each time the module is powered up it tests that the cryptographic algorithms still operate correctly and that sensitive data have not been damaged. Power up self–tests are available on demand by power cycling the module.
On power up or reset, the module performs the self ‐tests described in below. All KATs must be completed successfully prior to any other use of cryptography by the module. The Test LED is lit only during power‐self‐test. If any power‐up self‐test fails, the module remains in the FIPS Error state, indicated by the Test and Alarm LEDs remaining lit, until it is reset. Self‐test status is also shown on the console and captured into system logs.
Test Target (Cert. #) Description
Firmware Integrity HMAC‐SHA‐256 performed over all code in EEPROM.
AES (#4046) Separate KATs for each permutation of: encrypt, decrypt functions; 128, 256 bit keys; CBC, GCM modes. ECB encrypt/decrypt tested with 256 bit key only.
AES (#4044) Separate KATs for each permutation of: encrypt, decrypt functions; 128, 256 bit keys; CBC, ECB and GCM modes.
AES (#4045) Separate KATs for each permutation of: encrypt, decrypt functions; 128, 256 bit keys; CBC, ECB and GCM modes.
DRBG (#1211)
AES‐256 CTR DRBG test. Performed conditionally (where initial use at power‐up is the condition) per SP 800‐90 Section 11.3.
ECDSA (#907) Separate signature generation and signature verification KAT’s as well as a PCT are performed using a P‐256 key.
ECDSA (#906) Separate signature generation and signature verification KAT’s as well as a PCT are performed using a P‐256 key.
HMAC (#2641) Separate HMAC generation and HMAC verification KATs, using SHA‐1 and SHA‐256. 5
HMAC (#2640) Separate HMAC generation and HMAC verification KATs, using SHA‐1 and SHA‐256. 5
HMAC (#2639) Separate HMAC generation and HMAC verification KATs, using SHA‐1 and SHA‐256.5
RSA (#2077) Separate KATs of n=2048 bit signature generation and signature verification.
RSA (#2076) Separate KATs of n=2048 bit signature generation and signature verification.
SHS (#3335) Separate KATs of SHA‐1, SHA‐256, SHA‐3845
SHS (#3334) Separate KATs of SHA‐1, SHA‐256, SHA‐3845
SHS (#3333) Separate KATs of SHA‐1, SHA‐256, SHA‐3845
Triple‐DES (# 2213) Separate KATs of Encryption, Decryption using 3‐key TECB.
Triple‐DES (# 2212) Separate KATs of Encryption, Decryption using 3‐key TECB.
Triple‐DES (# 2211) Separate KATs of Encryption, Decryption using 3‐key TECB.
CSP Integrity (Critical function) A CSP integrity test is performed at power‐on and at each system configuration invocation and configuration update.
Table 17 – Power Up Self‐tests
5 IG 9.4 requires separate self‐tests of each of the SHA‐1, SHA‐256 and SHA‐384 methods. IG 9.4 requires an HMAC KAT for at least one of the implemented underlying SHS methods.
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 15 of 20
Test Target Description
CSP Integrity (Critical function) A CSP integrity test is performed at power‐on and at each system configuration invocation and configuration update.
DRBG AS09.42 Continuous RNG Test performed when a random value is requested from the DRBG.
ECDSA ECDSA Pairwise Consistency Test performed on every ECDSA key pair generation.
Firmware Load HMAC‐SHA‐256 verification performed when firmware is loaded. HMAC‐SHA‐1 is possible to use only for fallback scenarios.
NDRNG AS09.42 Continuous RNG Test performed when a random value is requested from the
NDRNG.
RSA RSA Pairwise Consistency Test performed on every RSA key pair generation.
Table 18 – Conditional Self‐tests
5 Physical Security Policy
The cryptographic modules each include the following physical security mechanisms:
Production‐grade components and production‐grade opaque enclosure
Tamper‐evident material and seals
Protected vents
Some module components (e.g., hard drives) are field replaceable. If a replacement component is installed in the field, new tamper seals are sent with the replacement component, along with specific instructions on how to properly prepare the module surface and apply the new seals. Tamper seals may not be ordered separately. The location and placement of tamper seals for each configuration are shown in the figures below. The tamper‐evident seals shall be installed for the module to operate in a FIPS mode of operation. EX6000 and EX7000 configurations require three (3) tamper seals placed as shown in Section 5.1. EX9000 requires seven (7) seals placed as shown in Section 5.2. SMA 6200 and SMA 7200 require two (2) seals as shown in Section 5.3.
An operator in the CO role is responsible for the following:
Directly controlling and monitoring module reconfigurations where the tamper‐ evident seals are removed and re‐installed, to ensure that the security of the module is maintained during component replacement and that the module is returned to a FIPS Approved state.
Securing and controlling any unused tamper seals.
Physical Security Mechanism
Recommended Frequency of Inspection/Test
Inspection/Test Guidance Details
Tamper‐evident Seals Inspect tamper‐evident seals monthly.
See the SonicWALL Aventail Secure Remote Access Installation and Administration Guide Version 11.4 for procedure.
Table 19 – Physical Security Inspection Guidelines
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 16 of 20
5.1 SRA EX6000 and SRA EX7000 Tamper Seal Placement
Figure 2 ‐ Tamper Seal #1 – Left Side
Figure 3 ‐ Tamper Seal #2 ‐ Bottom Cover
Figure 4 – Tamper Seal #3 – Expansion Bay
5.2 SRA EX9000 Tamper Seal Placement
Figure 5 – SRA EX9000 Tamper Seal #1 ‐ Right Side
Figure 6 –SRA EX9000 Underside Tamper Seals #2, #3 and #4
Figure 7 – SRA EX9000 Tamper Seal #5 ‐ Rear Fans
Figure 8 –SRA CBCCSPs and EX9000 Tamper Seals #6 and #7 ‐ Front Drive Bays
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 17 of 20
5.3 SMA 6200 and SMA 7200 Tamper Seal Placement
Figure 9 ‐ SMA 6200 / SMA 7200 Tamper Seal #1 ‐ Chassis Seam
Figure 10 ‐ SMA 6200 / SMA 7200 Tamper Seal #2 (over drive bay protected plate)
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 18 of 20
6 Operational Environment
The Module is designated as a limited operational environment under the FIPS 140‐2 definitions; see the statement in §1 Introduction ¶2.
7 Mitigation of Other Attacks Policy
The modules have not been designed to mitigate attacks outside the scope of FIPS 140‐2.
8 Security Rules and Guidance
The Module design corresponds to the module security rules. The module implements and enforces the following security rules:
1. An unauthenticated operator does not have access to any CSPs or cryptographic services. 2. The module inhibits data output during power up self‐tests and error states. 3. Status information does not contain CSPs or sensitive data that if misused could lead to a
compromise of the module. 4. Certificates are entered and output from the module in PKCS #12 format which obfuscates the
embedded keys but does not protect them. All import and export of key values shall be performed over VPN tunnels.
5. Zeroization overwrites all CSPs. Performance of the zeroization process will prevent the module from successfully booting, effectively disabling the module. The operator is required to be physically present while the module completes this process. The process may take up to one (1) hour to complete.
6. The module does not share CSPs between the Approved mode of operation and the non‐Approved mode of operation.
The following security rules must be adhered to for operation in the FIPS 140‐2 Approved mode: 1. Before enabling the FIPS Approved mode, a strong password, secure connection to the
authentication server, and valid license are required. 2. The module must be configured for FIPS Security as detailed in §1.2, with no warnings present. 3. Passwords must be at least 8 characters; 14 characters or more with a mix of numbers , letters and
symbols is recommended. 4. Do not use RSA Authentication Manager servers without strong passwords as shared secrets. 5. USB ports may be used for disaster recovery system restoration only. 6. Do not use eSATA devices for any purpose. 7. Do not Load or unload any kernel modules via the shell command line. 8. Do not Install third party software via the shell command line. 9. Do not attempt Firmware upgrades via the shell command line. 10. Do not use Debug 1, Debug 2, Debug 3 or plaintext logs. Plaintext logs do not contain CSPs, but may
contain information sensistive to users. 11. Do not use certificates with private/public key‐pairs generated by non‐FIPS validated systems. 12. Confirm physical security protections in accordance with Section 5, Physical Security Policy. 13. In case the module’s power is lost and then restored, a new key for use with the AES GCM
encryption/decryption is established.
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 19 of 20
References and Definitions
Ref Full Specification Name
[135] SP 800‐135, NIST, Recommendation for Existing Application‐Specific Key Derivation Functions, December 2011.
[180] FIPS 180‐4, NIST, Secure Hash Standard (SHS), August 2015.
[186] FIPS 186‐4, NIST, Digital Signature Standard (DSS), July 2013.
[197] FIPS 197, NIST, Advanced Encryption Standard (AES), November 26, 2001.
[198] FIPS 198‐1, The Keyed‐Hash Message Authentication Code (HMAC), July 2008.
[2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, “Remote Authentication Dial In User Service RFC 2865, (RADIUS), RFC 2865, Internet Engineering Task Force, June 2000.
[38A] SP 800‐38A, NIST, Recommendation for Block Cipher Modes of Operation ‐ Methods and Techniques, December 2001.
[38D] SP 800‐38D, NIST, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007.
[4254] RFC 4254, Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Connection Protocol”, Internet Engineering Task Force, January 2006.
[4303] RFC 4303, Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, Internet Engineering Task Force, December 2005.
[4511] RFC 4511, Semersheim, J., Ed., “Lightweight Directory Access Protocol (LDAP): The Protocol”, RFC 4511, Internet Engineering Task Force, June 2006.
[5246] RFC 5246, Dierks, T., and E. Rescoria, “The Transport Layer Security (TLS) Protocol Version 1.2”,. RFC 5246, Internet Engineering Task Force, August 2008.
[6239] RFCTBD, K. Igoe, “Suite B Cryptography in Suites for Secure Shell (SSH)”, Internet Engineering Task Force, May 2011.
[6379] RFC 6379, Law, L. and J. Solinas, “Suite B Cryptography Suites for IPsec”, RFC 6379, Internet Engineering Task Force, October 2011.
[6460] RFCTBD, Salter, M and R. Housely, “Suite B Profile for Transport Layer Security (TLS)”, Internet Engineering Task Force, January 2012.
[67] SP 800‐67, NIST, Recommendation for the Triple Data Encryption Algorithm (Triple‐DES) Block Cipher, January 2012.
[90A] SP 800‐90A, NIST, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015.
Table 20 – References
SonicWall, Inc. SonicWALL SMA Series v11.4
FIPS 140‐2 Security Policy
SonicWall, Inc. Page 20 of 20
Term Definition
AAA Authentication, Authorization and Accounting ‐ access control, policy enforcement and auditing framework for computing systems, e.g. LDAP
AMC Administration Management Console
ESP Encapsulated Security Payload (a subset of IPsec, Internet Protocol Security)
IKE Internet Key Agreement, a key agreement scheme associated with IPsec (but not used by the module)
GMS Global Management System
GUI Graphical User Interface
LDAP Lightweight Directory Access Protocol
PKCS #12 Public‐Key Cryptography Standards #12, regarding certificate formats.
RADIUS Remote Authentication Dial‐In Service
SAML Security Assertion Markup Language
SNMP Simple Network Management Protocol
SSH Secure Shell
VPN Virtual Private Network
TLS Transport Layer Security
Table 21 – Acronyms and Definitions (for terms not defined in FIPS 140‐2 and associated documents)