Copyright Juniper, 2017 Version 1.3 Page 1 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Juniper Networks SRX1500, SRX4100 and SRX4200 Services
Gateways
Non-Proprietary FIPS 140-2 Cryptographic Module Security
Policy
Version: 1.3
Date: February 21, 2018
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408.745.2000
1.888 JUNIPER
www.juniper.net
Copyright Juniper, 2017 Version 1.3 Page 2 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Table of Contents
1 Introduction ..................................................................................................................5
1.1 Hardware and Physical Cryptographic Boundary.........................................................................7
1.2 Mode of Operation.......................................................................................................................8
1.3 Zeroization..................................................................................................................................10
2 Cryptographic Functionality......................................................................................... 11
2.1 Approved Algorithms .................................................................................................................11
2.2 Allowed Algorithms....................................................................................................................13
2.3 Allowed Protocols ......................................................................................................................14
2.4 Disallowed Algorithms................................................................................................................15
2.5 Critical Security Parameters.......................................................................................................15
3 Roles, Authentication and Services .............................................................................. 17
3.1 Roles and Authentication of Operators to Roles .......................................................................17
3.2 Authentication Methods............................................................................................................17
3.3 Services.......................................................................................................................................17
3.4 Non-Approved Services..............................................................................................................19
4 Self-tests ..................................................................................................................... 20
5 Physical Security Policy................................................................................................ 22
5.1 General Tamper Evident Label Placement and Application Instructions...................................22
5.2 SRX1500 (10 seals) .....................................................................................................................22
5.3 SRX4100 & SRX4200 (11 seals)...................................................................................................25
6 Security Rules and Guidance ........................................................................................ 28
7 References and Definitions .......................................................................................... 29
Copyright Juniper, 2017 Version 1.3 Page 3 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
List of Tables
Table 1 – Cryptographic Module Configurations..........................................................................................5
Table 2 – Security Level of Security Requirements.......................................................................................6
Table 3 – Ports and Interfaces ......................................................................................................................8
Table 4 – Data Plane Approved Cryptographic Functions ..........................................................................11
Table 5 – Control Plane QuickSec Approved Cryptographic Functions ......................................................11
Table 6 – OpenSSL Approved Cryptographic Functions..............................................................................12
Table 7 – OpenSSH Approved Cryptographic Functions.............................................................................13
Table 8 – LibMD Approved Cryptographic Functions .................................................................................13
Table 9 – Allowed Cryptographic Functions ...............................................................................................13
Table 10 – Protocols Allowed in FIPS Mode................................................................................................14
Table 11 – Critical Security Parameters (CSPs) ...........................................................................................15
Table 12 – Public Keys.................................................................................................................................16
Table 13 – Authenticated Services..............................................................................................................17
Table 14 – Unauthenticated traffic.............................................................................................................18
Table 15 – CSP Access Rights within Services .............................................................................................18
Table 16 – Authenticated Services..............................................................................................................19
Table 17 – Unauthenticated traffic.............................................................................................................19
Table 18 – Physical Security Inspection Guidelines ....................................................................................22
Table 19 – References.................................................................................................................................29
Table 20 – Acronyms and Definitions .........................................................................................................29
Table 21 – Datasheets.................................................................................................................................30
List of Figures
Figure 1 - SRX1500 ........................................................................................................................................7
Figure 2 - SRX4100 ........................................................................................................................................7
Figure 3 - SRX4200 ........................................................................................................................................7
Figure 4 - SRX1500 Front View: TEL 1 - 6 ....................................................................................................23
Figure 5 - SRX1500 Top-Front View: TEL 1 & 2 ...........................................................................................23
Figure 6 - SRX1500 Rear View: TEL 7 & 8....................................................................................................23
Figure 7 - SRX1500 Top - Rear View: TEL 7 .................................................................................................24
Figure 8 - SRX1500 Bottom View: TEL 8, 9 & 10 .........................................................................................24
Figure 9 - SRX1500 Right Side View: TEL 9..................................................................................................25
Figure 10 - SRX1500 Left Side View: TEL 10................................................................................................25
Figure 11 - SRX4100 & SRX4200 Top View: TEL 1 & 2.................................................................................26
Figure 12 - SRX4100 & SRX4200 Left-Side View: TEL 1...............................................................................26
Copyright Juniper, 2017 Version 1.3 Page 4 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 13 - SRX4100 & SRX4200 Right-Side View: TEL 2.............................................................................26
Figure 14 - SRX4100 & SRX4200 Bottom View: TEL 3, 4, 5 .........................................................................27
Figure 15 - SRX4100 & SRX4200 Front View: TEL 6-11 ...............................................................................27
Copyright Juniper, 2017 Version 1.3 Page 5 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
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. The JUNOS firmware is FIPS-compliant, when
configured in FIPS-MODE called JUNOS-FIPS-MODE, version 15.1X49-D100. The firmware image is junos-
srxentedge-15.1X49-D100.6-domestic.tgz for the SRX1500 and junos-srxmr-15.1X49-D100.6-
domestic.tgz for the SRX 4100/4200 and the firmware status service identifies itself as in the “Junos
15.1X49-D100.6”.
This Security Policy covers the following “Mid-Size Enterprise and Data Center” models – the SRX1500,
SRX4100, and SRX4200 models. They are meant for Mid-Size Enterprise and Data Center.
The cryptographic modules are defined as multiple-chip standalone modules that execute JUNOS-FIPS
firmware on any of the Juniper Networks SRX-Series gateways listed in the table below.
Table 1 – Cryptographic Module Configurations
Model Hardware Versions Firmware Distinguishing Features
SRX1500
SRX1500 SYS-JB-AC
SRX1500 SYS-JB-DC
JUNOS
15.1X49-D100
12x1GbE ports; 4x1GbE SFP ports;
4x10GbE SFP ports+; 2 PIM slots (not used
in validation)
SRX4100
SRX4100 SYS-JB-AC
SRX4100 SYS-JB-DC
JUNOS
15.1X49-D100
8 x 1GbE/10GbE ports
SRX4200
SRX4200 SYS-JB-AC
SRX4200 SYS-JB-DC
JUNOS
15.1X49-D100
8 x 1GbE/10GbE ports
All JNPR-FIPS-TAMPER-LBLS N/A Tamper-Evident Seals
Each Hardware Version for a model is identical in physical form factor, materials, and assembly
methods. The Hardware Version differences for a model are considered non-security relevant. The
differences denoted by the various suffixes are described below:
• AC – Alternating current power
• DC – Direct current power
• JB – Junos Base licensing
Copyright Juniper, 2017 Version 1.3 Page 6 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
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 2
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
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.
Copyright Juniper, 2017 Version 1.3 Page 7 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
1.1 Hardware and Physical Cryptographic Boundary
The physical forms of the module’s various models are depicted in Figures 1-3 below. For all models, the
cryptographic boundary is defined as the outer edge of the chassis. The modules do not rely on external
devices for input and output.
Figure 1 - SRX1500
Figure 2 - SRX4100
Figure 3 - SRX4200
Copyright Juniper, 2017 Version 1.3 Page 8 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Table 3 – Ports and Interfaces
Port Device (# of ports) Description Logical Interface Type
Ethernet
SRX1500 (21: 1 Management,
12 10/100/1000 Base-T, 4
SFP, 4 SFP+),
SRX4100 (9: 1 Management, 8
SFP+),
SRX4200 (9: 1 Management, 8
SFP+)
LAN Communications
Control in, Data in, Data out, Status
out
Serial
SRX1500 (1), SRX4100 (1),
SRX4200 (1)
Console serial port Control in, Status out
USB
SRX1500 (1) Console mini-USB
port
Control in, Status out
Power
SRX1500 (1), SRX4100 (1),
SRX4200 (1)
Power connector Power
Reset
SRX1500 (1), SRX4100 (1),
SRX4200 (1)
Reset Control in
LED
SRX1500 (6), SRX4100 (3),
SRX4200 (3)
Status indicator
lighting
Status out
HA
SRX1500 (1), SRX4100 (2),
SRX4200 (2)
SFP+ Transceivers
Tamper Evident Label –
Inaccessible
USB
SRX1500 (1), SRX4100 (2),
SRX4200 (2)
Firmware load
port/Storage device
Tamper Evident Label –
Inaccessible
1.2 Mode of Operation
The Crypto-Officer (CO) shall follow the instructions in Section 5 to apply the tamper seals to the module.
Once the tamper seals have been applied as shown in this document, the JUNOS firmware image must be
installed on the device. Next, the module is configured in FIPS-MODE and rebooted. Once the module is
rebooted and the integrity and self-tests have run successfully on initial power-on in FIPS-MODE, the
module is operating in the FIPS-Approved mode. The Crypto-Officer (CO) must ensure that the backup
image of the firmware is also a JUNOS-FIPS-MODE image by issuing the request system snapshot
command.
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.3
The CO shall enable the module in FIPS mode or operation by performing the following steps.
1. Enable the FIPS mode on the device.
user@host> set system fips level 2
2. Commit and reboot the device.
user@host> commit
Then, the CO must run the following commands to configure SSH to use FIPS approved and FIPS allowed
algorithms:
Copyright Juniper, 2017 Version 1.3 Page 9 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
1. Specify the permissible SSH host-key algorithms for the system services.
[edit system services]
root@host# set ssh hostkey-algorithm ssh-ecdsa
2. Specify the SSH key-exchange for Diffie-Hellman keys for the system services.
[edit system services]
root@host#set ssh key-exchange ecdh-sha2-nistp256
3. Specify all the permissible message authentication code algorithms for SSHv2.
[edit system services]
root@host#set ssh macs hmac-sha1
4. Specify the ciphers allowed for protocol version 2.
[edit system services]
root@host#set ssh ciphers aes128-cbc
When AES GCM is configured as the encryption-algorithm for IKE or IPsec, the CO must configure the
module to use IKEv2 by running the following commands:
IKE:
root@host# set security ike proposal <ike_proposal_name> encryption-algorithm aes-256-gcm
IPSec:
root@host# set security ipsec proposal <ipsec_proposal_name> encryption-algorithm aes-128-gcm
root@host# set security ike gateway <gateway_name> version v2-only
root@host# commit
commit complete
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>”
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.
The “show version” command will indicate if the module is operating in FIPS mode (e.g. JUNOS Software
Release [15.1X49-D100]) along with “fips” prompt.
The “show configuration security ike” and “show configuration security ipsec” commands display the
approved and configured IKE/IPsec configuration for the device operating in FIPS-approved mode.
Copyright Juniper, 2017 Version 1.3 Page 10 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
1.3 Zeroization
The cryptographic module provides a non-Approved mode of operation in which non-approved
cryptographic algorithms are supported. When transitioning between the non-Approved mode of
operation and the Approved mode of operation, the Cryptographic Officer must run the following
commands to zeroize the Approved mode CSPs:
user@host> request system zeroize hypervisor
This command wipes clean all the CSPs/configs as well as the disk. Currently the device will have to be
reimaged to bring back the device, as all the disk partitions are securely erased.
Use of the zeroize command is restricted to the Cryptographic Officer. The cryptographic officer shall
perform zeroization in the following situations:
1. Before FIPS Operation: To prepare the device for operation as a FIPS cryptographic module by
erasing all CSPs and other user-created data on a device before its operation as a FIPS
cryptographic module.
2. Before non-FIPS Operation: To conduct erasure of all CSPs and other user-created data on a
device in preparation for repurposing the device for non-FIPS operation.
Note: The Cryptographic Officer must retain control of the module while zeroization is in process.
Copyright Juniper, 2017 Version 1.3 Page 11 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
2 Cryptographic Functionality
The module implements the FIPS Approved and Non-Approved but Allowed cryptographic functions listed
in Tables 4, 5, 6, 7, 8 and 9 below.
Allowed Protocols
Table 10 summarizes the high-level protocol algorithm support.
2.1 Approved Algorithms
References to standards are given in square bracket [ ]; see the References table.
Table 4 – Data Plane Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
47211
4722
AES [197]
CBC [38A] Key Sizes: 128, 192, 256 Encrypt, Decrypt
GCM [38D] Key Sizes: 128, 192, 256 Encrypt, Decrypt, AEAD
3138
3139
HMAC [198]
SHA-1 Key size: 160 bits, λ = 96
Message Authentication
SHA-256 Key size: 256 bits, λ = 128
3866
3867
SHS [180]
SHA-1
SHA-256
Message Digest Generation
2503
2504
Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
Table 5 – Control Plane QuickSec Approved Cryptographic Functions
Cert Algorithm Mode Description Functions
4632
4711
AES [197]
CBC [38A] Key Sizes: 128, 192, 256 Encrypt, Decrypt
GCM [38D] Key Sizes: 128, 256 Encrypt, Decrypt, AEAD
N/A2
CKG
[133] Section 6.2
Asymmetric key generation using
unmodified DRBG output
[133] Section 7.3 Derivation of symmetric keys
1291
1355
CVL
IKEv1 [135] SHA 256, 384
Key Derivation
IKEv2 [135] SHA 256, 384
1560
1603
DRBG [90A] HMAC SHA-256 Random Bit Generation
1
AES CTR was validated; however, it is not used by any service.
2
Vendor Affirmed.
Copyright Juniper, 2017 Version 1.3 Page 12 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
1141
1164
ECDSA [186]
P-256 (SHA 256)
P-384 (SHA 384)
KeyGen, SigGen, SigVer
3067
3129
HMAC [198]
SHA-256
Key size: 256 bits,
λ = 128, 256 Message Authentication, KDF
Primitive
SHA-384
Key size: 384 bits,
λ = 192, 384
N/A KTS
AES Cert. #4632, #4711 and HMAC Cert.
#3067, #3129
key establishment methodology
provides between 128 and 256 bits
of encryption strength
Triple-DES Cert. #2464, #2497 and
HMAC Cert. #3067, #3129
key establishment methodology
provides 112 bits of encryption
strength
2529
2567
RSA [186] PKCS1_V1_5
n=2048 (SHA 256)
n=4096 (SHA 256)
SigGen, SigVer3
3798
3857
SHS [180]
SHA-256
SHA-384
Message Digest Generation
2464
2497
Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
Table 6 – OpenSSL Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
4710
4631
AES [197]
CBC [38A]
CTR [38A]
Key Sizes: 128, 192, 256 Encrypt, Decrypt
1602
1559
DRBG [90A] HMAC SHA-256 Random Bit Generation
N/A4
CKG
[133] Section 6.1
[133] Section 6.2
Asymmetric key generation using
unmodified DRBG output
1163
1140
ECDSA [186]
P-256 (SHA 256)
P-384 (SHA 384)
SigGen, KeyGen, SigVer
3128
3066
HMAC [198]
SHA-1 Key size: 160 bits, λ = 160
Message Authentication
SHA-3845
N/A
SHA-512 Key size: 512 bits, λ = 512
SHA-256 Key size: 256, λ = 256
Message Authentication
DRBG Primitive
3
RSA 4096 SigVer was not tested by the CAVP; however, it is Approved for use per CMVP guidance,
because RSA 2048 SigVer was tested and testing for RSA 4096 SigVer is not available.
4
Vendor Affirmed.
5
HMAC-SHA384 was validated; however, it is not used by any service.
Copyright Juniper, 2017 Version 1.3 Page 13 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
N/A KTS
AES Cert. #4710, #4631 and HMAC Cert.
#3128, #3066
key establishment methodology
provides between 128 and 256 bits
of encryption strength
Triple-DES Cert. #2496, #2463 and
HMAC Cert. #3128, #3066
key establishment methodology
provides 112 bits of encryption
strength
2566
25286 RSA [186]
n=2048 (SHA 256)
n=4096 (SHA 256)
KeyGen7
, SigGen, SigVer8
3856
3795
SHS [180]
SHA-1
SHA-256
SHA-384
Message Digest Generation,
KDF Primitive
SHA-512 Message Digest Generation
2496
2463
Triple-DES [67] TCBC [38A] Key Size: 192 Encrypt, Decrypt
Table 7 – OpenSSH Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
N/A9
CKG [133] Section 7.3 Derivation of symmetric keys
1292
129310 CVL SSH [135] SHA 1, 256, 384 Key Derivation
Table 8 – LibMD Approved Cryptographic Functions
CAVP
Cert. Algorithm Mode Description Functions
3796
3797
SHS [180]
SHA-256
SHA-512
Message Digest Generation
2.2 Allowed Algorithms
Table 9 – Allowed Cryptographic Functions
Algorithm Caveat Use
6
RSA 3072 KeyGen was validated; however, it is not used by any service.
7
RSA 4096 KeyGen was not tested by the CAVP; however, it is Approved for use per CMVP guidance,
because RSA 2048 KeyGen was tested and testing for RSA 4096 KeyGen is not available.
8
RSA 4096 SigVer was not tested by the CAVP; however, it is Approved for use per CMVP guidance,
because RSA 2048 SigVer was tested and testing for RSA 4096 SigVer is not available.
9
Vendor Affirmed.
10
SHA-512 was validated for CVL; however, it is not used by the SSH service.
Copyright Juniper, 2017 Version 1.3 Page 14 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
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 [IG] 7.14
Scenario 1a
The module generates a minimum of 256
bits of entropy for key generation.
Seeding the DRBG
2.3 Allowed Protocols
Table 10 – Protocols Allowed in FIPS Mode
Protocol Key Exchange Auth Cipher Integrity
IKEv1
Diffie-Hellman (L = 2048, N = 224, 256)
EC Diffie-Hellman P-256, P-384
RSA 2048
RSA 4096
Pre-Shared
Secret
ECDSA P-256
ECDSA P-384
Triple-DES CBC
AES CBC
128/192/256
HMAC-SHA-
1-96
HMAC-SHA-
256-128
HMAC-SHA-
384-192
IKEv211 Diffie-Hellman (L = 2048, N = 224, 256)
EC Diffie-Hellman P-256, P-384
RSA 2048
RSA 4096
Pre-Shared
Secret
ECDSA P-256
ECDSA P-384
Triple-DES CBC
AES CBC
128/192/256
AES GCM12
128/256
HMAC-SHA-
1-96
HMAC-SHA-
256-128
HMAC-SHA-
384-192
IPsec ESP
IKEv1 with optional:
• Diffie-Hellman (L = 2048, N = 224,
256)
• EC Diffie-Hellman P-256, P-384
IKEv1
3 Key Triple-DES CBC
AES CBC
128/192/256 HMAC-SHA-
1-96
HMAC-SHA-
256-128
IKEv2 with optional:
• Diffie-Hellman (L = 2048, N = 224),
(2048, 256)
• EC Diffie-Hellman P-256, P-384
IKEv2
3 Key Triple-DES CBC
AES CBC
128/192/256
AES GCM13
128/192/256
SSHv2
Diffie-Hellman (L = 2048, N = 256)
EC Diffie-Hellman P-256, P-384 ECDSA P-256
Triple-DES CBC
AES CBC
128/192/256
AES CTR
128/192/256
HMAC-SHA-
1-96
HMAC-SHA-
1
HMAC-SHA-
256
HMAC-SHA-
512
11
IKEv2 generates the SKEYSEED according to RFC7296
12
The AES GCM IV is generated according to RFC5282
13
The AES GCM IV is generated according to RFC4106
Copyright Juniper, 2017 Version 1.3 Page 15 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
No part of these protocols, other than the KDF, have been tested by the CAVP and CMVP. The IKE and SSH
algorithms allow independent selection of key exchange, authentication, cipher and integrity. In reference
to the Allowed Protocols in Table 10 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.
2.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
2.5 Critical Security Parameters
All CSPs and public keys used by the module are described in this section.
Table 11 – Critical Security Parameters (CSPs)
Name Description and usage
DRBG_Seed Seed material used to seed or reseed the DRBG
DRBG_State V and Key values for the HMAC_DRBG
Entropy Input
String
256 bits entropy (min) input used to instantiate the DRBG
SSH PHK
SSH Private host key. 1st
time SSH is configured, the keys are generated. ECDSA P-256.
Used to identify the host.
SSH DH
SSH Diffie-Hellman private component. Ephemeral Diffie-Hellman private key used in SSH.
DH (N = 256 bit14
), ECDH P-256, or ECDH P-384
SSH-SEKs
SSH Session Keys: SSH Session Encryption Key: TDES (3key) or AES; SSH Session Integrity
Key: HMAC
ESP-SEKs
IPSec ESP Session Keys: IKE Session Encryption Key: TDES (3key) or AES; IKE Session
Integrity Key: HMAC
IKE-PSK Pre-Shared Key used to authenticate IKE connections.
IKE-Priv IKE Private Key. RSA 2048, RSA 4096 ECDSA P-256, or ECDSA P-384
IKE-SKEYID IKE SKEYID. IKE secret used to derive IKE and IPsec ESP session keys.
IKE-SEKs
IKE Session Keys: IKE Session Encryption Key: TDES (3key) or AES; IKE Session Integrity Key:
HMAC
IKE-DH-PRI
IKE Diffie-Hellman private component. Ephemeral Diffie-Hellman private key used in IKE.
DH N = 224 bit, ECDH P-256, or ECDH P-384
14
SSH generates a Diffie-Hellman private key that is 2x the bit length of the longest symmetric or MAC key
negotiated.
Copyright Juniper, 2017 Version 1.3 Page 16 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
CO-PW ASCII Text used to authenticate the CO.
User-PW ASCII Text used to authenticate the User.
Table 12 – Public Keys
Name Description and usage
SSH-PUB SSH Public Host Key used to identify the host. ECDSA P-256.
SSH-DH-PUB
Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in SSH key
establishment. DH (L = 2048 bit), ECDH P-256, or ECDH P-384
IKE-PUB IKE Public Key. RSA 2048, RSA 4096, ECDSA P-256, or ECDSA P-384
IKE-DH-PUB
Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in IKE key
establishment. DH L = 2048 bit, ECDH P-256, or ECDH P-384
Auth-UPub
User Authentication Public Keys. Used to authenticate users to the module. ECDSA P256 or P-
384
Auth-COPub CO Authentication Public Keys. Used to authenticate CO to the module. ECDSA P256 or P-384
Root-CA
JuniperRootCA. ECDSA P-256 or P-384 X.509 Certificate; Used to verify the validity of the
Juniper Package-CA at software load.
Package-CA
PackageCA. ECDSA P-256 X.509 Certificate; Used to verify the validity of Juniper Images at
software load and also at runtime integrity.
Copyright Juniper, 2017 Version 1.3 Page 17 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
3 Roles, Authentication and Services
3.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.
3.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 (576 attempts per
hour/60 mins); 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 5.6e7 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 5.6e7/(2128
).
3.3 Services
All services implemented by the module are listed in the tables below. Table 15 lists the access to CSPs by
each service.
Table 13 – 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
Copyright Juniper, 2017 Version 1.3 Page 18 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
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 14 – Unauthenticated traffic
Service Description
Local reset Hardware reset or power cycle
Traffic Traffic requiring no cryptographic services
Table 15 – CSP Access Rights within Services
Service
CSPs
DRBG_Seed
DRBG_State
Entropy
Input
String
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 Z Z Z -- -- -- Z Z
SSH
connect
-- E -- E GE GE -- -- -- -- -- --
E E
IPsec
connect
-- E -- -- -- -- G E E GE G GE
-- --
Console
access
-- -- -- -- -- -- -- -- -- -- -- --
E E
Remote
reset
GEZ GZ GZ -- Z Z Z -- -- Z Z Z Z Z
Local reset GEZ GZ 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 updated or written to the module
Z = Zeroize: The module zeroizes the CSP.
Copyright Juniper, 2017 Version 1.3 Page 19 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
3.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) and IPSec Connect (non-compliant). SSH Connect (non-compliant) supports
the security functions identified in Section 2.4 and the SSHv2 row of Table 10. The IPsec (non-compliant)
supports the DSA in Section 2.4 and the IKEv1, IKEv2 and IPSec rows of Table 10.
Table 16 – 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
Table 17 – Unauthenticated traffic
Service Description
Local reset (non-
compliant)
Hardware reset or power cycle
Traffic (non-
compliant)
Traffic requiring no cryptographic services
Copyright Juniper, 2017 Version 1.3 Page 20 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
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 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 QuickSec KATs
o SP 800-90A HMAC DRBG KAT
▪ Health-tests initialize, re-seed, and generate
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-SHA-256 KAT
o HMAC-SHA-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
• OpenSSL KATs
o SP 800-90A HMAC DRBG KAT
▪ Health-tests initialize, re-seed, and generate.
o ECDSA P-256 Sign/Verify PCT
o ECDH 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
Copyright Juniper, 2017 Version 1.3 Page 21 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
o HMAC-SHA-1 KAT
o HMAC-SHA-256 KAT
o HMAC-SHA-384 KAT
o HMAC-SHA-512 KAT
o AES-CBC (128/192/256) Encrypt KAT
o AES-CBC (128/192/256) Decrypt KAT
• OpenSSH KATs
o KDF-SSH KAT
• LibMD KATs
o SHA-256
o SHA-512
• Critical Function Test
o The cryptographic module performs a verification of a limited operational environment,
and verification of optional non-critical packages.
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 signature verification)
Copyright Juniper, 2017 Version 1.3 Page 22 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
5 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 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 18 – 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 1.3 of the Security Policy and then follow the steps in
Section 1.2 to place the module back into a FIPS-Approved mode of operation.
5.1 General Tamper Evident Label 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.
5.2 SRX1500 (10 seals)
Six tamper evident labels (TEL) must be applied to the following location:
• The front of the SRX1500 has two slot covers. The slot covers should be secured with two screws
each and then tamper evident labels (TEL #1 & #2) applied as shown by the red boxes in following
two figures. The TEL go from the front of the SRX1500 to the top (Figures 4 & 5).
• 2 Tamper labels (#5 & #6) are used to cover the USB port and two tamper labels (#3 & #4) are
used to cover the High Availability port (Figure 4).
Copyright Juniper, 2017 Version 1.3 Page 23 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 4 - SRX1500 Front View: TEL 1 - 6
• The rear of the SRX1500 has two TELs (TEL #7 and TEL #8). The TEL #7, at the top of the rear-view
wraps to the top of the device and covers the fourth screw from side containing the power supply
(see Figure 7). TEL #8 wraps from the rear of the SRX1500, on the SSD slot cover, to the bottom of
the SRX1500 (see Figure 8).
Figure 6 - SRX1500 Rear View: TEL 7 & 8
Figure 5 - SRX1500 Top-Front View: TEL 1 & 2
1 2
Copyright Juniper, 2017 Version 1.3 Page 24 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 7 - SRX1500 Top - Rear View: TEL 7
Figure 8 - SRX1500 Bottom View: TEL 8, 9 & 10
7
Copyright Juniper, 2017 Version 1.3 Page 25 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
• TEL #9 and TEL #10 cover the indicated screw on the left and right side of the SRX1500 (Figure 9
and Figure 10) and wrap to the bottom of the SRX1500 as shown in Figure 8.
Figure 9 - SRX1500 Right Side View: TEL 9
Figure 10 - SRX1500 Left Side View: TEL 10
5.3 SRX4100 & SRX4200 (11 seals)
The placement of the tamper evident labels for the SRX4100 and SRX4200 are exactly the same in that
the outside of the devices is identical. Eleven tamper-evident seals must be applied to the following
locations:
• The top of the chassis, covering one screw on the top-back left and one screw on the top-back
right (TEL #1 and TEL #2). The TELs cover the screws on the top of the chassis and wrap down each
side of the chassis.
Copyright Juniper, 2017 Version 1.3 Page 26 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 11 - SRX4100 & SRX4200 Top View: TEL 1, 2, 6, 8 & 10
Figure 12 - SRX4100 & SRX4200 Left-Side View: TEL 1
Figure 13 - SRX4100 & SRX4200 Right-Side View: TEL 2
• Bottom chassis, covering 3 screws that secure the faceplates on the front of the chassis. TEL #3,
#4, #5 are entirely on the bottom of the chassis they do not wrap around to any other portion of
the chassis
Copyright Juniper, 2017 Version 1.3 Page 27 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Figure 14 - SRX4100 & SRX4200 Bottom View: TEL 3, 4, 5
• Tamper evident seals 6 & 7 cover the two USB ports on the front of the SRX4100 and the SRX4200
• Two tamper evident labels cover each HA port. Tamper evident labels #8 & #9 cover one HA port
and tamper evident labels #10 & #11 cover the second HA port.
Figure 15 - SRX4100 & SRX4200 Front View: TEL 6-11
Copyright Juniper, 2017 Version 1.3 Page 28 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
6 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.
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. If the module loses power and then it is restored, then a new key shall be established for use with the
AES GCM encryption/decryption processes.
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.
Copyright Juniper, 2017 Version 1.3 Page 29 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
7 References and Definitions
The following standards are referred to in this Security Policy.
Table 19 – 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
[135] National Institute of Standards and Technology, Recommendation for Existing
Application-Specific Key Derivation Functions, Special Publication 800-135rev1,
December 2011.
[186] National Institute of Standards and Technology, Digital Signature Standard (DSS),
Federal Information Processing Standards Publication 186-4, July, 2013.
[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 20 – Acronyms and Definitions
Acronym Definition
AEAD Authenticated Encryption with Associated Data
AES Advanced Encryption Standard
DH Diffie-Hellman
Copyright Juniper, 2017 Version 1.3 Page 30 of 30
Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).
Acronym Definition
DSA Digital Signature Algorithm
ECDH 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
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 21 – Datasheets
Model Title URL
SRX1500 SRX1500 Services
Gateway
https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000551-
en.pdf
SRX4100
SRX4200
SRX4100 and
SRX4200 Services
Gateways
http://www.juniper.net/assets/de/de/local/pdf/datasheets/1000600-
en.pdf