Arista Crypto Module v3.0 [Software, Software IPsec]

Certificate

Approved Algorithms (39)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Arista Crypto Module v3.0 [Software, Software IPsec]
  %% 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<br/>upgrade</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>On-Demand self-test<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<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 Arista Crypto Module v3.0 [Software, Software IPsec]
  %% 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<br/>upgrade</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>On-Demand self-test<br/>Show Status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<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

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Arista Networks Inc. Arista Crypto Module v3.0 [Software, Software IPsec] Version: 3.0 Non-Proprietary FIPS 140-3 Security Policy Document Version: v1.4 Date: July 6, 2024 Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table of Contents

10. Self‐tests Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec]

Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec]

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.0 of the Arista Networks Inc. Arista Crypto Module v3.0 [Software, Software IPsec]. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 1 module.

Purpose and Use: The Arista Crypto Module v3.0 [Software, Software IPsec] (hereafter referred to as “the module”) is a Software Multichip standalone cryptographic module. The module provides cryptographic services to applications running in the user space of the underlying operating system through a C language Application Program Interface (API). Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Module Embodiment: Multi-chip Standalone Module Characteristics: None Cryptographic Boundary: The block diagram in Figure 1 shows the cryptographic boundary of the module, its interfaces with the operational environment and the flow of information between the module and operator (depicted through the arrows) Figure 1

• Block diagram depicting the cryptographic boundary (in pink) and data flow between the module interfaces and operator. The boundary also includes the instantiation of the cryptographic module in memory. The TOEPP is the physical perimeter of the hardware platform listed in Table 2
• Tested Operational Environment. The module components consist of the fipscanister.o file in executable form. The fipscanister.o is delivered in the product by statically linking to libcrypto.so. The Module performs no communications other than with the calling application (the process that invokes the Module services) and the OS syslog. The boundary also includes the instantiation of the module saved in memory.

Table A

• Version Information Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] The module does not contain any hardware or firmware.

The module operates in a modifiable operational environment. The module runs on a commercially available virtual machine, based on a general-purpose operating system. The module executes on the hardware specified in Section 2. The module does not support concurrent operators. Software, Firmware, Hybrid Testing Operating Environments: The module has been tested on the platforms indicated in the following table, with the corresponding module variants and configuration options with and without PAA. # Table 2

• Tested Operational Environments Code Sets: The module consists of executable code in the form of fipscanister.o. The compiler used to generate the executable code is gcc. Vendor Affirmed Operating Environments: The vendor claims the following platforms to be vendor affirmed - that is, the module functions the same way and provides the same services on the following systems: # Table 3 - Vendor Affirmed Operational Environments The module installation procedure for the above platforms is the same as mentioned in Section 11.1, Startup Procedures. Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Per the FIPS 140-3 Cryptographic Module Validation Program Management Manual, Section 7.9, Arista affirms that the module remains compliant with the FIPS 140-3 validation when operating on any general-purpose computer (GPC) provided that the GPC uses the specified operating system/mode specified on the validation certificate, or another compatible operating system (including Linux distros such as CentOS 6.x,7.x,8.x). The CMVP allows vendor porting and re-compilation of a validated cryptographic module from the operational environment specified on the validation certificate to an operational environment which was not included as part of the validation testing as long as the porting rules are followed. Note: The 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.

There are no excluded components for the module.

Modes List and Description: Table B - Modes of Operation When the module starts up successfully, after passing all the pre-operational self-tests, the module is set to use Approved Mode by calling FIPS_mode_set with an argument of 1. Section

Mode change instructions and status indicators: To change to Approved mode, call FIPS_mode_set(1). To validate that the Approved Mode is active, call FIPS_mode() and verify the return value is equal to “1”.

The table below lists the approved security functions (or cryptographic algorithms) of the module, including specific key lengths employed for approved services, and implemented modes or methods of operation of the algorithms. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table 5 - Approved Algorithms Note: IG D.R states for modules submitted after May 16, 2023 it is non-approved to use of SHA2-224 or SHA2-384 within Hash DRBG or HMAC DRBG. Vendor Affirmed Approved Algorithms The table below lists the vendor affirmed algorithms that are allowed in the approved mode of operation. Table 6

• Vendor Affirmed Approved Algorithms Non-Approved Algorithms Allowed in the Approved Mode of Operation The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation. (SP 800-140B table 7: Non-Approved Algorithms Allowed in the Approved Mode of Operation has been omitted) Non-Approved Algorithms Allowed Algorithms with No Security Claimed The table below lists the non-approved algorithms that are allowed in the approved mode of operation with no security claimed. These algorithms are used by the approved services listed in Table 15. Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table 8

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Security Function Implementation (SFI) SF Properties [O] KASECC KASFFC D.G. TLSKTS SSHv2KTS IPsecKTS Table 9
• Security Function Implementation (SFI) Entropy Certificates The module does not implement or actively call any SP 800-90B entropy sources. (SP 800140B table 10: Entropy Certificates has been omitted) Non-Approved Algorithms Not Allowed In the approved Mode of Operation The table below lists non-approved algorithms that are not allowed in the approved mode of operation. Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table 11 - Non-Approved Algorithms Not Allowed In the approved Mode of Operation

AES-GCM IV Generation The module offers three AES GCM implementations. The GCM IV generation for these implementations complies respectively with IG C.H under Scenario 1 and Scenario 2. The GCM shall only be used in the context of the AES-GCM encryption executing under each scenario, and using the referenced APIs explained next. Scenario 1, TLS 1.2 For TLS 1.2, the module offers the GCM implementation via the functions aes_gcm_tls_cipher, which calls CRYPTO_gcm128_encrypt_ctr32, and uses the context of Scenario 1 of IG C.H. The module is compliant with SP800-52rev2 and the mechanism Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] for IV generation is compliant with RFC5288. The module supports acceptable AESGCM ciphersuites from Section 3.3.1 of SP800-52rev2. The module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 264-1 for a given session key. If this exhaustion condition is observed, the module returns an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. Scenario 1, SSHv2 For SSH, the module offers the GCM implementation via the functions CRYPTO_gcm128_encrypt_ctr32, and uses the context of Scenario 1 of IG C.H. The module is compliant with RFCs 4252, 4253, and 5647. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. Scenario 1, IPsec-v3 For IPsec, the module offers the GCM implementation via the functions CRYPTO_gcm128_encrypt_ctr32, and uses the context of Scenario 1 of IG C.H. The module is compliant with RFCs 4106 and 5282. The module uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES-GCM encryption keys are derived. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. This application negotiates the protocol session’s keys and the value in the first 32 bits of the nonce. The construction of the last

The module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 264-1 for a given session key. If this exhaustion condition is observed, the module returns an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. Scenario 2, Random IV In this implementation, the module offers the interfaces RAND_bytes for compliance with Scenario 2 of IG C.H and SP800-38D Section 8.2.2. The AES-GCM IV is generated randomly internal to the module using the module's approved DRBG. The DRBG seeds itself from the entropy source. The GCM IV is 96 bits in length. Per Section 9, this 96-bit IV contains 96 bits of entropy. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] XTS-AES Key Generation The module checks for Key_1 ≠ Key_2 before using the keys in the XTS-AES algorithm in compliance with IG C.I.

The module provides an SP800-90Arev1-compliant Deterministic Random Bit Generator (DRBG) using CTR_DRBG mechanism with AES-256 for creation of key components of asymmetric keys, and random number generation. Operators may instantiate and use the other Approved DRBGs offered by the module. The module receives entropy passively and uses 384 bits of entropy to seed the DRBG.

For generating RSA, ECDSA and EC Diffie-Hellman keys, the module implements asymmetric key generation services compliant with FIPS186-4 and using a DRBG compliant with SP80090Arev1. The random value used in asymmetric key generation is obtained from the DRBG. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 5.1 of SP800-133rev2 (vendor affirmed) by obtaining a random bit string directly from an approved DRBG and that can support the required security strength requested by the caller (without any V, as described in Additional Comments 2 of IG D.H). The module does not provide a dedicated service for generating symmetric keys. However, symmetric keys can be derived using SP800-135rev1 for TLS KDF, IKE v1/2 KDF, and SSHv2 KDF algorithms, as well as SP800-108 counter KBKDF. This generation method maps to section

The module provides EC Diffie-Hellman and FFC Diffie-Hellman shared secret computation compliant with SP800-56Arev3, in accordance with scenario 2 (1) of IG D.F. It also provides RSA OAEP key transport as KTS-IFC compliant with SP 800-56Br2 in accordance with IG D.G. and applications may transport keys as TLS, SSHv2, or IPsec protocol payload compliant to SP 800-38F in accordance with IG D.G. Additionally, the module also supports key derivation using TLS 1.0/1.1, TLS 1.2, IKE v1, IKE v2, SSHv2 KDF compliant to SP800-135rev1 and counter KBKDF compliant to SP800-108.

The module does not implement any industry protocols. However it provides the building blocks to support the following protocols. Note: no parts of the TLS v1.0/1.1, v1.2, SSHv2, or IPsec-v3 protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table C- Security Relevant Protocols Used in Approved Mode Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table D - Security Relevant Protocols Used in Approved Mode Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec]

The module initializes upon power-on. After the pre-operational self-tests (POST) are successfully concluded, the module automatically transitions to the operational state. In this state, the module awaits service requests from the operator. The operator must then manually set the module to approved mode, via the interface described in Section “2.5 Modes of Operation”.

Upon initializing the module by installing the module and setting the password, the operator must then manually set the module to approved mode, via the interface described in Section “2.5 Modes of Operation”:

As a Software module, the module interfaces are defined as Software or Firmware Module Interfaces (SFMI), and there are no physical ports. The interfaces are mapped to the API provided by the module, through which the operator can interact. The interfaces are listed in the table below. All data output via data output interface is inhibited under the following circumstances:

• When the module is in POST mode During zeroisation of data such as CSPs When the module enters error state. N/A N/A N/A N/A Table 12
• Ports and Interfaces The module does not support Control Output.

The module supports Role-based authentication using passwords as the SP 800-140E memorized secret. The module has a strength of authentication objective of at least 1/95^8, and to achieve that over a one minute period the module enforces a minimum password length of 16 Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] characters. The password can be set by the calling application through the “FIPS_set_password” API. The module has procedural controls and enforces that an operator must set a password prior to use of the module. The module is installed according to section 11.1 and the module authentication mechanism is included within the module software and so automatically included during that installation process. Since the module enforces a minimum 16 character password length and there are 95 possible ASCII characters (upper and lower case, digits, special characters), it has an authentication strength of 95^16. Thus the false acceptance rate is 1/95^16. Assuming a very high-performing CPU that runs at 4 GHz with 24 cores which means it can perform 4 billion * 24 instructions per second, the probability of a successful random access within a minute is still extremely unlikely at 1/95^16 * 4 billion * 24 cores * 60 seconds/min. It would take about 150 billion years to have a 1% chance of cracking the password in this scenario: 1/95^16 * 4 billion * 24 cores * 60 sec / min * 60 min / hr * 24 hr / day * 365 days / year *

The module supports the Crypto Officer role only, whose authentication is performed by the module using passwords. This sole role is implicitly assumed by the operator of the module when performing a service after authentication. Table 13 provides a mapping of services to the roles that can utilize them, in this case the sole role of the module, and the service inputs and outputs. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table 13

• Roles, Services, Input, and Output Table 14 lists all operator roles supported by the module (for the role, CO indicates “Crypto maintenance role nor bypass capability. The Module does not support concurrent operators. Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] length); chance of guessing in one minute 1 in 9.03*10^18 Table 14

• Roles and Authentication

The module provides services to operators who assume the available role. All services are described in detail in the developer documentation. For the role, CO indicates “Crypto Officer”. The following table lists the approved services that utilize approved and allowed security W, E W, E W, E W, E 1.0/1/1/1.2 (SP 800108r1) Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] - W, R Key Unencapsulation Key Unencapsulation - W, R W, E -E W, E N/A N/A HMAC SHA2256 N/A N/A Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] R N/A N/A N/A N/A N/A N/A N/A N/A W, E W, E N/A N/A Table 15

• Approved services The module implements a status indicator that indicates whether the invoked service is approved. When approved mode is active, non-approved functions cannot be used. If a nonapproved function is used in approved mode, an error code of 0 indicating failure is returned and the reason for failure is added to the error queue. To verify if approved mode is active, the function FIPS_mode() should be called. This function is described in Section “2.5 Modes of Operation”. In addition to the return code, the module outputs syslog messages to indicate whether an invoked service is approved. The usage is as follows: STEP 1: Check the system log output buffer for existing log messages STEP 2: Make a service call i.e., API function for performing a service STEP 3: Check the system log output buffer for a new log message indicating which service was invoked. For example, running the TLS key derivation service will generate a new log message saying “OpenSSL: Key derivation service for TLS performed”. If there is no log message, that is an indication that the invoked function was not an approved service. Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec]

The following table lists the non-approved services that utilize non-approved security functions. Table E - Non-approved services

The integrity of the module is validated by comparing the module with a HMAC-SHA2-256 value generated after the build of fipscanister.o, which is the FIPS Object Module. This generated value is embedded into fipscanister.o before fipscanister.o is statically linked to libcrypto.so. During runtime the FIPS_mode_set() function calculates the digest over fipscanister.o, excluding the embedded hash value, and checks to see if the embedded value matches the calculated Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec]

The module provides on-demand integrity test. The integrity test is performed by the OnDemand Integrity Test service, which calls the FIPS_check_incore_fingerprint function. The integrity test is also performed as part of the Pre-Operational Self-Tests. One can also initiate the On Demand Integrity Test service by calling “openssl --fips” on the command line, which is a calling application that runs the module’s self-test API function. A successful test will show “FIPS mode is enabled”.

Type of Operating Environment: Modifiable

The module should be installed as stated in section 11.

Table F

• Storage Areas SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroisation function calls. The module does not perform persistent storage of SSPs.

The module does not support manual SSP entry or intermediate key generation output. The module does not support entry and output of SSPs beyond the physical perimeter of the operational environment. Except for services designed to wrap or unwrap an SSP the SSPs are provided to the module via API input parameters in the plaintext form and output via API output parameters in the plaintext form to and from the calling application running on the same operational environment. SSPs provided for unwrapping are input encrypted using KTS-IFC’s RSA-OAEP_basic, and SSPs the module wrapped are output encrypted using KTS-IFC’s RSAOAEP_basic. The output of plaintext CSPs requires two independent internal actions. Specifically, the first action is creation of the cipher context to request the service and to hold the CSPs to be output from the module. The second action is to process the ‘Key Generation’ service request using the Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] context created. Only after successful completion of this request, the generated CSP is output via the API output parameter. The zeroisation is performed by the module overwriting zeroes or predefined values to the memory location occupied by the SSP and further deallocating that area. The calling application, interacting with the module, is responsible for calling the appropriate destruction functions using the zeroisation APIs listed in the above table to zeroise the calling application’s copies of the SSP. The completion of a zeroisation routine will indicate that a zeroisation procedure succeeded.

N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A / N/A N/A N/A / N/A N/A N/A / N/A N/A N/A / N/A N/A N/A N/A N/A N/A Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] N/A N/A N/A N/A N/A N/A Table 20

• SSPs Intermediate key generation values are never output from the module, but are treated like CSPs and are automatically zeroised once no longer needed. 10. Self‐tests

The module performs pre-operational tests automatically when the module is powered on. The pre-operational self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. The module transitions to the operational state only after the preoperational self-tests (and the cryptographic algorithm self-tests, which in this module are executed automatically after the pre-operational self-tests) are passed successfully. The types of pre-operational self-tests are described in the next sub-section. Pre-Operational Software Integrity Test The HMAC-SHA2-256 Conditional CAST is performed before checking the module integrity. Then the integrity of the software component of the module is verified according to Section 5, using HMAC-SHA2-256. If the comparison verification fails, the module transitions to the error state (Section 10.4). Pre-Operational Bypass and Critical Functions Tests The module does not implement pre-operational bypass or critical functions tests. We note that the entropy source is not within the cryptographic boundary of the module, instead passively receiving entropy from the external entropy source. Thus, its critical functions tests are not included in the module. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] HMACSHA2-256 Table G

• Pre-Operational Test Methods

P-224, P384 Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] KAS-ECCSSC KAS-FFCSSC Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] N/A KAS-ECCSSC N/A SP 80056Arev3 KAS-FFCSSC N/A SP 80056Arev3 N/A Table H

• Conditional Self-Tests Cryptographic Algorithm Self-Tests The module performs self-tests on FIPS-Approved cryptographic algorithms supported in the approved mode of operation, using the tests shown in (and indicated as CASTs) and using the provision of IG 10.3.A and IG 10.3.B for optimization of the number of self-tests. Data output through the data output interface is inhibited during the self-tests. The cryptographic algorithm self-tests are performed in the form of Known Answer Tests (KATs), in which the calculated output is compared with the expected known answer (that are hard-coded in the module). A failed match causes a failure of the self-test. If any of these self-tests fails, the module transitions to error state and is aborted. Conditional Pairwise Consistency Tests Document Version 1.4 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] The module implements RSA and ECDSA key generation service and performs the respective pairwise consistency test using sign and verify functions when the keys are generated (Table H). In addition, SP 800-56a Rev3 conditional tests are run when ephemeral keypairs are created for key agreement.

On demand self-tests can be invoked by powering-off and reloading the module. This service performs the same pre-operational test that includes integrity test and cryptographic algorithm tests executed during power-up. The integrity test can also be performed on demand by calling the FIPS_check_incore_fingerprint function. During the execution of the on-demand self-tests, cryptographic services are not available, and no data output or input is possible.

Table I - Error States If the module fails any of the self-tests, the module enters the error state. In the error state, the module outputs the error through the status output interface and the abort function is called that raises the SIGABRT signal, causing the program termination such that the module is no longer operational. In the error state, as the module is no longer operational the data output interface is inhibited. In order to recover from the Error state, the module needs to be rebooted. 11. Life-cycle Assurance

The cryptographic module is the fipscanister.o file, though Arista does not distribute this file on its own. Instead it is embedded into the shared library libcrypto.so which is part of OpenSSL, which in turn is distributed as part of the CloudEOS product, in the CloudEOS image accessible through the Arista software downloads website. The CloudEOS product includes the CloudEOS operating system, virtual machine, applications, OpenSSL, libcrypto.so, and fipscanister.o. While there is no need for the fipscanister.o library to be built by the user at any point in time, the file can be verified as the correct one by comparing the SHA256 hash sum. The SHA256 hash should be 8b92b97d92571963b66649d0bb3ca62fba77100a316757e9487ad2091eddcc18. In the Arista build process for building OpenSSL, this fipscanister.o file is linked into OpenSSL’s libcrypto.so shared library file and OpenSSL is configured to use it. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] When downloading the CloudEOS image, the SHA-256 hash of the image is also made available. When an authorized operator downloads the CloudEOS image, they can also download the hash file and compare the SHA-256 hash of the CloudEOS image to the one listed in the file to make sure that the downloaded image is correct. Then they can install the CloudEOS image onto the virtual machine. Upon completion of installation, the user can confirm that the correct module has been installed by running the “show version” service should display the module base name and version number, “Crypto Module: Arista Crypto Module v3.0“. Correct operation of the module can be verified by running the on-demand self-test service as specified in Section 5 by calling “openssl --fips” from bash.

To cease using the module, power off the module. The module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory and that value vanishes when the module is powered off. So as a first step for the secure sanitization, the module needs to be powered off. Then for actual deprecation, the module will be upgraded to a newer version that is approved. This upgrade process will uninstall/remove the old/terminated and provide a new replacement.

The following standards are referred to in this Security Policy. Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table J - References Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. ‐ Arista Crypto Module v3.0 [Software, Software IPsec] Table K - Acronyms and Definitions Document Version 1.4 Arista Networks Inc. Public Material

• May be reproduced only in its original entirety (without revision).