Juniper Networks QFX10002, QFX10008 and QFX10016

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Juniper Networks QFX10002, QFX10008 and QFX10016
  %% 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>firmware load<br/>upgrade<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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 QFX10002, QFX10008 and QFX10016
  %% 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>firmware load<br/>upgrade<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Show status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>SSH<br/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>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,C5,C6 clueLow;

Security Policy, page by page

Juniper Networks, Inc. Juniper Networks QFX10002, QFX10008 and QFX10016

Introduction 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. About this Document This non-proprietary Cryptographic Module Security Policy for the Juniper Networks QFX10002, QFX10008 and QFX10016 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. 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 document describes the cryptographic module security policy for the Juniper Networks QFX10002, QFX10008, QFX10016 (Hardware versions: QFX10002-36Q, QFX10002-60C, QFX10002-72Q, QFX10008 and QFX10016) cryptographic module (also referred to as the “module” hereafter) with firmware version Junos OS 22.3R1-S2.3. The module has a multi-chip standalone embodiment. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard.

The module claims an overall Security Level of 1 with all individual sections at a Security Level

1 with the exceptions of Roles, Services and Authentication (claimed at Security Level 3). The

module does not implement any non-invasive security mitigations or mitigations of other attacks and thus the requirements per these sections are inapplicable.

Purpose and Use: The cryptographic module provides for an encrypted connection, using SSH, between the management station and itself, i.e., the QFX switch. Module Type: Hardware Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic module’s operational environment is a limited operational environment. The cryptographic boundary of the hardware module is the entirety of the module/chassis (demarked with a black outline in the figures below). This includes the Routing Engine (RE). No components have been excluded from the cryptographic boundary of the module. Tested Operational Environment’s Physical Perimeter (TOEPP): The Tested Operational Environment’s Physical Perimeter (TOEPP) is the entirety of the module chassis.

Figure 1: Front view of QFX10002-36Q, QFX10002-72Q and QFX10002-60C Figure 2: Rear view for QFX10002-36Q Figure 3: Rear view of QFX10002-72Q

Figure 4: Rear view of QFX10002-60C Figure 5: Front view of QFX10008 Figure 6: Rear view of QFX10008

Figure 7: Front view of QFX100016 Figure 8: Rear view image QFX100016

Figure 9 – High-level Block Diagram for QFX10002/QFX10008/QFX10016

Tested Module Identification – Hardware:

Table 2: Tested Module Identification – Hardware

No components have been excluded from the cryptographic boundary of the module. Modes List and Description: Table 3: Modes List and Description

The hardware versions contained in Table 2, with Junos OS 22.3R1-S2.3 installed, contain one Approved mode of operation and a non-Approved mode of operation. The Junos OS 22.3R1S2.3 firmware image must first be installed on the module. The module is configured during initialization by the Crypto Officer to operate in the Approved mode or the non-Approved mode. When operated in the non-Approved mode of operation, the module supports non-Approved algorithms as well as the algorithms supported in the Approved mode of operation. The module is in a non-compliant state by default and the Crypto Officer can place the module into the nonApproved mode of operation by following the instructions in Section 11 Life-Cyle Assurance in this document. Mode Change Instructions and Status: The module must always be zeroised when switching between the Approved mode of operation and the non-Approved mode of operation and vice versa. Degraded Mode Description: The module does not support a degraded mode of operation.

Approved Algorithms: Kernel Table 4: Approved Algorithms - Kernel LibMD Table 5: Approved Algorithms - LibMD OpenSSL

Table 6: Approved Algorithms - OpenSSL Table 7: Approved Algorithms The following protocol is supported by the module in the Approved mode: SSHv2 (EC Diffie-Hellman P-256, P-384, P-521; Diffie-Hellman MODP2048; RSA 2048, 3072

4096 bits; ECDSA P-256, P-384, P-521; AES CBC 128, 192, 256 bits; AES CTR 128, 192, 256

bits, HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-512) The SSH protocol allows independent selection of key exchange, authentication, cipher and integrity algorithms. Please note that there are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in the table above are used by an approved service of the module. Vendor-Affirmed Algorithms: 6.2.1 Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The module does not support any non-Approved algorithms in the Approved mode, i.e., it does not support Non-Approved Algorithms Allowed in the Approved Mode of Operation.

The module does not support any non-Approved algorithms in the Approved mode, i.e., it does Table 10: Non-Approved, Not Allowed Algorithms Operation, all Approved algorithms supported in the Approved mode of operation are also

Table 11: Security Function Implementations

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 12: Entropy Certificates Table 13: Entropy Sources

The module implements two NIST SP 800-90Ar1 DRBGs 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 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 and KAS2 in the SFI Table have been documented in accordance with this requirement. KAS1: KAS (KAS-ECC-SSC Cert.#A3349 and CVL Cert. #A3349; SSP establishment methodology provides between 128 and 256 bits of encryption strength) KAS2: KAS (KAS-FFC-SSC Cert.#A3349 and CVL Cert. #A3349; SSP establishment methodology provides 112 bits of encryption strength) The Approved Algorithm list includes the tested components (KAS-ECC-SSC, KAS-FFC-SSC and KDF SSH) as individual entries. Per IG D.G: The module supports the IETF SSH protocol and thus implements key transport in the context of the protocol (per the KTS1 entry in the SFI table of the Security Policy). The module implements the following approved KTS using approved AES modes: AES CBC and CTR: KTS (AES Cert. #A3349 and HMAC Cert. #A3349; key establishment methodology provides between 128 and 256 bits of encryption strength)

No parts of the SSH protocol, other than the KDF, have been tested by the CAVP or CMVP.

The module design corresponds to the security rules below. The term shall 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. Self-tests do not require any operator action.
4. Data output is inhibited during SSP generation, self-test execution, zeroisation, and error states.
5. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the module.
6. There are no restrictions on which SSPs are zeroised by the zeroisation service.

7. The module does not support a maintenance interface or role.
8. The module does not output intermediate key values.
9. The module does not output plaintext CSPs.
10. The Crypto officer shall verify that the firmware image to be loaded on the module is a FIPS 140-3 validated image. If any non-validated firmware image is loaded the module will no longer be a validated module.
11. The Crypto Officer shall retain control of the module while zeroisation is in process.

Table 14: Ports and Interfaces The module does not support control output.

Table 15: Authentication Methods The module enforces the separation of roles using identity-based operator authentication. The module implements two forms of identity-based authentication, username, and password over

based authentication over SSHv2.

Table 16: 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.

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access - HMAC_DRBG seed: Z - ECDH Shared Secret: Z - DH Shared Secret: Z - HMAC Key: Z - SSH Public Host Key: Z - User Authentication Public Keys: Z - CO Authentication Public Keys: Z - JuniperRootC A: Z - PackageCA: Z - SSH ECDH Public Key: Z - SSH DH Public Key: Z - SSH ECDH Client Public Key: Z - SSH DH Client Public Key: Z Root - SSH Private Host Key: Z - SSH ECDH Private Key: Z - SSH DH Private Key: Z - SSH Session Key: Z - User Password: Z - CO Password: E,Z - HMAC_DRBG

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access G,E,Z - SSH DH Private Key: G,E,Z - SSH Session Key: G,E,Z - HMAC_DRBG V value: E - HMAC_DRBG Key value: E - HMAC_DRBG entropy input: E - HMAC_DRBG seed: E - ECDH Shared Secret: G,E,Z - DH Shared Secret: G,E,Z - HMAC Key: G,E,Z - SSH Public Host Key: E - SSH ECDH Public Key: G,E,Z - SSH DH Public Key: G,E,Z - CO Password: E - CO Authentication Public Keys: E - SSH ECDH Client Public Key: G,E,Z - SSH DH Client Public Key: G,E,Z Operator - SSH Private Host Key: E

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access - SSH ECDH Private Key: G,E,Z - SSH DH Private Key: G,E,Z - SSH Session Key: G,E,Z - HMAC_DRBG V value: E - HMAC_DRBG entropy input: E - HMAC_DRBG seed: E - ECDH Shared Secret: G,E,Z - DH Shared Secret: G,E,Z - HMAC Key: G,E,Z - SSH Public Host Key: E - SSH ECDH Public Key: G,E,Z - SSH DH Public Key: G,E,Z - User Password: E - User Authentication Public Keys: E - SSH ECDH Client Public Key: G,E,Z - SSH DH Client Public Key: G,E,Z - HMAC_DRBG Key value: E Read-only

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access - SSH Private Host Key: E - SSH ECDH Private Key: G,E,Z - SSH DH Private Key: G,E,Z - SSH Session Key: G,E,Z - HMAC_DRBG V value: E - HMAC_DRBG Key value: E - HMAC_DRBG entropy input: E - HMAC_DRBG seed: E - ECDH Shared Secret: G,E,Z - DH Shared Secret: G,E,Z - HMAC Key: G,E,Z - SSH Public Host Key: E - SSH ECDH Public Key: G,E,Z - SSH DH Public Key: G,E,Z - User Password: E - User Authentication Public Keys: E - SSH ECDH Client Public Key: G,E,Z - SSH DH Client Public

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access Key: G,E,Z Unauthorised - SSH Private Host Key: E - SSH ECDH Private Key: G,E,Z - SSH DH Private Key: G,E,Z - SSH Session Key: G,E,Z - HMAC_DRBG V value: E - HMAC_DRBG entropy input: E - HMAC_DRBG seed: E - ECDH Shared Secret: G,E,Z - DH Shared Secret: G,E,Z - HMAC Key: G,E,Z - SSH Public Host Key: E - SSH ECDH Public Key: G,E,Z - SSH DH Public Key: G,E,Z - User Password: E - User Authentication Public Keys: E - SSH ECDH Client Public Key: G,E,Z - SSH DH Client Public Key: G,E,Z

Name

Description

Indicator

Inputs

Output s

Security Function s

SSP Access - SSH ECDH Public Key: G,E,Z - SSH DH Public Key: G,E,Z - CO Password: E - Firmware Integrity Key: E - SSH Private Host Key: E - SSH Public Host Key: E - SSH ECDH Client Public Key: W,E,Z - SSH DH Client Public Key: W,E,Z - SSH Private Host Key: E - SSH Public Host Key: E - User Authentication Public Keys: E - CO Authentication Public Keys: E Root - SSH ECDH Private Key: G,E,Z - SSH DH Private Key: G,E,Z - SSH Session Key: G,E,Z - HMAC_DRBG Key value: G,E,Z - HMAC_DRBG V value: G,E,Z -

Table 18: Non-Approved Services

The module supports loading of firmware from an external source (a complete image replacement) and a firmware load test using ECDSA P-256 with SHA2-256 (CAVP Cert. #A3349) is performed in support of the load.

The module does not support self-initiated cryptographic output.

The module performs the firmware integrity check using ECDSA P-256 with SHA2-256 (CAVP Cert. #A3349). 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) and is exempt from zeroisation. The operator can initiate the integrity test on demand by rebooting the module.

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

Type of Operational Environment: Limited How Requirements are Satisfied: The module contains a limited operational environment since it supports loading of firmware from an external source. The Junos OS 22.3R1-S2.3 operating system is contained within the module, i.e., the tested configurations listed in the Tested Module Identification – Hardware in this document.

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

The module’s physical embodiment is that of a multi-chip standalone meeting Level 1 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. The module enclosure is made of production grade materials. 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. No actions are required by the operator to ensure that physical security is maintained.

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

Table 20: 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 entered/ouput/established via SSH respectively.

Table 21: SSP Zeroization Methods

Table 24: 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 firmware integrity test.

Algorith m or Test

Test Properties the module's console (serial) interface

Test Method

Test Type

Indicator n of the test

Details

Condition s

Table 25: 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 FFC tests respectively). The firmware load test is performed when a firmware image is loaded onto the module from an external source.

Table 26: Pre-Operational Periodic Information

Table 27: Conditional Periodic Information prior to any other use of cryptography by the module in the Approved mode of operation. These

If the conditional self-tests fail, the module enters the soft error state, i.e., it rejects the 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 Crypto Officer must follow the procedures defined below for secure installation, initialization, startup and operation of the module. Crypto Officer Guidance The Crypto Officer must check to verify the firmware image being loaded on the module is the FIPS 140-3 validated version/image. If the image is the FIPS 140-3 validated image, then proceed with installation of the image. Installing The Firmware Image Download the validated firmware image from https://www.juniper.net/support/downloads/junos.html. Log in to the Juniper Networks authentication system using the username (generally your e-mail address) and password supplied by Juniper Networks representatives. Select the validated firmware image. Download the firmware image to a local host or to an internal software distribution site. Connect to the console port on the device from your management device and log in to the Junos OS CLI. Copy the firmware package to the device to the /var/tmp/ directory. Install the new package on the device using the following command: operator > request vmhost software add /var/tmp/<package>.tgz. NOTE: If you need to terminate the installation, do not reboot your device; instead, finish the installation and then issue the request system software delete package.tgz command, where package.tgz is, for example, jinstall-host-qfx-10-f-x86-64.22.3R1-S2.3.secure-signed.tgz.This is your last chance to stop the installation. Reboot the device to complete the load and start the installation: For QFX10002-60C: operator> request vmhost reboot

For QFX10002-36Q/QFX10002-72Q/QFX10008/QFX10016: operator> request system reboot After the reboot has completed, log in and use the show version command to verify that the new version of the firmware is successfully installed. Also install the built-in fips-mode.tgz package needed for enabling the Approved-mode and the jpfe-fips package needed for execution of the CASTs. Please note that this is a one-time installation after which the module remains in the Approved mode once enabled and automatically executes the CASTs on each boot without requiring any operator or external intervention. The following are the commands used for installing these packages: operator >request system software add optional://fips-mode.tgz operator >request system software add optional://jpfe-fips.tgz Enabling Approved Mode of Operation The Crypto Officer is responsible for initializing the module in the Approved mode of operation. The Approved mode of operation is not automatically enabled. The Crypto Officer shall place the module in the Approved mode by first zeroising it to ensure no SSPs are present. Next, the cryptographic officer shall follow the steps found in the Junos OS FIPS Evaluated Configuration Guide for QFX Series, Release 22.3R1 document Chapter 2 to place the module into an Approved mode of operation. The steps from the aforementioned document have been reiterated below. To enable the Approved mode in Junos OS on the module:

1. Zeroise the module using the “request vmhost zeroize” command for QFX10002-60C hardware version or “request system zeroize” command for the other hardware versions. Once the module comes up in the “amnesiac mode” post zeroisation, connect to it using the console port with username “root” and enter the configuration mode. Enable the Approved mode on the device by setting the Approved level to 1, and verify the level: [edit] root# set system fips level 1 [edit] root# show system fips level level 1;
2. Configure the root-authentication password (i.e., Crypto Officer credentials) as follows: root> edit Entering configuration mode [edit] root# set system root-authentication plain-text password New password: Retype new password:

3. Commit the configuration [edit ] root# commit configuration check succeeds Generating RSA key /etc/ssh/fips_ssh_host_key Generating RSA2 key /etc/ssh/fips_ssh_host_rsa_key Generating ECDSA key /etc/ssh/fips_ssh_host_ecdsa_key 'system' reboot is required to transition to fips level 1 commit complete
4. Reboot the device: [edit] root# run request system reboot Reboot the system ? [yes,no] (no) yes During the reboot, the device runs the pre-operational firmware integrity test and all CASTs. It returns a login prompt as follows: root:fips>
5. After the reboot has completed, log in and use the show version command to verify the firmware version is the validated version: root:fips > show version Placing the Module in the Non-Approved Mode of Operation As Crypto Officer, the operator needs to disable the Approved mode of operation on the device to return it to the non-Approved mode of operation. To disable the Approved mode on the device, the module must be zeroised (step 1 defined above).

For further information and for the Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for QFX, Release 22.3R1 document.

For further information and for the Administrator guidance, please see the Junos OS FIPS Evaluated Configuration Guide for QFX, Release 22.3R1 document.

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.