Juniper Networks SRX Series Services Gateways

Certificate

Approved Algorithms (21)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks SRX Series Services Gateways
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Soft Error State</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Enc/Dec (SSH)<br/>Show status<br/>Local reset</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>Serial</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C4,C5,C6 clue;
  class I2,I3,I4,I5,I6 infer;
  class R2,R3,R4,R5,R6 risk;
  class E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Juniper Networks SRX Series Services Gateways
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Soft Error State</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Enc/Dec (SSH)<br/>Show status<br/>Local reset</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>Serial</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>kernel<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Juniper Networks, Inc Juniper Networks SRX Series Services Gateways Version: Junos OS 22.2R3-S1 Prepared for: Juniper Networks, Inc.

www.juniper.net TERON LABS Prepared by: www.teronlabs.com Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

This is a non-proprietary Cryptographic Module Security Policy for the Juniper Networks SRX Series Services Gateways consisting of the SRX1500, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600 and SRX5800 models and running Junos OS 22.2R3-S1, hereafter referred to as the

The cryptographic module meets requirements applicable to Level 2 of FIPS 140-3. The table below shows the security levels claimed for each section of the security requirements. N/A N/A N/A Table 1: Security Levels Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Purpose and Use: The 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. Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: This Security Policy covers the following models:

• SRX1500, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, and SRX5800. All models run Juniper’s JUNOS firmware. The JUNOS firmware is FIPS-compliant when configured in the Approved mode called JUNOS-FIPS-MODE, version 22.2R3-S1. The firmware images used in the different models are as follows:
• SRX1500: junos-srxentedge-x86-64-22.2R3-S1.9.tgz; SRX4100 and SRX4200: junos-srxmr-x86-64-22.2R3-S1.9.tgz; SRX4600: junos-srxhe-x86-64-22.2R3-S1.9.tgz; and SRX5400, SRX5600 and SRX5800: junos-vmhost-install-srx-x86-64-22.2R3-S1.9.tgz. The physical form of the module is depicted in Figure 1 to Figure 14 below. The cryptographic boundary encompasses the entire Tested Operational Environment Physical Perimeter (TOEPP), which is defined as the outer edge of the chassis. The module does not rely on external devices for input and output of security sensitive parameters (SSPs). Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 1

• SRX1500 (front) Figure 2
• SRX1500 (rear) Figure 3
• SRX4100 (front) Figure 4
• SRX4100 (rear) Figure 5
• SRX4200 (front) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 6

• SRX4200 (rear) Figure 7
• SRX4600 (front) Figure 8
• SRX4600 (rear) Figure 9
• SRX5400 (front) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 10

• SRX5400 (rear) Figure 11
• SRX5600 (front) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 12

• SRX5600 (rear) Figure 13
• SRX5800 (front) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Tested Module Identification

• Hardware: Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 2: Tested Module Identification

• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A The module is not classified as software, firmware, or hybrid; thus, this section is not applicable. Tested Module Identification
• Hybrid Disjoint Hardware: N/A The module is not classified as hybrid disjoint hardware; thus, this section is not applicable. Tested Operational Environments - Software, Firmware, Hybrid: N/A The module is not classified as software, firmware, or hybrid; thus, this section is not applicable. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A There are no vendor-affirmed operational environments claimed. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

No components are excluded from the requirements of FIPS 140-3. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Modes List and Description: JUNOS-FIPSMODE Table 3: Modes List and Description Once the module has been securely initialized following the instructions provided in Section 11.1, the module is in approved mode of operation. Failure to follow the secure initialization instructions results in the module being in a non-compliant state which is out of scope of the validation.

Approved Algorithms: Although the module may have been tested for additional algorithms or modes, only those listed below are utilized by the module. OpenSSL Approved Cryptographic Functions Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 4: Approved Algorithms - OpenSSL Approved Cryptographic Functions Kernel Approved Cryptographic Functions HMAC-SHA2256 Table 5: Approved Algorithms - Kernel Approved Cryptographic Functions LibMD Approved Cryptographic Functions HMAC-SHA2256 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 6: Approved Algorithms - LibMD Approved Cryptographic Functions OpenSSH Approved Cryptographic Functions Table 7: Approved Algorithms - OpenSSH Approved Cryptographic Functions Vendor-Affirmed Algorithms: Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

The module implements the security functions listed in the following table. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

AsymKeyPairKeyGen AsymKeyPairKeyVer Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

AsymKeyPairKeyGen AsymKeyPairKeyGen AsymKeyPairKeyVer Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 9: Security Function Implementations

The module includes RSA and ECDSA algorithms that have been validated using FIPS 186-4 CAVP tests, which are mathematically identical to FIPS 186-5 CAVP tests. Per IG C.K, all RSA and ECDSA algorithms implemented by the module are claimed compliant with FIPS 186-5. The module complies with IG C.F. RSA Key Generation, Signature Generation and Signature Verification have been tested and validated using CAVP testing for all implemented modulus lengths (2048, 3072 and 4096 bits). The number of Miller-Rabin tests used for primality testing as part of RSA Key Generation is consistent with Table C.3. The module implements the following Approved key agreement methods which have been CAVP tested and validated:

• KAS-ECC per SP 800-56A Rev. 3 (FIPS 140-3 IG D.F Scenario 2, path 2). The module obtains the FIPS 140-3 IG D.F required key agreement assurances in accordance with Section 5.6.2 of SP800-56A Rev. 3. All the key agreement protocols implemented by the module are Diffie-Hellman based. The module includes approved KDF algorithms for the SSH protocols. No parts of these protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 10: Entropy Certificates N/A for this module. Non-Proprietary FIPS 140-3 Security Policy

The entropy source is used to seed the module’s HMAC DRBG with the minimum required 256bits of entropy. Each 512-bit block of conditioned output from the entropy source contains 448 bits of entropy. The HMAC DRBG is used for all random data required by the module, including key generation. There are no initialization procedures required by the users of the module to operate the entropy source in a compliant manner. The module complies to the ESV Public Use document of the validated entropy source (Cert. E56).

The cryptographic module implements the key generation methods listed above in the Security Functions implementation table.

The cryptographic module implements the key establishment methods listed above in the Security Functions implementation table.

The cryptographic module supports the protocols listed below. No part of these protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. The SSH algorithms allow independent selection of key exchange, authentication, cipher, and integrity. In reference to the supported protocols table below, each column of options for a given protocol is independent and may be used in any viable combination. Juniper Networks ECDSA P256 HMAC-SHA2256 HMAC-SHA2512 Non-Proprietary FIPS 140-3 Security Policy

The following table maps each physical interface to one or more logical interface types defined in the FIPS 140-3 standard. Table 11: Ports and Interfaces Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 12: Authentication Methods The module enforces the separation of roles using either password-based authentication or

Table 13: Roles The module supports two roles: Cryptographic Officer (CO) and User. The module supports rolebased operator authentication for assuming these roles, using methods specified in Section 4.1. The module supports concurrent operators but does not support a maintenance role and/or bypass capability. connection. As root or super-user, the Cryptographic Officer has permission to view and edit secrets within the module. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The User role monitors the router via the console or SSH. The user role cannot change the

G,R,W Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Z Juniper Networks Non-Proprietary FIPS 140-3 Security Policy G,E G,E G,E G,E

E Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

algorithm selftests Table 14: Approved Services

The module includes a firmware load service to support necessary updates. Only the CO can install the new image using the CLI as described in Section 11.1. The loaded firmware is a complete image replacement and constitutes an entirely new module and version of Junos OS which would require a separate FIPS 140-3 validation. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The cryptographic module implements an approved firmware integrity self-test that uses ECDSA P-256 with SHA2-256 to ensure the integrity of all Junos OS firmware components. The selftest is automatically run on power-up. It can also be run on demand by the module’s operator by power cycling the module. When the integrity check fails, the module enters an error state (kernel panic) which can only be exited by power-cycling the module.

The self-test is automatically run on power-up. It can also be run on demand by the module’s operator by power cycling the module. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Type of Operational Environment: Non-Modifiable How Requirements are Satisfied: The module consists of hardware containing a non-modifiable operational environment as per the FIPS 140-3 definitions. It includes a firmware load service to support necessary updates. The loaded firmware is a complete image replacement and constitutes an entirely new module and version of Junos OS which would require a separate FIPS 140-3 validation.

There are no security rules, settings, or restrictions to the configuration of the operational environment beyond the initialization instructions to set the module in approved mode. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

n/a n/a Table 15: Mechanisms and Actions Required 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 approved mode. 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 an approved mode of operation. 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 9.3 and then follow the steps in Section 11.1 to place the module back into approved mode of operation.

The number of seals that need to be applied depends on the module model, as follows:

• SRX1500: 10 seals SRX4100 and SRX 4200: 13 seals SRX4600: 15 seals SRX5400: 20 seals SRX5600: 19 seals Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

• SRX5800: 42 seals Placement: SRX1500 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). Figure 15 - 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 16 - SRX1500 Rear View: TEL 7 & 8 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 17 - SRX1500 Top - Rear View: TEL 7 Figure 18 - SRX1500 Bottom View: TEL 8, 9 & 10

• TEL #9 and TEL #10 cover the indicated screw on the left and right side of the SRX1500 (Figure 19 and Figure 20) and wrap to the bottom of the SRX1500 as shown in Figure 8. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 19 - SRX1500 Right Side View: TEL 9 Figure 20 - SRX1500 Left Side View: TEL 10 SRX4100 & SRX4200 The placement of the tamper evident labels for the SRX4100 and SRX4200 are the same in that the outside of the devices is identical. Thirteen 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 topback 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. Figure 21 - SRX4100 & SRX4200 Top View: TEL 1, 2, 6, 8 & 10 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 22 - SRX4100 & SRX4200 Left-Side View: TEL 1 Figure 23 - 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. Figure 24 - 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. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 25 - SRX4100 & SRX4200 Front View: TEL 6-11

• The rear of the SRX4100 & SRX4200 require 2 tamper evident labels (TEL #12 and #13) as shown in Figure 26. Each label is applied on the power supply plate and wraps around the bottom. Figure 26 - SRX4100 & SRX4200 Rear View: TEL 12-13 SRX4600 Fifteen tamper evident labels (TEL) must be applied to the following location:
• The front of the SRX4600 has 4 HA ports, 1 USB port, and 2 Solid State Drives (SSDs) that must be protected with 8 tamper evident labels. Referring to Figure 27 and Figure 28, the front panel requires 4 tamper evident labels (#1 - #4) cover the HA ports, 2 tamper evident labels cover the USB port and top screw (#5, #6), 1 tamper evident label (#7) to cover the first SSD, and 1 tamper evident label (#8) to cover the second SSD. Figure 27 - SRX4600 Front View: TEL 1
• 8 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 28 - SRX4600 Top Front View: TEL 1, 3, 5, 7, 8

• The rear of the SRX4600 requires 7 tamper evident labels (TEL #9 -#15) as shown in Figure

29 TEL #9 and TEL #10 wrap over the top and cover the back plate of each power supply

and the adjacent chassis edge. Each of TEL#11 to TEL #15 = wraps over the top and attaches to a fan cover. Figure 29 - SRX4600 Rear View: TEL 9-15 Figure 30 - SRX4600 Top Rear View: TEL 9

• 10
• The right and left sides have 1 TEL each (TEL 11 and 12) over the 4th screw from the front and wrapping around to the bottom. Figures 6 & 7 show the placement of the side TELs. Figure 31 - SRX4600 Right Side View: TEL 12 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 32 - SRX4600 Left Side View: TEL 11

• The bottom view (Figure 8) shows the TELs wrapping around from the front and sides of the SRX4600. Figure 33 - SRX4600 Bottom View: TEL 2, 4, 11, 12 SRX5400 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Tamper-evident seals shall be applied to the following locations:

• Front Pane (10 seals, TEL 1-10). Two seals (2), Vertical Covering the screws on the information panel at the top of the device. Seven (7) seals, vertical, connection each expansion plane to its neighbors and the top and button plane to the chassis. One (1) seal, vertical covering the USB port.
• Back Pane (8 seals TEL 11-18) Four (4) seals, vertical: one on each of the top four sub-panes, extending to the large chassis plate below. Two (2) seals, vertical: on the horizontal screwed-in plate resting on the large central chassis. Placed over screws. Two (2) seals, horizontal: placed on the low side sub-panes, extending to the large central chassis area and wrapping around to the neighbouring side panes. Figure 34 - SRX5400 Front View: TEL 1-10 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 35 - SRX5400 Rear View: TEL 11-18 SRX5600 Tamper-evident seals must be applied to the following locations:

• Front Pane (11 seals, TEL 1-11) Nine (9) seals, vertical: one for each horizontal sub-pane (excluding the honeycomb plate on the top and the thin sub-pane a little below). The seals should attach to vertically adjacent subpanes. The extra on the bottom attaches to the lowermost sub-pane and wraps around attaching to the bottom pane. It should be ensured that one of the seals spans across the thin plate with ample extra distance on each side. Two (2) seals, horizontal attach to the uppermost sub-pane and wraps around attaching to the side panels of the chassis.
• USB Port (1 seal, TEL 12) One (1) Seal, Vertical Covering the front USB port.
• Back Pane (7 seals, TEL 13-18) Four (4) seals, vertical: one on each of the upper four sub-panes, attaching to the large plate below. Two (2) seals, horizontal: one on each of the vertical side sub-panes, extending to side the panes. One (1) Seal, Horizontal: connecting the small access pane on the lower right of the chassis to the main panel. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 36 - SRX5600 Front View: TEL 1-11 Figure 37 - SRX5600 Rear View: TEL 12-20 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 38 - SRX5600 USB Port: TEL 21 SRX5800 Tamper-evident seals shall be applied to the following locations:

• Front Panel (36 seals: TEL 1-36) Thirty (30) seals, horizontal: two on each of the long vertical sub-panes, extending to the neighboring two. If on an end sub-pane, seal should wrap around to the side. Three (3) seals, vertical: One over each of the thin panes
• two near the bottom, one near the top of the lower half. Two (2) seals, vertical: both on the console area at the top of the module, one extending to the top and the other extending to the chassis area below. One (1) Seal, Diagonal covering the front USB port.
• Back Pane (6 seals: TEL 37-42) Five (5) seals, horizontal: Three spanning the gaps between the vertical sub-panels, and then two more, one each on the far edges of the left and right panels. (These last two should wrap around to the sides.) Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

One (1) Seal, Vertical: At the top of the case connecting the DC system pane to the mesh fan cover. Figure 39 - SRX5800 Front View: TEL 1-36 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 40 - SRX5800 Rear View: TEL 37-41 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Figure 41 - SRX5800 Rear View: TEL 37,39,40-42 Surface Preparation: 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. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Operator Responsible for Securing Unused Seals: The Cryptographic Officer is responsible for securing and having control at all times of any unused seals. Part Numbers: Tamper seals have part number JNPR-FIPS-TAMPER-LBLS. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

This section is not applicable, as there are currently no approved non-invasive mitigation techniques specified in ISO/IEC 19790:2012 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The table below lists the areas within the module’s cryptographic boundary where SSPs can be stored. Table 16: Storage Areas

The table below lists the method used by the module for the input and output of SSPs. Table 17: SSP Input-Output Methods

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 18: SSP Zeroization Methods The CO can run the following commands to zeroize the approved mode SSPs:

• For the SRX1500, SRX4100, SRX4200 and SRX4600 models: user@host> request system zeroize hypervisor
• For the SRX5400, SRX5600 and SRX5800 models: user@host> request vmhost zeroize firmware image. After zeroizing the system, the module is no longer in a FIPS compliant state. Installation and configuration as per section 11.1 is required to enter the FIPS compliant state and enable the Approved mode of operation. The Cryptographic Officer must retain control of the module while zeroization is in process. Zeroization commands, as described above, and power cycling are initiated by the operator. The module automatically zeroizes all SSPs when no longer required by calling explicit delete commands. Session termination is initiated by the operator or by environmental errors. The completion of zeroization is indicated implicitly. If the zeroization is initiated using a zeroization command or explicit delete command, completion of the command indicates that zeroization has successfully completed. If the zeroization is initiated by power cycling the module, then successful reboot of the module indicates that zeroization has completed successfully. In the case of zeroization initiated by session termination, SSPs are zeroized when the session terminates, and session termination is indicated in the log. All SSPs used by the module are described in this section Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

SSH-DHSharedSecret SSH-DHpriv n/a - n/a n/a - n/a Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

PackageCA SSH-DHPUB Table 19: SSP Table 1 Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

SSH-DHSharedSecret SSH-DHpriv Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The following transitions apply to algorithms used by this module: SHA-1: The SHA-1 hash algorithm will be non-Approved for all cryptographic purposes after December 31, 2030. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

On power up or reset, the module performs the pre-operational self-tests and the indicated conditional cryptographic algorithm self-tests described below. All KATs must be completed successfully prior to any other use of cryptography by the module. The algorithms utilized in the

Table 21: Pre-Operational Self-Tests

Source (startup) n/a n/a Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

n/a Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

n/a n/a n/a n/a n/a n/a n/a n/a Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

n/a Table 22: Conditional Self-Tests

Table 23: Pre-Operational Periodic Information Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Table 24: Conditional Periodic Information

Table 25: Error States Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module enters Critical Failure State upon failure of any pre-operational self-tests or CAST, causing the kernel to ‘panic‘ and all execution to halt. The only way to exit from this state is to reboot the module, which causes the self-tests to be repeated and pass successfully before the corresponding algorithms are usable.

Self–tests that are performed at power-up are available on demand by power cycling the module. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Before installation of module firmware, CO must first zeroize any module SSPs by following the instructions in Section 9.3. Once zeroization is complete, the CO must install the JUNOS firmware image on the device using the following CLI command: CO@host> request system software add /<image-path>/<image-filename> no-copy no-validate reboot. The image-filenames for the validated firmware are as follows: • • • • SRX1500: junos-srxentedge-x86-64-22.2R3-S1.9.tgz; SRX4100 and SRX4200: junos-srxmr-x86-64-22.2R3-S1.9.tgz; SRX4600: junos-srxhe-x86-64-22.2R3-S1.9.tgz; and SRX5400, SRX5600 and SRX5800: junos-vmhost-install-srx-x86-64-22.2R3-S1.9.tgz. Once the image is installed, the CO shall follow the instructions in Section 7.2 to apply the tamper seals to the module. Next, the CO shall proceed as follows:

1. Enable the approved mode on the device. CO@host> set system fips level 2
2. Set the root password. user@host# set system root-authentication plain-text-password New password: <type password here>
3. Commit and reboot the device. CO@host# commit Once the module is rebooted and the integrity and self-tests have run successfully on initial power-on in, the module is operating in the approved mode of operation. The CO must create a backup image of the firmware to ensure it is also a approved mode Junos OS image by issuing the request system snapshot command. The show version command will display the version of the Junos OS on the device so that the CO can confirm it is the FIPS validated version. The CO should also verify the presence of the suffix string “:fips” in the cli prompt, indicating the module is operating in approved mode. IPsec, High Availability and TLS features are not enabled by default and must not be enabled for FIPS compliant usage of the module. . Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The Cryptographic Officer is the person responsible for enabling, configuring, monitoring, and maintaining the module in approved mode. The Cryptographic Officer securely installs Junos OS on the device, enables the approved of operation, establishes keys and passwords for other users and software modules, and initializes the device before network connection. The Cryptographic Officer can configure and monitor the module through a console or SSH connection.

No specific non-administrator guidance is required to operate the module.

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. 2. 3.

4. The module clears previous authentications on power cycle. Power up self-tests do not require any operator action. Data output is inhibited during key generation, self-tests, zeroization, and error states. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
5. There are no restrictions on which SSPs are zeroized by the zeroization service.
6. The module does not support a maintenance interface or role.
7. The module does not output intermediate key values.
8. The module requires two independent internal actions to be performed prior to outputting plaintext CSPs.
9. The cryptographic officer must determine whether firmware being loaded is a legacy use of the firmware load service.
10. The cryptographic officer must retain control of the module while zeroization is in process.
11. IPsec, High Availability and TLS features must not be enabled.

No special maintenance requirements apply.

When disposing of the cryptographic module, the CO shall perform the zeroize command described in Section 9.3. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

The module does not implement mechanisms to mitigate other attacks beyond what is described in this security policy. Juniper Networks Non-Proprietary FIPS 140-3 Security Policy

Referenced URLs

• www.juniper.net
• www.teronlabs.com