Page 1 FIPS Policy
Juniper Networks SRX300, SRX340, and SRX345 Services Gateways
Non-Proprietary FIPS 140-2 Cryptographic Module Security Policy
Version: 2.4
Date: December 22, 2017
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408.745.2000
1.888 JUNIPER
www.juniper.net
Page 2 FIPS Policy
Table of Contents
1 Introduction ................................................................................................................................................................................................4
2 Hardware and Physical Cryptographic Boundary .........................................................................................................................................5
2.1 Mode of Operation .........................................................................................................................................................6
2.2 Zeroization....................................................................................................................................................................7
3 Cryptographic Functionality.........................................................................................................................................................................7
3.1 Approved Algorithms.......................................................................................................................................................7
3.2 Allowed Algorithms.......................................................................................................................................................10
3.3 Allowed Protocols.........................................................................................................................................................10
3.4 Disallowed Algorithms ...................................................................................................................................................11
3.5 Critical Security Parameters ............................................................................................................................................12
4 Roles, Authentication and Services............................................................................................................................................................ 13
4.1 Roles and Authentication of Operators to Roles ..................................................................................................................13
4.2 Authentication Methods ................................................................................................................................................13
4.3 Services......................................................................................................................................................................13
4.4 Non-Approved Services..................................................................................................................................................16
5 Self-Tests................................................................................................................................................................................................... 17
6 Physical Security Policy.............................................................................................................................................................................. 18
6.1 General Tamper Seal Placement and Application Instructions.................................................................................................19
6.2 SRX300 (4 seals) ...........................................................................................................................................................20
6.3 SRX 340/345 (27 seals)...................................................................................................................................................21
7 Security Rules and Guidance...................................................................................................................................................................... 23
8 References and Definitions........................................................................................................................................................................ 23
List of Tables
TABLE 1 – CRYPTOGRAPHIC MODULE CONFIGURATIONS........................................................................................................................................ 4
TABLE 2 - SECURITY LEVEL OF SECURITY REQUIREMENTS........................................................................................................................................ 4
TABLE 3 - PORTS AND INTERFACES .................................................................................................................................................................... 6
TABLE 4 – DATA PLANE APPROVED CRYPTOGRAPHIC FUNCTIONS ............................................................................................................................ 7
TABLE 5 – CONTROL PLANE AUTHENTEC APPROVED CRYPTOGRAPHIC FUNCTIONS...................................................................................................... 8
TABLE 6 – OPENSSL APPROVED CRYPTOGRAPHIC FUNCTIONS ................................................................................................................................ 9
TABLE 7 – OPENSSL APPROVED CRYPTOGRAPHIC FUNCTIONS ................................................................................................................................ 9
TABLE 8 – OPENSSH APPROVED CRYPTOGRAPHIC FUNCTIONS ............................................................................................................................. 10
TABLE 9 – LIBMD APPROVED CRYPTOGRAPHIC FUNCTIONS ................................................................................................................................. 10
TABLE 10 - ALLOWED CRYPTOGRAPHIC FUNCTIONS ............................................................................................................................................ 10
TABLE 11 - PROTOCOLS ALLOWED IN FIPS MODE.............................................................................................................................................. 10
TABLE 12 - CRITICAL SECURITY PARAMETERS (CSPS) .......................................................................................................................................... 12
TABLE 13 - PUBLIC KEYS................................................................................................................................................................................ 12
TABLE 14 - AUTHENTICATED SERVICES ............................................................................................................................................................. 14
TABLE 15 - UNAUTHENTICATED TRAFFIC........................................................................................................................................................... 14
TABLE 16 - CSP ACCESS RIGHTS WITHIN SERVICES ............................................................................................................................................. 15
TABLE 17: PUBLIC KEY ACCESS RIGHTS WITHIN SERVICES..................................................................................................................................... 15
TABLE 18 - AUTHENTICATED SERVICES ............................................................................................................................................................. 16
TABLE 19 - UNAUTHENTICATED TRAFFIC ........................................................................................................................................................... 17
TABLE 20 – PHYSICAL SECURITY INSPECTION GUIDELINES..................................................................................................................................... 19
TABLE 21– REFERENCES ................................................................................................................................................................................ 23
Page 3 FIPS Policy
TABLE 22 – ACRONYMS AND DEFINITIONS ........................................................................................................................................................ 24
TABLE 23 – DATASHEETS............................................................................................................................................................................... 25
List of Figures
FIGURE 1. SRX300 ........................................................................................................................................................................................ 5
FIGURE 2. SRX340 ........................................................................................................................................................................................ 5
FIGURE 3. SRX345 ........................................................................................................................................................................................ 6
FIGURE 4. SRX300 TAMPER-EVIDENT SEAL PLACEMENT- FOUR (4) SEALS ............................................................................................................. 20
FIGURE 5. SRX340/SRX345 TAMPER-EVIDENT SEAL PLACEMENT - TOP COVER. NINE (9) SEALS............................................................................... 21
FIGURE 6. SRX 340/345 TAMPER-EVIDENT SEAL PLACEMENT - RARE PANEL. TWO (2) SEALS................................................................................... 22
FIGURE 7. SRX340/SRX345 TAMPER-EVIDENT SEAL PLACEMENT - SIDE PANELS OVER THE SCREW HOLES. EIGHT ON EACH SIDE (16) SEALS..................... 22
Page 4 FIPS Policy
1 INTRODUCTION
The Juniper Networks SRX Series Services Gateways are a series of secure routers that provide essential capabilities to
connect, secure, and manage work force locations sized from handfuls to hundreds of users. By consolidating fast, highly
available switching, routing, security, and applications capabilities in a single device, enterprises can economically deliver
new services, safe connectivity, and a satisfying end user experience. All models run Juniper’s JUNOS firmware – in this
case, a specific FIPS-compliant version, when configured in FIPS-MODE called JUNOS-FIPS-MODE, version 15.1X49-D60.
The firmware image is junos-srxsme-15.1X49-D60.10-domestic.tgz and the firmware Status service identifies itself as in
the “Junos OS 15.1X49-D60.10”.
This Security Policy covers the “Branch” models – the SRX300, SRX340, and SRX345. They are meant for corporate branch
offices of various sizes. (Intended size is proportional to model number.)
The cryptographic modules are defined as multiple-chip standalone modules that execute JUNOS firmware on any of the
Juniper Networks SRX-Series Services Gateways listed in the table below.
Table 1 – Cryptographic Module Configurations
Model Hardware Versions Firmware Distinguishing Features
SRX300 SRX300
JUNOS
15.1X49-D60
6 x 10/100/1000; 2 SFP
SRX340 SRX340
JUNOS
15.1X49-D60
8 x 10/100/1000; 4 SFP; 4 MPIM
expansion slots; 1 x 10/100/1000
management port
SRX345 SRX345
JUNOS
15.1X49-D60
8 x 10/100/1000; 4 SFP; 4 MPIM
expansion slots; 1 x 10/100/1000
management port
All
JNPR-FIPS-TAMPER-LBLS
(P/N 520-052564)
N/A
Tamper-Evident Seals
(FIPS Label for PSD Products)
The modules are designed to meet FIPS 140-2 Level 2 overall:
Table 2 - Security Level of Security Requirements
Area Description Level
1 Module Specification 2
2 Ports and Interfaces 2
3 Roles and Services 3
4 Finite State Model 2
5 Physical Security 2
6 Operational Environment N/A
7 Key Management 2
8 EMI/EMC 2
9 Self-test 2
10 Design Assurance 3
11 Mitigation of Other Attacks N/A
Overall 2
Page 5 FIPS Policy
The modules have a limited operational environment as per the FIPS 140-2 definitions. They include 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 these modules is out of the scope of this validation and require a
separate FIPS 140-2 validation.
The modules do not implement any mitigations of other attacks as defined by FIPS 140-2.
2 HARDWARE AND PHYSICAL CRYPTOGRAPHIC BOUNDARY
The physical forms of the module’s various models are depicted in Figures 1-5 below. For all models the cryptographic
boundary is defined as the outer edge of the chassis. The SRX340 and SRX345 exclude the TI TMP435ADGSR temperature
sensor from the requirements of FIPS 140-2.
Figure 1. SRX300
Figure 2. SRX340
Page 6 FIPS Policy
Figure 3. SRX345
Table 3 - Ports and Interfaces
Port Description Logical Interface Type
Ethernet LAN Communications Control in, Data in, Data out, Status out
Serial Console serial port Control in, Status out
Power Power connector Power in
Reset Reset button Control in
LED Status indicator lighting Status out
USB Firmware load port Control in, Data in
WAN SHDSL, VDSL, T1, E1 Control in, Data in, Data out, Status out
2.1 MODE OF OPERATION
The cryptographic module provides a non-Approved mode of operation in which non-Approved cryptographic algorithms
are supported. The module supports non-Approved algorithms when operating in the non-Approved mode of operation
as described in Sections 2.4 and 3.4. When transitioning between the non-Approved mode of operation and the Approved
mode of operation, the CO must zeroize all CSPs by following the instructions in Section 1.3. If the module was previously
in a non-Approved mode of operation, the Cryptographic Officer must zeroize the CSPs by following the instructions in
Section 1.4
Then, the CO must run the following commands to configure the module into the Approved mode of operation:
co@fips-srx# set system fips level 2
co@fips-srx# commit
When Triple-DES is configured as the encryption-algorithm for IKE or IPsec, the CO must configure the IPsec proposal
lifetime-kilobytes to comply with [IG A.13] using the following command:
co@fips-srx:fips# set security ipsec proposal <ipsec_proposal_name> lifetime-kilobytes <kilobytes>”
Page 7 FIPS Policy
co@fips-srx:fips# commit
When Triple-DES is the encryption-algorithm for IKE (regardless of the IPsec encryption algorithm), the lifetime-kilobytes
for the associated IPsec proposal must be greater than or equal to 12800.
When Triple-DES is the encryption-algorithm for IPsec, the lifetime-kilobytes must be less than or equal to 33554432.
When AES-GCM is configured as the encryption-algorithm for IKE or IPSec, the CO must also configure the module to use
IKEv2 by running the following commands:
co@fips-srx:fips# set security ike gateway <name> version v2-only
<name> - the user configured name for the IKE gateway
co@fips-srx:fips# commit
The operator can verify the module is operating in the Approved mode by verifying the following:
• The “show version” command indicates that the module is running the Approved firmware (i.e. JUNOS Software
Release [15.1X49-D60]).
• The command prompt ends in “:fips”, which indicates the module has been configured in the Approved mode of
operation.
• The “show security ike” and “show security ipsec” commands show IKEv2 is configured when either an IPsec or
IKE proposal is configured to use AES-GCM.
2.2 ZEROIZATION
The following command allows the Cryptographic Officer to zeroize CSPs contained within the module:
co@fips-srx> request system zeroize
Note: The Cryptographic Officer must retain control of the module while zeroization is in process.
3 CRYPTOGRAPHIC FUNCTIONALITY
The module implements the FIPS Approved, vendor affirmed, and non-Approved but Allowed cryptographic functions
listed in Table 4 through Table 10 below. Table 11 summarizes the high level protocol algorithm support.
3.1 APPROVED ALGORITHMS
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.
Table 4 – Data Plane Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
4348
4347
AES [197] CBC [38A] Key Sizes: 128, 192, 256 Encrypt, Decrypt
Page 8 FIPS Policy
GCM [38D] Key Sizes: 128, 192, 256 Encrypt, Decrypt, AEAD
2888
2887
HMAC [198]
SHA-1 λ = 96
Message Authentication
SHA-256 λ = 128
3585
3584
SHS [180]
SHA-1
SHA-256
Message Digest Generation
2352
2351
Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
Table 5 – Control Plane Authentec Approved Cryptographic Functions
Cert Algorithm Mode Description Functions
4345 AES [197]
CBC [38A] Key Sizes: 128, 192, 256 Encrypt, Decrypt
GCM [38D] Key Sizes: 128, 256 Encrypt, Decrypt, AEAD
N/A1
CKG
[133] Section 6.2
Asymmetric key generation
using unmodified DRBG
output
[133] Section 7.3
Derivation of symmetric
keys
1051 CVL
IKEv1 [135] SHA 256, 384
Key Derivation
IKEv2 [135] SHA 256, 384
1041
1040
ECDSA [186]
P-256 (SHA 256)
P-384 (SHA {256}, 384)
KeyGen, SigGen, SigVer
2885 HMAC [198]
{SHA-1}
IKE Message Authentication,
IKE KDF Primitive
SHA-256 λ = 128, 256
SHA-384 λ = 192, 384
N/A KTS
AES Cert. #4345 and HMAC Cert. #2885
Key establishment
methodology provides
between 128 and 256 bits of
encryption strength
Triple-DES Cert. #2349 and HMAC Cert.
#2885
Key establishment
methodology provides 112
bits of encryption strength
2361
2360
RSA [186]
PKCS1_V1_
5
n=2048 (SHA 256)
n=4096 (SHA 256) 2 SigGen, SigVer
3582 SHS [180]
{SHA-1}
SHA-256
SHA-384
Message Digest Generation
2349 Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
1
Vendor Affirmed.
2
RSA 4096 SigGen was tested to FIPS 186-4; however, the CAVP certificate lists 4096 under FIPS 186-2.
Page 9 FIPS Policy
Table 6 – OpenSSL Approved Cryptographic Functions
Cert Algorithm Mode Description Functions
1398 DRBG [90A] HMAC SHA-256
Control Plane Random Bit
Generation/ Open SSL Random
Bit Generator
Table 7 – OpenSSL Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
4362 AES [197]
CBC [38A]
CTR[38A]
Key Sizes: 128, 192, 256 Encrypt, Decrypt
N/A
3
CKG
[133] Section 6.1
[133] Section 6.2
Asymmetric key generation using
unmodified DRBG output
[133] Section 7.3 Derivation of symmetric keys
1038 ECDSA [186]
{P-224 (SHA 256)}
P-256 (SHA 256)
{P-384 (SHA 256)}
SigGen
{P-224 (SHA 256)}
P-256 (SHA 256)
P-384 (SHA {256}, 384)
{P-521 (SHA-256)}
KeyGen, SigVer
2902 HMAC [198]
SHA-1 λ = 160
SSH Message Authentication
DRBG Primitive
SHA-256 λ = 256
SHA-512 λ = 512
N/A KTS
AES Cert. #4362 and HMAC Cert. #2902
Key establishment methodology
provides between 128 and 256 bits of
encryption strength
Triple-DES Cert. #2358 and HMAC Cert. #2902
Key establishment methodology
provides 112 bits of encryption
strength
2358 RSA [186]
n=2048 (SHA 256)
{n=3072 (SHA 256)}
n=4096 (SHA 256)
4 SigGen
n=2048 (SHA 256)
{n=3072 (SHA 256)}
KeyGen, SigVer
3600 SHS [180]
SHA-1
SHA-256
SHA-384
Message Digest Generation,
SSH KDF Primitive
SHA-512 Message Digest Generation
2358 Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
3
Vendor Affirmed.
4
RSA 4096 SigGen was tested to FIPS 186-4; however, the CAVP certificate lists 4096 under FIPS 186-2.
Page 10 FIPS Policy
Table 8 – OpenSSH Approved Cryptographic Functions
Cert Algorithm Mode Description Functions
1071 CVL SSH [135] SHA 1, 256, 384 Key Derivation
Table 9 – LibMD Approved Cryptographic Functions
Cert Algorithm Mode Description Functions
3586 SHS [180]
SHA-256
SHA-512
Message Digest Generation
3.2 ALLOWED ALGORITHMS
Table 10 - Allowed Cryptographic Functions
Algorithm Caveat Use
Diffie-Hellman [IG] D.8 Provides 112 bits of encryption strength. Key agreement; key establishment
Elliptic Curve Diffie-
Hellman [IG] D.8
Provides 128 or 192 bits of encryption
strength.
Key agreement; key establishment
NDRNG Provides 256 bits of entropy. Seeding the DRBG
3.3 ALLOWED PROTOCOLS
Table 11 - Protocols Allowed in FIPS Mode
Protocol Key Exchange Auth Cipher Integrity
IKEv1
Diffie-Hellman (L = 2048, N = 2047)
EC Diffie-Hellman P-256, P-384
RSA 2048
RSA 4096
Pre-Shared
Secret
ECDSA P-256
ECDSA P-384
Triple-DES CBC
5
AES CBC 128/192/256
AES GCM 128/256
SHA-256,384
IKEv2
6 Diffie-Hellman (L = 2048, N = 2047)
EC Diffie-Hellman P-256, P-384
RSA 2048
RSA 4096
Pre-Shared
Secret
ECDSA P-256
ECDSA P-384
Triple-DES CBC
7
AES CBC 128/192/256
AES GCM
8
128/256
SHA-256,384
5
The Triple-DES key for the IETF IKEv1 protocol is generated according to RFC 2409.
6
IKEv2 generates the SKEYSEED according to RFC7296.
7
The Triple-DES key for the IETF IKEv2 protocol is generated according to RFC 7296.
8
The GCM IV is generated according to RFC5282.
Page 11 FIPS Policy
IPsec ESP
IKEv1 with optional:
• Diffie-Hellman (L = 2048, N = 2047)
• EC Diffie-Hellman P-256, P-384
IKEv1
3 Key Triple-DES CBC
9
AES CBC 128/192/256 HMAC-SHA-
1-96
HMAC-SHA-
256-128
IKEv2 with optional:
• Diffie-Hellman (L = 2048, N = 2047)
• EC Diffie-Hellman P-256, P-384
IKEv2
3 Key Triple-DES CBC
10
AES CBC 128/192/256
AES GCM
11
128/192/256
SSHv2
Diffie-Hellman (L = 2048, N = 2047)
EC Diffie-Hellman P-256, P-384 ECDSA P-256
Triple-DES CBC
12
AES CBC 128/192/256
AES CTR 128/192/256
HMAC-SHA-1
HMAC-SHA-
256
HMAC-SHA-
512
No parts of the IKEv1, IKEv2, ESP, and SSHv2 protocols, other than the KDF, have been tested by the CAVP or CMVP.
The IKE and SSH algorithms allow independent selection of key exchange, authentication, cipher and integrity. In Table 11
- Protocols Allowed in FIPS Mode above, each column of options for a given protocol is independent, and may be used in
any viable combination. These security functions are also available in the SSH connect (non-compliant) service.
3.4 DISALLOWED ALGORITHMS
These algorithms are non-Approved algorithms that are disabled when the module is operated in an Approved mode of
operation.
• ARCFOUR
• Blowfish
• CAST
• DSA (SigGen, SigVer; non-compliant)
• HMAC-MD5
• HMAC-RIPEMD160
• UMAC
9
The Triple-DES key for the ESP protocol is generated by the IETF IKEv1 protocol according to RFC 2409.
10
The Triple-DES key for the ESP protocol is generated by the IETF IKEv2 protocol according to RFC 7296.
11
The GCM IV is generated according to RFC4106.
12
The Triple-DES key for the IETF SSHv2 protocol is generated according to RFCs 4253 and 4344.
Page 12 FIPS Policy
3.5 CRITICAL SECURITY PARAMETERS
All CSPs and public keys used by the module are described in this section.
Table 12 - Critical Security Parameters (CSPs)
Name Description and usage CKG
DRBG_Seed Seed material used to seed or reseed the DRBG N/A
DRBG_State V and Key values for the HMAC_DRBG N/A
SSH PHK
SSH Private host key. 1st
time SSH is configured, the keys are generated.
ECDSA P-256. Used to identify the host.
[133] Section 6.1
SSH DH
SSH Diffie-Hellman private component. Ephemeral Diffie-Hellman
private key used in SSH. Diffie-Hellman (N = 256 bit, 320 bit, 384 bit, 512
bit, or 1024 bit13
), EC Diffie-Hellman P-256, or EC Diffie-Hellman P-384
[133] Section 6.2
SSH-SEK
SSH Session Key; Session keys used with SSH. Triple-DES (3key), AES,
HMAC.
[133] Section 7.3
ESP-SEK IPSec ESP Session Keys. Triple-DES (3 key), AES, HMAC. [133] Section 7.3
IKE-PSK Pre-Shared Key used to authenticate IKE connections. N/A
IKE-Priv IKE Private Key. RSA 2048, RSA 4096, ECDSA P-256, or ECDSA P-384 [133] Section 6.1
IKE-SKEYID IKE SKEYID. IKE secret used to derive IKE and IPsec ESP session keys. [133] Section 7.3
IKE-SEK IKE Session Keys. Triple-DES (3 key), AES, HMAC. [133] Section 7.3
IKE-DH-PRI
IKE Diffie-Hellman private component. Ephemeral Diffie-Hellman private
key used in IKE. Diffie-Hellman N = 224 bit, EC Diffie-Hellman P-256, or
EC Diffie-Hellman P-384
[133] Section 6.2
CO-PW ASCII Text used to authenticate the CO. N/A
User-PW ASCII Text used to authenticate the User. N/A
Table 13 - Public Keys
Name Description and usage CKG
SSH-PUB SSH Public Host Key used to identify the host. ECDSA P-256. [133] Section 6.1
SSH-DH-PUB
Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in
SSH key establishment. DH (L = 2048 bit), EC Diffie-Hellman P-256, or EC Diffie-
Hellman P-384
[133] Section 6.2
IKE-PUB IKE Public Key RSA 2048, RSA 4096, ECDSA P-256, or ECDSA P-384 [133] Section 6.1
IKE-DH-PUB
Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in
IKE key establishment. Diffie-Hellman L = 2048 bit, EC Diffie-Hellman P-256, or
EC Diffie-Hellman P-384
[133] Section 6.2
13
SSH generates a Diffie-Hellman private key that is 2x the bit length of the longest symmetric or MAC key negotiated.
Page 13 FIPS Policy
Name Description and usage CKG
Auth-UPub
SSH User Authentication Public Keys. Used to authenticate users to the
module. ECDSA P-256 or P-384
N/A
Auth-COPub
SSH CO Authentication Public Keys. Used to authenticate CO to the module.
ECDSA P-256 or P-384
N/A
Root CA
Juniper Root CA. ECDSA P-256 or P-384 X.509 Certificate; Used to verify the
validity of the Juniper Package CA at software load.
N/A
Package CA
Package CA. ECDSA P-256 X.509 Certificate; Used to verify the validity of
Juniper Images at software load and boot.
N/A
4 ROLES, AUTHENTICATION AND SERVICES
4.1 ROLES AND AUTHENTICATION OF OPERATORS TO ROLES
The module supports two roles: Cryptographic Officer (CO) and User. The module supports concurrent operators, but does
not support a maintenance role and/or bypass capability. The module enforces the separation of roles using either
identity-based operator authentication.
The Cryptographic Officer role configures and monitors the module via a console or SSH connection. As root or super-user,
the Cryptographic Officer has permission to view and edit secrets within the module.
The User role monitors the router via the console or SSH. The user role may not change the configuration.
4.2 AUTHENTICATION METHODS
The module implements two forms of Identity-Based authentication, username and password over the Console and SSH
as well as username and public key over SSH.
Password authentication: The module enforces 10-character passwords (at minimum) chosen from the 96 human
readable ASCII characters. The maximum password length is 20 characters.
The module enforces a timed access mechanism as follows: For the first two failed attempts (assuming 0 time to process),
no timed access is enforced. Upon the third attempt, the module enforces a 5-second delay. Each failed attempt thereafter
results in an additional 5-second delay above the previous (e.g. 4th
failed attempt = 10-second delay, 5th
failed attempt =
15-second delay, 6th
failed attempt = 20-second delay, 7th
failed attempt = 25-second delay).
This leads to a maximum of nine (9) possible attempts in a one-minute period for each getty. The best approach for the
attacker would be to disconnect after 4 failed attempts and wait for a new getty to be spawned. This would allow the
attacker to perform roughly 9.6 attempts per minute; this would be rounded down to 9 per minute, because there is no
such thing as 0.6 attempts. Thus the probability of a successful random attempt is 1/9610
, which is less than 1/1 million.
The probability of a success with multiple consecutive attempts in a one-minute period is 9/(9610
), which is less than
1/100,000.
ECDSA signature verification: SSH public-key authentication. Processing constraints allow for a maximum of 56,000,000
ECDSA attempts per minute. The module supports ECDSA (P-256 and P-384). The probability of a success with multiple
consecutive attempts in a one-minute period is 56,000,000/(2128
).
4.3 SERVICES
All services implemented by the module are listed in the tables below.
Page 14 FIPS Policy
Table 16 lists the access to CSPs by each service.
Table 14 - Authenticated Services
Service Description CO User
Configure security Security relevant configuration x
Configure Non-security relevant configuration x
Secure Traffic IPsec protected connection (ESP) x
Status Show status x x
Zeroize Destroy all CSPs x
SSH connect
Initiate SSH connection for SSH monitoring and control
(CLI)
x x
IPsec connect Initiate IPsec connection (IKE) x
Console access Console monitoring and control (CLI) x x
Remote reset Software initiated reset x
Table 15 - Unauthenticated Traffic
Service Description
Local reset Hardware reset or power cycle
Traffic Traffic requiring no cryptographic services
Page 15 FIPS Policy
Table 16 - CSP Access Rights within Services
Service
CSPs
DRBG_Seed
DRBG_State
SSH
PHK
SSH
DH
SSH-SEK
ESP-SEK
IKE-PSK
IKE-Priv
IKE-SKEYID
IKE-SEK
IKE-DH-PRI
CO-PW
User-PW
Configure security -- E GWR -- -- -- WR GWR -- -- -- W W
Configure -- -- -- -- -- -- -- -- -- -- -- -- --
Secure traffic -- -- -- -- -- E -- -- -- E -- -- --
Status -- -- -- -- -- -- -- -- -- -- -- -- --
Zeroize -- Z Z -- -- -- Z Z -- -- -- Z Z
SSH connect -- E E GE GE -- -- -- -- -- -- E E
IPsec connect -- E -- -- -- G E E G G G -- --
Console access -- -- -- -- -- -- -- -- -- -- -- E E
Remote reset GZE GZ -- Z Z Z -- -- Z Z Z Z Z
Local reset GZE GZ -- Z Z Z -- -- Z Z Z Z Z
Traffic -- -- -- -- -- -- -- -- -- -- -- -- --
G = Generate: The module generates the CSP
R = Read: The CSP is read from the module (e.g. the CSP is output)
E = Execute: The module executes using the CSP
W = Write: The CSP is written to persistent storage in the module
Z = Zeroize: The module zeroizes the CSP.
Table 17: Public Key Access Rights within Services
Service
Public Keys
SSH-
PUB
SSH-DH-
PUB
IKE-
PUB
IKE-DH-
PUB
Auth-
UPub
Auth-
COPub
Root-
CA
Package-
CA
Configure
security
GWR - GWR - W W - -
Configure - - - - - - - -
Secure
traffic
- - - - - - - -
Status - - - - - - - -
Zeroize Z - Z Z Z Z - -
SSH connect E GE - - E E - -
IPsec
connect
- - E GE - - - -
Console
access
- - - - - - - -
Page 16 FIPS Policy
Remote
reset
- Z - Z Z Z - E
Local reset - Z - Z Z Z - E
Traffic - - - - - - - -
Software
load
- - - - - - EW EW
G = Generate: The module generates the key.
R = Read: The key is read from the module (e.g. the key is output).
E = Execute: The module executes using the key.
W = Write: The key is written to persistent storage in the module.
Z = Zeroize: The module zeroizes the key.
4.4 NON-APPROVED SERVICES
The following services are available in the non-Approved mode of operation. The security functions provided by the non-
Approved services are identical to the Approved counterparts with the exception of SSH Connect (non-compliant). SSH
Connect (non-compliant) supports the security functions identified in Section 2.3 and the SSHv2 row of Table 11 - Protocols
Allowed in FIPS Mode.
Table 18 - Authenticated Services
Service Description CO User
Configure security
(non-compliant)
Security relevant configuration x
Configure (non-
compliant)
Non-security relevant configuration x
Secure Traffic (non-
compliant)
IPsec protected connection (ESP) x
Status (non-
compliant)
Show status x x
Zeroize (non-
compliant)
Destroy all CSPs x
SSH connect (non-
compliant)
Initiate SSH connection for SSH monitoring and
control (CLI)
x x
IPsec connect (non-
compliant)
Initiate IPsec connection (IKE) x
Console access (non-
compliant)
Console monitoring and control (CLI) x x
Remote reset (non-
compliant)
Software initiated reset x
Page 17 FIPS Policy
Table 19 - Unauthenticated traffic
Service Description
Local reset (non-
compliant)
Hardware reset or power cycle
Traffic (non-
compliant)
Traffic requiring no cryptographic services
5 SELF-TESTS
Each time the module is powered up, it tests that the cryptographic algorithms still operate correctly and that sensitive
data has 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 below. All KATs must be completed successfully prior
to any other use of cryptography by the module. If one of the KATs fails, the module enters the Critical Failure error state.
The module performs the following power-up self-tests:
• Firmware Integrity check using ECDSA P-256 with SHA-256
• Data Plane KATs
o AES-CBC (128/192/256) Encrypt KAT
o AES-CBC (128/192/256) Decrypt KAT
o Triple-DES-CBC Encrypt KAT
o Triple-DES-CBC Decrypt KAT
o HMAC-SHA-1 KAT
o HMAC-SHA-256 KAT
o AES-GCM (128/192/256) Encrypt KAT
o AES-GCM (128/192/256) Decrypt KAT
• Control Plane Authentec KATs
o RSA 2048 w/ SHA-256 Sign KAT
o RSA 2048 w/ SHA-256 Verify KAT
o ECDSA P-256 w/ SHA-256 Sign/Verify PCT
o Triple-DES-CBC Encrypt KAT
o Triple-DES-CBC Decrypt KAT
o HMAC-SHA2-256 KAT
o HMAC-SHA2-384 KAT
o AES-CBC (128/192/256) Encrypt KAT
o AES-CBC (128/192/256) Decrypt KAT
o AES-GCM (128/256) Encrypt KAT
o AES-GCM (128/256) Decrypt KAT
o KDF-IKE-V1 KAT
o KDF-IKE-V2 KAT
• HMAC_DRBG KAT
o SP 800-90A HMAC DRBG KAT
§ Health-tests initialize, re-seed, and generate.
Page 18 FIPS Policy
• OpenSSL KATs
o ECDSA P-256 Sign/Verify PCT
o EC Diffie-Hellman P-256 KAT
§ Derivation of the expected shared secret.
o RSA 2048 w/ SHA-256 Sign KAT
o RSA 2048 w/ SHA-256 Verify KAT
o Triple-DES-CBC Encrypt KAT
o Triple-DES-CBC Decrypt KAT
o HMAC-SHA-1 KAT
o HMAC-SHA2-256 KAT
o HMAC-SHA2-384 KAT
o HMAC-SHA2-512 KAT
o AES-CBC (128/192/256) Encrypt KAT
o AES-CBC (128/192/256) Decrypt KAT
• OpenSSH KAT
o KDF-SSH KAT
• Libmd KATs
o HMAC-SHA2-256 KAT
o SHA-2-512 KAT
• Critical Function Test
o The cryptographic module performs a verification of a limited operational environment.
Upon successful completion of the self-tests, the module outputs “FIPS self-tests completed.” to the local console.
If a self-test fails, the module outputs “<self-test name>: Failed” to the local console and automatically reboots.
The module also performs the following conditional self-tests:
• Continuous RNG Test on the SP 800-90A HMAC-DRBG
• Continuous RNG test on the NDRNG
• Pairwise consistency test when generating ECDSA and RSA key pairs.
• Firmware Load Test (ECDSA P-256 with SHA-256 signature verification)
6 PHYSICAL SECURITY POLICY
The module’s physical embodiment is that of a multi-chip standalone device that meets Level 2 Physical Security
requirements. The module is completely enclosed in a rectangular nickel or clear zinc coated, cold rolled steel, plated steel
and brushed aluminum enclosure. There are no ventilation holes, gaps, slits, cracks, slots, or crevices that would allow for
any sort of observation of any component contained within the cryptographic boundary. Tamper-evident seals allow the
operator to tell if the enclosure has been breached. These seals are not factory-installed and must be applied by the
Cryptographic Officer. (Seals are available for order from Juniper using part number JNPR-FIPS-TAMPER-LBLS.) The
tamper-evident seals shall be installed for the module to operate in a FIPS mode of operation.
The Cryptographic Officer is responsible for securing and having control at all times of any unused seals and the direct
control and observation of any changes to the module, such as reconfigurations where the tamper-evident seals or
Page 19 FIPS Policy
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.
Table 20 – Physical Security Inspection Guidelines
Physical Security Mechanism Recommended Frequency of
Inspection/Test
Inspection/Test Guidance Details
Tamper seals, opaque metal
enclosure.
Once per month by the
Cryptographic Officer.
Seals should be free of any tamper
evidence.
If the Cryptographic Officer observes tamper evidence, it shall be assumed that the device has been compromised. The
Cryptographic Officer shall retain control of the module and perform zeroization of the module's CSPs by following the
steps in Section 2.2 of the Security Policy.
6.1 GENERAL TAMPER SEAL PLACEMENT AND APPLICATION INSTRUCTIONS
For all seal applications, the Cryptographic Officer should observe the following instructions:
• Handle the seals with care. Do not touch the adhesive side.
• Before applying a seal, ensure the location of application is clean, dry, and clear of any residue.
• Place the seal on the module, applying firm pressure across it to ensure adhesion. Allow at least 1 hour for the
adhesive to cure.
Page 20 FIPS Policy
6.2 SRX300 (4 SEALS)
A tamper-evident seal must be applied to the following location:
• The bottom of the chassis, covering the four chassis screws.
Figure 4. SRX300 Tamper-Evident Seal Placement- Four (4) Seals
Page 21 FIPS Policy
6.3 SRX 340/345 (27 SEALS)
Tamper-evident seals must be applied to the following locations:
• The top of the chassis, covering one of the five chassis screws. 1-5. Five seals.
• The I/O Slots. 6-9. Four seals.
• The rare panel, covering the blank faceplate and the SSD. 10-11. Two seals.
• Side panels over the screw holes. Eight on each side 12-27. Sixteen Seals
Total of 27 seals
Figure 5. SRX340/SRX345 Tamper-Evident Seal Placement - Top Cover. Nine (9) Seals
Page 22 FIPS Policy
Figure 6. SRX 340/345 Tamper-Evident Seal Placement - Rare Panel. Two (2) Seals
Figure 7. SRX340/SRX345 Tamper-Evident Seal Placement - Side Panels Over the Screw Holes. Eight on each side (16) Seals
Page 23 FIPS Policy
7 SECURITY RULES AND GUIDANCE
The module design corresponds to the security rules below. The term must in this context specifically refers to a
requirement for correct usage of the module in the Approved mode; all other statements indicate a security rule
implemented by the module.
1. The module clears previous authentications on power cycle.
2. When the module has not been placed in a valid role, the operator does not have access to any cryptographic services.
3. Power up self-tests do not require any operator action.
4. Data output is inhibited during key generation, self-tests, zeroization, and error states.
5. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
6. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
7. The module does not support a maintenance interface or role.
8. The module does not support manual key entry.
9. The module does not output intermediate key values.
10. The module requires two independent internal actions to be performed prior to outputting plaintext CSPs (i.e. SSH
PHK, IKE-PSK, or IKE-Priv via the Configure security service).
11. The cryptographic officer must determine whether firmware being loaded is a legacy use of the firmware load service.
12. The cryptographic officer must retain control of the module while zeroization is in process.
13. The cryptographic officer must configure the module to use IKEv2 when GCM is configured for IKE or IPsec ESP.
14. The cryptographic officer must configure the module to IPsec ESP lifetime-kilobytes to ensure the module does not
encrypt more than 2^32 blocks with a single Triple-DES key when Triple-DES is the encryption-algorithm for IKE and/or
IPsec ESP.
8 REFERENCES AND DEFINITIONS
The following standards are referred to in this Security Policy.
Table 21– References
Abbreviation Full Specification Name
[FIPS140-2] Security Requirements for Cryptographic Modules, May 25, 2001
[SP800-131A] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and
Key Lengths, January 2011
[IG] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation
Program
[133] NIST Special Publication 800-133, Recommendation for Cryptographic Key Generation,
December 2012
[135] National Institute of Standards and Technology, Recommendation for Existing
Application-Specific Key Derivation Functions, Special Publication 800-135rev1,
December 2011.
Page 24 FIPS Policy
Abbreviation Full Specification Name
[186] National Institute of Standards and Technology, Digital Signature Standard (DSS),
Federal Information Processing Standards Publication 186-4, July, 2013.
[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
[38A] National Institute of Standards and Technology, Recommendation for Block Cipher
Modes of Operation, Methods and Techniques, Special Publication 800-38A, December
2001
[38D] National Institute of Standards and Technology, Recommendation for Block Cipher
Modes of Operation: Galois/Counter Mode (GCM) and GMAC, Special Publication 800-
38D, November 2007
[198] National Institute of Standards and Technology, The Keyed-Hash Message
Authentication Code (HMAC), Federal Information Processing Standards Publication 198-
1, July, 2008
[180] National Institute of Standards and Technology, Secure Hash Standard, Federal
Information Processing Standards Publication 180-4, August, 2015
[67] National Institute of Standards and Technology, Recommendation for the Triple Data
Encryption Algorithm (TDEA) Block Cipher, Special Publication 800-67, May 2004
[90A] National Institute of Standards and Technology, Recommendation for Random Number
Generation Using Deterministic Random Bit Generators, Special Publication 800-90A,
June 2015.
Table 22 – Acronyms and Definitions
Acronym Definition
AES Advanced Encryption Standard
DSA Digital Signature Algorithm
EC Diffie-
Hellman
Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EMC Electromagnetic Compatibility
ESP Encapsulating Security Payload
FIPS Federal Information Processing Standard
HMAC Keyed-Hash Message Authentication Code
ICV Integrity Check Value (i.e. Tag)
IKE Internet Key Exchange Protocol
IOC Input/Output Card
IPsec Internet Protocol Security
MD5 Message Digest 5
Page 25 FIPS Policy
Acronym Definition
NPC Network Processing Card
RE Routing Engine
RSA Public-key encryption technology developed by RSA Data Security, Inc.
SHA Secure Hash Algorithms
SPC Services Processing Card
SSH Secure Shell
Triple-
DES
Triple - Data Encryption Standard
Table 23 – Datasheets
Model Title URL
SRX300
SRX340
SRX345
SRX300 Line of
Services
Gateways for the
Branch
http://www.juniper.net/assets/us/en/local/pdf/datasheets/1000550-
en.pdf