Copyright McAfee LLC 2018. May be reproduced only in its original entirety [without revision].
McAfee LLC
Network Security Platform Sensor
NS9300 P
Non-Proprietary Security Policy
Version 0.8
March 2018
Page 2
TABLE OF CONTENTS
1 MODULE OVERVIEW................................................................................................................................ 3
2 SECURITY LEVEL...................................................................................................................................... 5
3 MODE OF OPERATION ............................................................................................................................. 6
3.1 FIPS APPROVED MODE OF OPERATION........................................................................................................ 6
4 PORTS AND INTERFACES........................................................................................................................ 8
5 IDENTIFICATION AND AUTHENTICATION POLICY....................................................................... 11
6 ACCESS CONTROL POLICY .................................................................................................................. 13
6.1 ROLES AND SERVICES................................................................................................................................ 13
6.2 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ......................................................................... 14
6.3 DEFINITION OF PUBLIC KEYS..................................................................................................................... 15
6.4 DEFINITION OF CSPS MODES OF ACCESS ................................................................................................... 15
7 OPERATIONAL ENVIRONMENT .......................................................................................................... 17
8 SECURITY RULES.................................................................................................................................... 18
9 PHYSICAL SECURITY POLICY............................................................................................................. 20
9.1 PHYSICAL SECURITY MECHANISMS ........................................................................................................... 20
9.2 OPERATOR REQUIRED ACTIONS................................................................................................................. 20
10 MITIGATION OF OTHER ATTACKS POLICY .................................................................................... 23
Page 3
1 Module Overview
The Network Security Platform Sensor NS-9300 P (HW P/N IPS-NS9300 P Version 1.30 and FW
Version 9.1.17.2; FIPS Kit P/N IAC-FIPS-KT2) is a multi-chip standalone cryptographic module
as defined in FIPS 140-2.
The NS9300 is an Intrusion Prevention System (IPS) and Intrusion Detection System (IDS)
designed for network protection against zero-day, DoS/DDoS, encrypted and SYN Flood attacks,
and real-time prevention of threats like spyware, malware, VoIP vulnerabilities, phishing, botnets,
network worms, Trojans, and peer-to-peer applications.
The cryptographic boundary is the outer perimeter of the enclosure, including the removable power
supplies and fan trays. (The power supplies and fan trays are excluded from FIPS 140-2
requirements, as they are not security relevant.) Optional network I/O modules are not included
in the module boundary.
The McAfee NS-9300 product consists of the NS-9300 P cryptographic module physically
connected with the NS-9300 S cryptographic module. This security policy describes the NS-9300
P only.
Figure 1 shows the module configuration and the cryptographic boundary.
Figure 1 – Image of NS9300 P
Page 4
Figure 2 - Image of the Cryptographic Module connected to its peer NS-9300 S
Page 5
2 Security Level
The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS
140-2. Table 1 specifies the levels met for specific FIPS 140-2 areas.
Table 1 - Module Security Level Specification
Security Requirements Section Level
Cryptographic Module Specification 2
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
Page 6
3 Mode of Operation
3.1 FIPS Approved Mode of Operation
The module only supports a FIPS Approved mode of operation. An operator can obtain the FIPS
mode indicator by executing the “show” or “status” CLI command, which returns the module’s
firmware version, HW version, etc. The firmware and hardware versions must match the FIPS
validated versions located on the CMVP website.
The operator must also follow the rules outlined in Sections 8 and 9 of this Security Policy and
consult FIPS 140-2 IG 1.23 for further understanding of the use of functions where no security is
claimed.
Approved Algorithms
The module supports the following FIPS Approved algorithms:
• AES CBC and ECB mode with 128 & 256 bits for encryption and decryption (Cert. #4820)
• AES GCM mode with 128 bits for encryption and decryption use within TLS 1.2 (Cert.
#4820)
• AES GCM mode with 128 & 256 bits for encryption and decryption use within SSH v2
(Cert. #4820)
• KTS AES (Cert. #4820) encryption to transport keys and authentication using HMAC
(Cert. #3221) within TLS 1.2 and SSH
• FIPS 186-4 RSA with 2048 bit keys for key generation and RSA PSS with 2048 bit keys
for signature generation with SHA-256, and signature verification with SHA-256 (Cert.
#2639)
• SHA-1, SHA-256, and SHA-512 for hashing (Cert. #3962)
• HMAC SHA-1, SHA-256, and SHA-512 for message authentication (Cert. #3221)
(Note: The minimum HMAC key size is 20 bytes.)
• Block Cipher (CTR) DRBG using AES 256 (Cert. #1679)
• FIPS 186-4 XYSSL RSA PKCS #1 1.5 SigVer with 2048 bit keys using SHA-1 and SHA-
256 for image verification (Cert. #2638).
(Note: SHA-1 is CAVP tested but not used.)
• XYSSL SHA-256 for hashing and for use with image verification (Cert. #3960)
(Note: SHA-1 is CAVP tested but not used.)
• TLS v1.2 KDF for TLS session key derivation (CVL Cert. #1526)
• SSH KDF for SSH session key derivation (CVL Cert. #1441)
• SP 800-133 CKG (Vendor Affirmed)
(Note: The vendor affirms asymmetric keys are generated per SP 800-133 (unmodified output from the
DRBG))
Allowed Algorithms and Protocols
The module supports the following FIPS allowed algorithms and protocols:
• RSA with 2048-bit keys for key wrapping (key establishment methodology provides 112
bits of encryption strength)
• Diffie-Hellman with 2048-bit keys for key agreement (key establishment methodology
provides 112 bits of encryption strength)
Page 7
• NDRNG (internal entropy source) for seeding the Block Cipher (CTR) DRBG. The module
generates a minimum of 256 bits of entropy for key generation.
• TLS v1.2 with the following algorithm tested cipher suites. The protocol algorithms have
been tested by the CAVP (see certificate #s above) but the protocol implementation itself
has not been reviewed or tested by the CAVP or CMVP.
o TLS_RSA_WITH_AES_128_GCM_SHA256 for communication with Network
Security Platform (NSP) Manager
(Note: This is restricted to RSA-2048)
• SSH v2 with the following algorithm tested cipher suites. The protocol algorithms have
been tested by the CAVP (see certificate #s above) but the protocol implementation itself
has not been reviewed or tested by the CAVP or CMVP.
o Key Exchange methods (i.e., key establishment methods): Diffie-hellman-
group14-SHAl
o Public Key methods (i.e., authentication methods): SSH-RSA
(Note: This is restricted to RSA-2048)
o Encryption methods: AES128-GCM, AES256-GCM
o MAC methods: HMAC-256, HMAC-512
AES GCM is only used as part of TLS 1.2 cipher suites conformant to IG A.5, RFC 5288 and
SP 800-52
Non-Approved Algorithms and Protocols with No Security Claimed
The module supports the following non-Approved but allowed algorithms and protocols with no
security claimed:
• MD5 used to identify “fingerprint” of potential malware using Global Threat Information
(GTI) database (used internal to the module only). Non-Approved algorithms (no security
claimed): MD5
• SNMPv3 is used as a transport mechanism with no security claimed. All CSP content in
this SNMPv3 channel is additionally key wrapped and signed by NSM to ensure integrity
and decrypted in sensor using the TLS Sensor Private Key. Non-CSP SNMPv3 content is
deemed plaintext. Non-Approved algorithms (no security claimed): HMAC
(noncompliant), SHA (non-compliant), AES (non-compliant), Triple-DES (non-
compliant), MD5, DES and SNMP KDF (non-compliant).
• The following algorithms are implemented independently from all other cryptographic
code in the module and are used to analyze the network stream for malware and
malicious network attacks in accordance with the functionality of the product. For the
reasoning stated above, this functionality is allowed in the FIPS Approved mode of
operation.
o Decryption - SSLv2
- Cipher suites:
▪ SSL_CK_RC4_128_WITH_MD5
▪ SSL_CK_RC4_128_EXPORT40_WITH_MD5
▪ SSL_CK_DES_64_CBC_WITH_MD5
▪ SSL_CK_DES_192_EDE3_CBC_WITH_MD5
- Non-Approved algorithms (no security claimed): Triple-DES (non-
compliant), HMAC (non-compliant), RC4, MD5, DES
o Decryption - SSLv3/TLS
Page 8
- Cipher suites:
▪ SSL/TLS_NULL_WITH_NULL_NULL
▪ SSL/TLS_RSA_WITH_NULL_MD5
▪ SSL/TLS_RSA_WITH_NULL_SHA
▪ SSL/TLS_RSA_WITH_RC4_128_MD5
▪ SSL/TLS_RSA_WITH_RC4_128_SHA
▪ SSL/TLS_RSA_WITH_DES_CBC_SHA
▪ SSL/TLS_RSA_WITH_3DES_EDE_CBC_SHA
▪ SSL/TLS_RSA_WITH_AES_128_CBC_SHA
▪ SSL/TLS_RSA_WITH_AES_256_CBC_SHA
- Non-Approved algorithms (no security claimed): AES (non-compliant), RSA
(non-compliant), SHA (non-compliant), Triple-DES (non-compliant), HMAC
(non-compliant), RC4, MD5, DES
4 Ports and Interfaces
Table 2 provides the cryptographic module’s ports and interfaces.
Table 2 – Fixed Ports
Fixed Ports Number of ports Input/Output Type
40-Gig QSFP+ Monitoring Ports 2 Data Input/Output
1-GigE Monitoring Ports 8 Data Input/Output
Network I/O slots 2 Data Input/Output
GigE Management Port 1 Control Input, Data Output, Status Output
GigE Response Port 1 Data Output
GigE Aux Port 1 Data Output
RS232 Console 1 Control Input, Status Output
USB Ports 2 Data Input
Power Ports 2 Power Input
LEDs Many Status Output
Notes:
1. The Two fixed QSFP+ 40-GigE ports are used to connect to the peer NS-9300 S unit.
2. The GigE Response Port is connected directly to the peer NS-9300 S unit’s GigE Management
Port.
3. The Network IO Slots each accept interface modules which provide additional monitoring
ports. The interface modules are not included in the cryptographic boundary.
The module supports the following communication channels with the Network Security Platform
(NSP) Manager:
• Install channel: Only used to associate a Sensor with the NSM. They use a “shared secret”.
NSM listening on port 8501.
• Trusted Alert/Control channel (TLS): NSM listening on port 8502
• Trusted Packet log channel (TLS): NSM listening on port 8503
• Command channel (SNMP, plaintext): Sensor listening to 3rd Party SNMP Clients on port
8500
Page 9
• Bulk transfer channel (TLS): NSM listening on port 8504
• Trusted Authentication Gateway channel (TLS): uses same crypto context as Alert/Control
channel. NSM listening on port 8502.
Figure 3 - Front Panels of NS-9300 P
Table 3 – NS-9300 P Front Panel Ports and Connectors
Item Description
1 Console ports on the NS-9300 P Sensors (1)
2 QSFP+ 40 Gigabit Ethernet Interconnect ports (2). G0/1 and G0/2 on NS-9300 P Sensor
Sensor.
3 Two slots for Network I/O modules. The Network I/O modules are outside of the
cryptographic boundary. There is no security relevance to using the following Network
I/O modules in any combination.
• QSFP+ 40 Gigabit Ethernet ports (2)
• QSFP+ 40 Gigabit Ethernet ports (1)
• SFP/SFP+ 1/10 Gigabit Ethernet Monitoring ports (4)
• RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (3)
4 RJ-45 10/100/1000 Mbps Ethernet Monitoring ports (8)
Figure 4 - Front panel with no Network I/O Modules or cover plate
Page 10
Figure 5 - Rear Panels of NS-9300 P
Table 4 – NS-9300 P Rear Panel Ports and Connectors
Item Description
1 USB ports (2)
2 Power supply A (Pwr A)
3 Power supply B (Pwr B) (optional on NS9100)
4 RJ-45 100/1000/10000 Management port (Mgmt) (1)
5 RJ-45 100/1000/10000 Response port (R1) (1). R1 on NS-9300 P Sensor is used as an
interconnect port.
6 RJ-45 Auxiliary port (Aux) (1)
Figure 6 - Rear Panel with Power Supplies Removed
Page 11
5 Identification and Authentication Policy
The cryptographic module shall support four distinct “User” roles (Admin, Sensor Operator(s),
NS-9300 S, and 3rd Party SNMP Client(s)) and one “Cryptographic Officer” (CO) role (Network
Security Platform Manager). Table 5 lists the supported operator roles along with their required
identification and authentication techniques. Table 6 outlines each authentication mechanism and
the associated strengths.
Table 5 - Roles and Required Identification and Authentication
Role Type of Authentication Authentication Data
Admin (User) Role-based authentication Username and Password
Sensor Operator(s) (User) Role-based authentication Username and Password
Network Security Platform Manager (CO) Role-based authentication Digital Signature
NS-9300 S (User) Role-based authentication Shared Secret
3rd Party SNMP Client(s) (User) Role-based authentication Username, Privacy and
Authentication key
Table 6 – Strengths of Authentication Mechanisms
Authentication Mechanism Strength of Mechanism
Username and Password
(Admin and Sensor
Operator(s))
The password is an alphanumeric string of a minimum of
fifteen (15) characters chosen from the set of ninety-three (93)
printable and human-readable characters. Whitespace and “?”
are not allowed. New passwords are required to include 2
uppercase characters, 2 lowercase characters, 2 numeric
characters, and 2 special characters.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/{(10^2)*(26^4)*(31^2)*(93^7)},
which is less than 1/1,000,000.
After three (3) consecutive failed authentication attempts, the
module will enforce a one (1) minute delay prior to allowing
retry. Additionally, the module only supports 5 concurrent SSH
sessions. Thus, the probability of successfully authenticating to
the module within one minute through random attempts is
(3*5)/ {(10^2)*(26^4)*(31^2)*(93^7)}, which is less than
1/100,000.
Page 12
Authentication Mechanism Strength of Mechanism
Shared Secret
(NS-9300 S)
The Shared Secret is an alphanumeric string of a minimum of
six (6) characters chosen from the set of ninety-three (93)
printable and human-readable characters. Whitespace and “?”
are not allowed.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/93^6 which is less than 1/1,000,000.
After setting the Shared Secret, the module requires a reboot in
order to authenticate. The reboot takes longer than one minute
before authentication is achieved, and if authentication fails, the
module automatically reboots a second time. The probability of
successfully authenticating to the module within one minute
through random attempts is 1/93^6 which is less than
1/100,000.
Digital Signature and RSA Key
Wrap
RSA 2048-bit keys using SHA-256 are used for the signing (in
isolated McAfee laboratory) and verification (by sensor) of
digital signatures.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/2^112 which is less than 1/1,000,000.
The module can only perform one (1) digital signature
verification per second. The probability of successfully
authenticating to the module within one minute through random
attempts is 60/2^112 which is less than 1/100,000.
Username, Privacy and
Authentication Key
The privacy key and authentication key together make an
alphanumeric string of a minimum of sixteen (16) characters
chosen from the set of sixty-two (62) numbers, lower case
letters, and upper case letters.
The probability that a random attempt will succeed or a false
acceptance will occur is 1/62^16 which is less than 1/1,000,000.
The module will allow approximately one (1) attempt per
millisecond, meaning that 60,000 attempts can be made per
minute. The probability of successfully authenticating to the
module within one minute through random attempts is
60,000/62^16 which is less than 1/100,000.
Page 13
6 Access Control Policy
6.1 Roles and Services
Table 7 lists each operator role and the services authorized for each role.
For additional information of operation of the module, see the Network Security Platform 9.1 CLI
Guide.
Table 7 – Services Authorized for Roles
Approved
Mode
Authorized Services
Admin
Sensor
Operator(s)
NSP
Manager
NS-9300
S
3rd
Party
SNMP
Client(s)
X Show Status: Provides the status of the module, usage statistics,
log data, and alerts.
X X
X
X Sensor Operator Management: Allows Admin to add/delete
Sensor Operators, set their service authorization level, set their
session timeout limit, and unlock them if needed.
X
X Network Configuration: Establish network settings for the
module or set them back to default values.
X X* X
X Administrative Configuration: Other various services provided
for admin, private, and support levels. X X* X
X Firmware Update: Install an external firmware image through
SCP or USB X X* X
X Install with NSM: Configures module for use. This step includes
establishing trust between the module and the associated
management station.
X X*
X Install with 3rd
Party SNMP Client: Configures module for 3rd
Party SNMPv3 use. This step includes establishing trust between
the module and the associated 3rd
Party SNMP Client. Trust is
provided by NSM.
X
X Change Passwords: Allows Admin and Sensor Operators to
change their associated passwords. Admin can also change/reset
Sensor Operators passwords.
X X*
X Zeroize: Destroys all plaintext secrets contained within the
module. The “Reset Config” command is used, followed by a
reboot.
X X*
X Intrusion Detection/Prevention Management: Management of
intrusion detection/prevention policies and configurations through
SNMPv3 and TLS.
X
Page 14
Intrusion Detection/Prevention Monitoring: Limited monitoring
of Intrusion Detection/Prevention configuration, status, and
statistics through SNMPv3.
X X
X Disable SSH/Console Access: Disables SSH/Console access. X X*
* Depending on the authorization level granted by the Admin
Unauthenticated Services:
Table 8 lists the unauthenticated services supported by the module.
Table 8 – Unauthenticated Services
Approved
Mode
Unauthenticated Services
X Authentication: This service is associated with an unauthorized operator making a
request in order to authenticate themselves to the module.
X Self-Tests: This service executes the suite of self-tests required by FIPS 140-2. Self-tests
can be initiated by power cycling the module or through the CLI.
Intrusion Prevention Services: Offers protection against zero-day, DoS/DDoS,
encrypted and SYN Flood attacks, and real-time prevention of threats like spyware,
malware, VoIP vulnerabilities, phishing, botnets, network worms, Trojans, and peer-to-
peer applications.
Note: This service utilizes the non-Approved algorithms listed above. This includes an
MD5 hash to identify the “fingerprint” of malware and decryption of SSL-encrypted
streams for the purpose of detecting malware and network attacks. See the list above.
X Zeroize: Destroys all plaintext secrets contained within the module. The Internal
Rescue process is used.
6.2 Definition of Critical Security Parameters (CSPs)
The following are CSPs contained in the module:
• Administrator Passwords: Password used for authentication of the “admin” role through
Console and SSH login. Extended permissions are given to the “admin” role by using the
“support” or “private” passwords.
• Sensor Operator Passwords: Passwords used for authentication of “user” accounts
through Console and SSH login. Extended permissions are given to the “user” account by
using the “support” or “private” passwords.
• 3rd
Party SNMP Client Privacy and Authentication Keys: Passwords used for
authentication of 3rd
Party SNMP Clients.
• NS-9300 Password: Password for authentication of the NS-9300 S.
Page 15
• NSM Initialization Secret (i.e., NSM Shared Secret): Password used for mutual
authentication of the sensor and NSM during initialization.
• Bulk Transfer Channel Session Key: AES 128 bit key used to encrypt data packages
across the bulk transfer channel.
• SSH Host Private Keys: RSA 2048 bit key used for authentication of sensor to remote
terminal for CLI access, generated during initialization
• SSH Session Keys: Set of Diffie-Hellman private key 128 – 512 bit, AES 128/256 bit,
and HMAC (SHA-1/256/512 bit) keys created for each SSH session.
• TLS Sensor Private Key (for NSM): RSA 2048 bit key used for authentication of the
sensor to NSM.
• TLS Session Keys (for NSM): Set of AES 128/256 bit and HMAC (SHA-1/256/512 bit)
keys created for each TLS session with the NSM.
• Seed for DRBG: Seed created by NDRNG and used to seed the Block Cipher (CTR)
DRBG. The Nonce is 128 bits and the Entropy Input is 256 bits for a total seed size of 384
bits.
• DRBG Internal State: V and Key used by the DRBG to generate pseudo-random numbers
6.3 Definition of Public Keys
The following are the public keys contained in the module:
• McAfee FW Verification Key: RSA 2048 bit key used to authenticate firmware images
loaded into the module.
• SSH Host Public Key: RSA 2048 bit key used to authenticate the sensor to the remote
client during SSH.
• SSH Remote Client Public Key: RSA 2048 bit key used to authenticate the remote client
to the sensor during SSH.
• TLS Sensor Public Key (for NSM): RSA 2048 bit key used to authenticate the sensor to
NSM during TLS connections.
• TLS NSM Public Key: RSA 2048 bit key used to authenticate NSM to sensor during TLS
connections.
6.4 Definition of CSPs Modes of Access
Table 9 defines the relationship between access to keys/CSPs and the different module services.
The types of access used in the table are Use (U), Generate (G), Input (I), Output (O), Store (S),
and Zeroize (Z). Z* is used to denote that only the plaintext portion of the CSP is zeroized (i.e.,
the CSP is also stored using an Approved algorithm, but that portion is not zeroized).
Page 16
Table 9 – Key and CSP Access Rights within Services
Administrator
Passwords
Sensor
Operator
Passwords
NS-9300
Password
3rd
Party
SNMP
Client
P
and
A
Keys
NSM
Initialization
Secret
Bulk
Transfer
Channel
Session
Key
SSH
Host
Private
Keys
SSH
Session
Keys
TLS
Sensor
Private
Key
(for
NSM)
TLS
Session
Keys
(for
NSM)
Seed
for
DRBG
DRBG
Internal
State
McAfee
FW
Verification
Key
SSH
Host
Public
Key
SSH
Remote
Client
Public
Key
TLS
Sensor
Public
Key
(for
NSM)
TLS
NSM
Public
Key
Authentication – Admin, Sensor
Operator
U U
U
G
U
G
U
G
G
O
I
U
Authentication – NSP Manager –
Digital Signature
U U
U
G
U
G
O U
SNMP Authentication – NSP Manager
to Sensor – Username, Privacy, and
Authentication Key
Authentication – 3rd
Party SNMP
Client(s)
U I
S
Show Status U U
Sensor Operator Management
U U
Network Configuration
U U
Administrative Configuration
I U U
Firmware Update I
U
U U
U
I
Install with NSM I
U
G U
U
G
U
G
U G
Install with 3rd
Party SNMP Client
S
I
U
U
Change Passwords
I S I S
R
W
Zeroize
(Authenticated)
Z* Z*
Z
Z Z Z Z Z Z Z Z Z Z Z Z Z Z
Zeroize
(Unauthenticated)
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
Intrusion Detection/
Prevention Management
U U U U U
Intrusion Detection/
Prevention Monitoring
U
Disable SSH/Console Access
U
Self Tests
Intrusion Prevention Services
Page 17
7 Operational Environment
The device supports a limited operational environment.
Page 18
8 Security Rules
The cryptographic module’s design corresponds to the module’s security rules. This section
requirements of this FIPS 140-2 Level 2 module.
• The cryptographic module shall provide five distinct operator roles: Admin, Sensor
Operator(s), Network Security Platform Manager, NS-9300 S and 3rd Party SNMP
Client(s). The cryptographic module shall provide role-based authentication and each
change of operator roles shall be authenticated and previous authentication results are
cleared when the module transitions to a power-off state.
• When the module has not been placed in a valid role, the operator shall not have access to
any cryptographic services.
• The cryptographic module shall perform the following tests:
o Power up Self-Tests are performed without operator input:
• Firmware Integrity Test: RSA 2048 (Cert. #2638) using SHA-256 (Cert.
#3960) for hashing
• Cryptographic algorithm known answer tests (KATs) and pairwise
consistency tests (PCT):
• AES ECB 128 Encryption KAT and Decryption KAT (Cert. #4820)
• AES GCM Encryption KAT and Decryption KAT (Cert. #4820)
• RSA 2048 PSS Key Generation/Sign/Verify Pairwise Consistency
Test (Cert. #2638)
• SHA-1 KAT (Cert. #3962)
• SHA-256 KAT (Cert. #3962)
• SHA-512 KAT (Cert. #3962)
• Block Cipher (CTR) DRBG KAT and SP 800-90A DRBG Section
11.3 Health Checks (Cert. #1679)
• HMAC SHA-1 KAT (Cert. #3221)
• HMAC SHA-256 KAT (Cert. #3221)
• HMAC SHA-512 KAT (Cert. #3221)
• XYSSL RSA 2048 Signature Verification KAT (Cert. #2638)
(SHA-1 and SHA-256 based signatures)
• XYSSL SHA-1 KAT (Cert. #3960)
• XYSSL SHA-256 KAT (Cert. #3960)
• TLS 1.2 KDF KAT (CVL Cert. #1526)
• SSH KDF KAT (CVL Cert. #1441)
If any of these tests fail the following message will be displayed:
!!! CRITICAL FAILURE !!!
FIPS 140-2 POST and KAT...Failed
REBOOTING IN 15 SECONDS
Page 19
o Conditional Self-Tests:
▪ Block Cipher (CTR) DRBG Continuous Test
▪ SP 800-90A DRBG Section 11.3 Health Checks
▪ NDRNG Continuous Test
▪ RSA KeyGen/Sign/Verify Pairwise Consistency Test (Cert. #2639)
▪ XYSSL RSA KeyGen Pairwise Consistency Test (Cert. #2638)
▪ External Firmware Load Test –RSA 2048 (Cert. #2638) using SHA-256
(Cert. #3960) for hashing
If the firmware load test fails the following message will be displayed: "Load Image
with SCP Failed."
• At any time the cryptographic module is in an idle state, the operator shall be capable of
commanding the module to perform the power up self-test by power cycling.
• Data output shall be inhibited during self-tests and error states.
• All Power Up Self-Test are run before data output ports are initialized.
• In the case of failed Power Up Self Tests, the module enters an error state, and
reboots.
• Data output shall be logically disconnected during key generation and zeroization.
• For both Zeroize services (authenticated and unauthenticated), the operator must remain in
control of the module or be physically present with the module to assure that the entire
zeroization process completes successfully. This may take up to one minute.
• Status information shall not contain CSPs or sensitive data that if misused could lead to a
compromise of the module.
• If a non-FIPS validated firmware version is loaded onto the module, then the module is no
longer a FIPS validated module.
• The module shall only support five concurrent SSH operators when SSH is enabled.
• The cryptographic module shall not be configured to transmit files to McAfee Advanced
Threat Detection.
Page 20
9 Physical Security Policy
9.1 Physical Security Mechanisms
The cryptographic module includes the following physical security mechanisms:
• Production-grade components
• Production-grade opaque enclosure with tamper evident seals. Tamper evident seals and
further instructions are obtained in the FIPS Kits with the following part numbers:
o NS9300 P: IAC-FIPS-KT2
9.2 Operator Required Actions
For the module to operate in a FIPS Approved mode, the tamper seals shall be placed by the Admin
role as specified below. The Admin must clean the chassis of any dirt before applying the labels.
Per FIPS 140-2 Implementation Guidance (IG) 14.4, the Admin role is also responsible for the
following:
• Securing and having control at all times of any unused seals
• Direct control and observation of any changes to the module, such as reconfigurations,
where the tamper evident seals or security appliances are removed or installed to ensure
the security of the module is maintained during such changes and the module is returned
to a FIPS Approved state.
The Admin is also required to periodically inspect tamper evident seals. Table 10 outlines the
recommendations for inspecting/testing physical security mechanisms of the module. If the Admin
finds evidence of tampering, then the module is no longer FIPS compliant.
Table 10 – Inspection/Testing of Physical Security Mechanisms
Physical Security
Mechanisms
Recommended Frequency
of Inspection/Test
Inspection/Test Guidance
Details
Tamper Evident Seals As specified per end user
policy, annually at a
minimum
Visually inspect the labels for
tears, rips, dissolved
adhesive, and other signs of
malice.
Opaque Enclosure As specified per end user
policy, annually at a
minimum
Visually inspect the enclosure
for broken screws, bent
casing, scratches, and other
questionable markings.
Page 21
Figure 7 depicts the tamper label locations on the cryptographic module for the NS9300 P
platform. There are 9 tamper labels and they are numbered in red. An example tamper label is
shown in Figure 10.
Figure 7 – Tamper Label Placement Top (NS9300 P sensors)
Figure 8 – Tamper Label Placement Front (NS9300 P sensor)
Page 22
Figure 9 – Tamper Label Placement Front (NS9300 P with NS9300 S)
Figure 10 – Tamper Label
Page 23
10 Mitigation of Other Attacks Policy
The module has not been designed to mitigate any specific attacks beyond the scope of FIPS 140-
2 requirements.