Juniper Networks vSRX 3.0 Virtual Firewall

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 vSRX 3.0 Virtual Firewall
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>CASTs on boot<br/>Show status<br/>Show status (LED)</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>SSH<br/>IKEV<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["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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?"]
    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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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"]
    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
  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,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Juniper Networks vSRX 3.0 Virtual Firewall
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>CASTs on boot<br/>Show status<br/>Show status (LED)</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>SSH<br/>IKEV<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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Juniper Networks, Inc. Juniper Networks vSRX 3.0 Virtual Firewall Document Version 1.0

Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Juniper Networks shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. This non-proprietary Cryptographic Module Security Policy for the Juniper Networks vSRX 3.0 Virtual Firewall provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. It contains specification of the security rules under which the cryptographic module operates. The module will be running in approved mode of operation, when it is executing the Junos OS 22.2R2-S2.3 software version. The Juniper Networks vSRX 3.0 Virtual Firewall may also be referred to as the “module” in this document.

Purpose and Use: The Juniper Networks vSRX 3.0 Virtual Firewall cryptographic module is comprised of the Junos OS 22.2R2-S2.3 software. The Juniper Networks vSRX 3.0 Virtual Firewall is a secure firewall that provides 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: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module is depicted in Figure 1 below. The physical perimeter is defined as the outer edge of the hardware platform (server) on which the hypervisor and Juniper Networks vSRX 3.0 Virtual Firewall are installed. The cryptographic boundary is the Juniper vSRX 3.0 Virtual Firewall which is comprised of the Junos OS 22.2R2-S2.3 software. Tested Operational Environment’s Physical Perimeter (TOEPP): The Tested Operational Environment’s Physical Perimeter (TOEPP) is the hardware platform on which it executes. Document Version 1.0

Figure 1

• Block Diagram Document Version 1.0

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): N/A Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: No vendor-affirmed operational environments have been claimed.

No components have been excluded from the cryptographic boundary of the module.

Modes List and Description: Document Version 1.0

NonApproved NonApproved Table 4: Modes List and Description and the non-Approved mode of operation and vice versa. When switching from the nonApproved to the Approved mode, post zeroisation, the instructions in Section 11.1 Enabling the The module does not support a degraded mode of operation. Document Version 1.0

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: N/A Table 6: Vendor-Affirmed Algorithms Document Version 1.0

The module does not support any non-Approved algorithms in the Approved mode, i.e., it does Operation, all Approved algorithms supported in the Approved mode of operation are also Document Version 1.0

AsymKeyPairKeyGen AsymKeyPairKeyGen AsymKeyPairKeyVer AsymKeyPairKeyGen () () () Document Version 1.0

() Table 9: Security Function Implementations Document Version 1.0

The module only supports testable RSA moduli/key sizes (2048, 3072 and 4096 bits) and thus the requirements per FIPS 140-3 IG C.F do not apply.

Table 10: Entropy Certificates NonPhysical NonPhysical Table 11: Entropy Sources

The module implements an approved NIST SP 800-90Ar1 DRBG and supports the following sections per NIST SP 800-133r2 (CKG): Sections 4, 5.1, 5.2 and 6.2.1.

Per IG D.F: The module implements full KAS (KAS-ECC-SSC, KAS-FFC-SSC per NIST SP 800-56Ar3 and KDF SSH/IKEv1/IKEv2 per NIST SP 800-135r1; IG D.F Scenario 2 (path 2 option 2, separate testing of the SSC and SP800-135r1 KDF). The KAS1, KAS2, KAS3 and KAS4 in the Security Functions Implementations Table 9 have been documented in accordance with this requirement: KAS1: KAS (KAS-ECC-SSC Cert. #A3342 and CVL Cert. #A3341; SSP establishment methodology provides between 128 and 256 bits of encryption strength) KAS2: KAS (KAS-FFC-SSC Cert.#A3342 and CVL Cert. #A3341; SSP establishment methodology provides 112 bits of encryption strength) Document Version 1.0

KAS3: KAS (KAS-FFC-SSC Cert.#A3342 and CVL Cert. #A3343; SSP establishment methodology provides 112 bits of encryption strength) KAS4: KAS (KAS-ECC-SSC Cert. #A3342 and CVL Cert. #A3343; SSP establishment methodology provides between 128 and 256 bits of encryption strength) The Approved Algorithm list includes the tested components (KAS-ECC-SSC, KAS-FFC-SSC, KDF SSH, KDF IKEv1 and KDF IKEv2) as individual entries. Per IG D.G: The module supports the IETF SSH and IPsec protocols and thus implements key transport in the context of the protocols (per the KTS1 and KTS2 entries in the Security Functions Implementations Table 9). The module implements the approved KTS using approved AES modes:

• KTS1: KTS (AES Cert. #A3342 and HMAC Cert. #A3342; key establishment methodology provides between 128 and 256 bits of encryption strength corresponding to the key lengths between 128 to 256 bits), used in the context of the IETF SSH protocol.
• KTS2: KTS (AES Certs. #A3339, #A3343 and HMAC Certs. #A3339, #A3343; SSP establishment methodology provides between 128 and 256 bits of encryption strength), used in the context of the IETF IKEv1/IKEv2 protocol

No parts of the SSH and IPsec protocols, other than the KDF SSH and the KDF IKEv1/KDF IKEv2 for IPsec, have been tested by the CAVP or CMVP.

N/A N/A N/A N/A Table 12: Ports and Interfaces The module does not support control output. Document Version 1.0

1/ Table 13: Authentication Methods The module enforces the separation of roles using role-based operator authentication. The module implements two forms of identity-based authentication, username, and password over Document Version 1.0

the console and SSH connections, as well as username and an ECDSA or RSA public keybased authentication over SSHv2.

Table 14: Roles correspond to the User role. The module supports concurrent operators but does not support a maintenance role and/or bypass capability. An operator assuming the Crypto Officer role configures and monitors the module via a console or SSH connection. As Root or Super-user, the Crypto Officer has permission to view and configure passwords and public keys within the module. The User role monitors the module via the console or SSH. The User role does not have the permission to modify the configuration. Document Version 1.0

(nonsecurity Nonsecurity n s s E W W Document Version 1.0

s s Z A: Z Z Z Z - IKE-DHPUB: Z Document Version 1.0

n) s s Z Z - IKE-DHPUB: Z G,E,Z G,E,Z E G,E,Z G,E,Z Document Version 1.0

N/A n) ipsec securityassociation saname; * set securityassociation saname) s s E E E E E E W,E G,E,Z G,E,Z G,E,Z G,E,Z - IKE-DHPUB: G,R,E,Z W,E G,E,Z G,E,Z G,E,Z Document Version 1.0

s s G,E,Z - IKE-DHPUB: G,R,E,Z Table 15: Approved Services SigVer, noncompliant) HMACRIPEMD160 SigVer, noncompliant) HMACRIPEMD160 Table 16: Non-Approved Services Document Version 1.0

The module does not support software loading from an external source.

The module supports self-initiated cryptographic output in the context of the IPsec protocol and three independent configurations are required serving as three independent internal actions (two actions required at minimum):

• set security ipsec security-association sa-name set security ike security-association sa-name The following “show” commands indicate the status of the Ipsec service:
• show security ike security-associations
• show security ipsec security-associations
• show security ipsec statistics

The module performs the software integrity check using ECDSA P-256 with SHA2-256 (CAVP Cert. #A3342). The ECDSA P-256 public key used for signature verification is a non-SSP and stored persistently across reboots in the module’s Non-Volatile RAM (NVRAM) until zeroisation of the module.

The operator can initiate the integrity test on demand by rebooting the module.

The module software image is delivered in the form of a pre-compiled tarball (.ova).

Type of Operational Environment: Modifiable How Requirements are Satisfied: Document Version 1.0

The module contains a modifiable operational environment since the underlying hardware platform supports uncontrollable modifications to itself. The module contains the operating system Junos OS 22.2R2-S2.3.

Security rules and restrictions for configuration of the operational environment have been specified in Sections 11.1 and 11.4 of this document.

The requirements per this section do not apply since the module is of type software.

The module does not implement any non-invasive security mitigations and thus the requirements per this section do not apply to the module.

Table 18: SSP Input-Output Methods The module is complaint with FIPS 140-3 IG 9.5.A MD/DE and AD/EE for SSPs entered via the module’s CLI via a direct connection to its serial/console port and for SSPs entered/output/established via SSH/IPsec respectively.

Table 19: SSP Zeroization Methods Document Version 1.0

EC DiffieHellman DiffieHellman KASECCSSC P256, P384, P512 - 128 Document Version 1.0

G G DiffieHellman DiffieHellman G G G Document Version 1.0

A P-256, P384, P521 for P-256, P384, P521 for Document Version 1.0

EC DiffieHellman DiffieHellman KASECCSSC P256, P384, P512 - 128 KASECCSSC Document Version 1.0

HMAC (SHA256) HMAC (SHA256) DiffieHellman EC DiffieHellman DiffieHellman DiffieHellman KASECCSSC P256, P384, P512 - 128 KASECCSSC IKE DiffieHellman IKE DiffieHellman Table 20: SSP Table 1 Document Version 1.0

n n n d d n Powercycle Powercycle Powercycle powercycle Powercycle Document Version 1.0

powercycle powercycle powercycle n n Powercycle Powercycle Powercycle Powercycle Powercycle Powercycle Document Version 1.0

e e n n e A n n Powercycle Powercycle Powercycle Document Version 1.0

n n n n n n Powercycle Powercycle Powercycle Powercycle Powercycle Table 21: SSP Table 2

Per the NIST SP 800-133Ar2/3 and the programmatic transitions defined by the CMVP, the following algorithm transitions apply to the module, and the algorithms have been designated allowed/non-approved accordingly in Section 2.5: Document Version 1.0

a. Usage of SHA-1 for SigVer is allowed for legacy use only until 2030. Thereafter, all usage of SHA-1 will be considered a non-approved, not allowed algorithm. b. Until January 1, 2031, the following algorithms will be considered deprecated: a. Hash function and HMAC using SHA-1 hash function b. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Generation c. As of January 1, 2031, the following algorithms will be considered deprecated/disallowed (i.e. non-approved, not allowed)/legacy use: a. Use of the 112-bit security strength for classical digital signature and keyestablishment mechanisms (deprecated) b. Use of the 112-bit security strength for block ciphers (disallowed) c. Use of a security strength less than 128-bits but greater than 112 bits for ECDA KeyGen and RSA KeyGen (PKCS #1 v1.5 & PSS) (deprecated) d. HMAC using SHA-1 hash function (legacy use) e. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Generation (disallowed) f. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Verification (legacy use)

Table 22: Pre-Operational Self-Tests The module is complaint with FIPS 140-3 IG 10.2.A in that it performs a self-test, a Known integrity test on each boot prior to executing the software integrity test.

HMACSHA2256 Length: 0256 s HMACSHA2256 AESCBC AESCBC AESCBC AESCBC AESCBC N/A AESCBC AESCBC AESCBC AESCBC AESCBC Document Version 1.0

AESCBC s HMACSHA-1 N/A HMACSHA2256 N/A HMACSHA2512 N/A KASECCSSC Sp80056Ar3 Methods: P256 N/A KASECCSSC Sp80056Ar3 Methods: P384 N/A KASFFCSSC AESCBC HMACSHA-1 HMACSHA2256 HMACSHA2512 KASECCEPHEMUNIFIED KASECCEPHEMUNIFIED KASFFCEPHEMN/A Document Version 1.0

Sp80056Ar3 Cipher: AES128, AES192, AES256 ; Hash 6-5) 6-5) 6-5) SHA2512 6-5) KDFSSHSHA2256 RSASIGN RSAVERIFY ECDSASIGN ECDSAVERIFY SHA-2512 s N/A N/A Document Version 1.0

6-5) s KASFFCSSC Sp80056Ar3 6-5) N/A and IKEPSK Document Version 1.0

s N/A N/A AESCBC AESCBC HMACSHA2256 N/A AESCBC AESCBC HMACSHA2256 AESCBC AESCBC HMACSHA2256 AESCBC AESCBC HMACSHA2256 N/A Document Version 1.0

s Table 23: Conditional Self-Tests Cryptographic Algorithm Self-tests (CASTs) are performed on each boot of the module. Other conditional self-tests are performed by the module when the corresponding condition is met. The pairwise consistency tests are performed on key pair generation for use in signature generation/verification (ECDSA and/or RSA tests) and/or for use in KAS-ECC-SSC or KASFFC-SSC SSP agreement (ECDSA and DSA tests respectively). The software load test is performed when a software image (.tgz) is loaded onto the module from an external source.

Table 24: Pre-Operational Periodic Information Document Version 1.0

Table 25: Conditional Periodic Information The pre-operational software integrity test as well as all CASTs must be completed successfully prior to any other use of cryptography by the module in the Approved mode of operation. These tests can also be performed periodically by rebooting the module.

N/A Table 26: Error States generated keypair/loaded image, returns an error indicator and resumes normal operation.

Each time the module is powered up it tests that all the cryptographic algorithms operate correctly, and that sensitive data have not been damaged. Pre-operational as well as Conditional Cryptographic Algorithm Self-tests (CAST) are performed on each power up/boot of the module and on demand by power cycling the module (Perform self-tests (remote reset) service).

The module is in the non-compliant state by default. The Crypto Officer (CO) shall follow the instructions in this section to download, install and initialize the module onto the host platforms identified in Table

2. Next, the module must be configured in Approved mode, as described below, and rebooted. Once the module is rebooted and the integrity and self-tests have run successfully on initial boot, the module is operational in the Approved mode. The Crypto Officer must follow the procedures defined below for secure installation, initialization, startup and operation of the module. Downloading the Image The Crypto Officer must check to verify the image being loaded on the module is the FIPS 1403 validated version/image. If the image is the FIPS 140-3 validated image, then proceed with installation of the image. Guide to Download Software Packages for vSRX 3.0 from Juniper Networks:
3. Using a Web browser, follow the link to the download URL on the Juniper Networks webpage at https://www.juniper.net/support/downloads/?p=vsrx#sw
4. Log in to the Juniper Networks website using the username (generally your e-mail address) and password supplied by your Juniper Networks representatives.
5. Under “Version” dropped down list, select the appropriate certified Release (Example: 22.2R2-S2.3).
6. Under “Application Media” section, select the appropriate software package for the target release version and hypervisor.
7. Download Junos OS to a local host or to an internal software distribution site.
8. MD5 checksum and SHA1 checksum can be found under “Checksum” o Verify the checksum of the download with the provided checksum The crypto-officer shall follow the instructions for installation provided in the Juniper Networks documentation: For installing the vSRX 3.0 using a .tgz file, the instructions can be found in the Junos® OS FIPS Evaluated Configuration Guide for vSRX 3.0 Instance. The CLI command from the aforementioned document to install Junos OS is repeated below: >request system software add /<image-path>/<junos package>no-copy no-validate reboot Where the <junos package> is the .tgz file for e.g. junos-install-vsrx3-x86-64-22.2R2.tgz. For installing the vSRX 3.0 using an .ova file, the instructions can be found in the vSRX Guide for VMware. The steps from the aforementioned document are repeated below:
9. Enter the vCenter server hostname or address in your browser (https://<ipaddress>:9443) to access the vSphere WebClient, and login to the vCenter server with your credentials.
10. Select a host or other valid parent for a virtual machine and click Actions>All vCenter Actions>Deploy OVF Template.
11. Click Browse to locate the vSRX 3.0 software package, and then click Next.
12. Click Next in the OVF Template Details window.
13. Click Accept in the End User License Agreement window, and then click Next.
14. Change the default vSRX 3.0 VM name in the Name box and click Next. It is advisable to keep this name the same as the hostname you intend to give to the VM.
15. In the Datastore window, do not change the default settings for: • Datastore • Available Space Document Version 1.0

8. Select a datastore to store the configuration file and virtual disk files in OVF template, and then click Next.
9. Select your management network from the list, and then click Next. The management network is assigned to the first network adapter, which is reserved for the management interface (fxp0).
10. Click Finish to complete the installation.
11. Open the Edit Settings page of the vSRX 3.0 VM and select a virtual switch for each network adapter. Three network adapters are created by default. Network adapter 1 is for the management network (fxp0). To add a fourth adapter, select Network from New device list at the bottom of the page.
12. Enable promiscuous mode for the management virtual switch:
13. Select the host where the vSRX 3.0 VM is installed and select Manage>Networking >Virtual switches.
14. In the list of virtual switches, select vSwitch0 to view the topology diagram for the management network connected to network adapter 1.
15. Click the Edit icon at the top of the list, select Security, and select Accept next to Promiscuous mode. Click OK. Once the FIPS 140-3 validated vSRX 3.0 software is installed on the hardware platform and hypervisor in Table 3 then the crypto-officer shall follow the instructions below to place the module in the Approved mode of operation. Enabling the Approved Mode of Operation: The CO shall enable the module for Approved mode of operation by performing the following steps.
16. Set up the password for root authentication: root@host> set system root-authentication plaintext-password Enter password: Re-enter password: root@host> commit commit complete
17. Enable the Approved mode: root@host> set system fips level 2 *
18. Commit. root@host> commit
19. Restart the virtual machine from the hypervisor console.
20. Verify that the module is operational in the Approved mode in the correct version (Junos OS 22.2R2-S2.3) by using the “show version” command. The command prompt should contain the string “fips” denoting that the Approved mode has been successfully configured. Document Version 1.0

*Note: This module is a FIPS 140-3 Security Level 1 module but the command “set system fips level 2” must be used to invoke the Approved mode of operation. Please note this is Juniper terminology only. The module claims to meet FIPS 140-3/ISO 19790 Security Level

1. Then, the CO must run the following commands to configure the SSHv2 protocol:
2. Edit system services ssh and set root-login allow [edit system services] root@host# set ssh root-login allow
3. Assign an IP address to the fxp0 interface and set the routing options [edit] root@host# set interfaces fxp0 unit <unit> family inet address <ip address> root@host# set routing-options static route 0.0.0.0/0 next-hop <gateway> The “show configuration security ike” and “show configuration security ipsec” commands display the approved and configured IKE/IPsec configuration for the module. Zeroisation The vSRX 3.0 instance can be deleted from the datastore of the VMware ESXi 7.0 hypervisor as the method of zeroisation. The cryptographic officer must retain control of the module while zeroisation is in process.

For further information and for the Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for vSRX, Release 22.2R2 document.

For further information and for the non-Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for vSRX, Release 22.2R2 document.

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. Pre-operational self-test 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. Document Version 1.0

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 does not output plaintext CSPs.
11. The cryptographic officer must retain control of the module while zeroisation is in process.
12. Entropy Source: The Juniper Networks vSRX 3.0 Virtual Firewall (running Junos OS 22.2R2-S2.3) cryptographic module is a software module with an entropy gathering non-physical entropy source inside of the module's physical perimeter per IG 9.3.A Scenario
13. (b) (ESV cert.#E56 applies to the module). The module generates sufficient entropy for the generation of SSPs (using the approved DRBG of the module) with the maximum target security strength (256 bits) needed. As can be verified from the Public Use Document and Security Policy Section 2.8, Entropy Sources Table 11, the entropy source generates a minimum of 448 bits of overall entropy per 512-bit output sample/

6.4 per 8-bit sample (entropy input to the DRBG). The DRBG is seeded with 512 bits.

No other maintenance requirements apply for operation of the module in the Approved/nonApproved modes as defined above.

The module can be securely sanitized at the end of its lifetime by zeroising it.

The module does not implement any mitigation of other attacks and thus the requirements per this section do not apply to the module. Document Version 1.0

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-validation-program
• https://www.juniper.net/support/downloads/?p=vsrx#sw