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

Certificate

Approved Algorithms (39)

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

flowchart LR
  %% Deterministic review-risk graph for Arista Crypto Module v3.0 [Software, Software IPsec, Web Portal]
  %% 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["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>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["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 Arista Crypto Module v3.0 [Software, Software IPsec, Web Portal]
  %% 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["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>self-test<br/>Show Status</i><br/>src: text:keyword"]
    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,C3,C5,C6 clueLow;

Security Policy, page by page

Arista Networks Inc. Arista Networks Inc. Arista Crypto Module v3.0 [Software, Software IPsec, Web Portal] Version: 3.0 Non-Proprietary FIPS 140-3 Security Policy Document Version: v1.3 Date: July 18, 2024 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. Table of Contents

1.0 - General Information 4

1.1 Overview 4

1.2 Security Levels 4

2.0 Cryptographic Module Specification 4

2.1 Description 4

2.2 Version Information 5

2.3 Operating Environments 6

2.4 Excluded Components 7

2.5 Modes of Operation 7

2.6 Approved Algorithms 8

2.7 Algorithm Specific Information 12

2.8 RBG and Entropy 14

2.9 Key Generation 14

2.10 Key Establishment 14

2.11 Industry Protocols 15

2.12 Design and Rules 18

2.13 Initialization 18

3.0 - Cryptographic Module Interfaces 18

3.1 Ports and Interfaces 18

4.0 - Roles, Services and Authentication 19

4.1 Authentication Methods 19

4.2 Roles 19

4.3 Approved Services 21

4.4 Non-Approved Services 24

4.5 External Software/Firmware Loaded – N/A 25

5.0 - Software/Firmware security 25

5.1 Integrity Techniques 25

5.2 Initiate on Demand 25

6.0 Operational environment 25

6.1 Operational Environment Type and Requirements 25

6.2 Configuration Settings and Restrictions 25

7.0 - Physical security – N/A 25

8.0 - Non-invasive security – N/A 25

9.0 Sensitive Security Parameters Management 25

9.1 Storage Areas 25

9.2 SSP Input-Output Methods 25

9.3 SSP Zeroisation Methods 26

9.4 SSPs 26

10. Self‐tests 27 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

10.1 Pre-Operational Self-Tests 27

10.2 Conditional Self-Tests 28

10.3 Periodic Self-Tests 31

10.4 Error States 31

11.1 Startup Procedures 31

11.2 Administrator Guidance 32

11.3 Non-Administrator Guidance 32

11.4 Maintenance Requirements – N/A 32

11.5 End of Life 32

12.0 Mitigation of other attacks – N/A 32

13.0 References and Definitions 32

Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

1.0 - General Information

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, Web Portal]. 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, Web Portal] (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). Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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 The module does not contain any hardware or firmware. Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

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: Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. 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

4.3 provides details on the service indicator implemented by the module.

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”. Section 4.3 provides details on the service indicator implemented by the module. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

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. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. CKG [IG D.H] Cryptographic key generation per SP 800-133rev2 * Generation of asymmetric keys for signature generation per [133] section 5.1. * Generation of asymmetric keys for key establishment per [133] section 5.2. protocols from a key agreement shared secret per [133] section 6.2.1. * Symmetric key derivation from existing key per [133] section 6.2.2. 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 Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. Table 8

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Security Function Implementation (SFI) Table 9
• Security Function Implementation (SFI) Entropy Certificates Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. 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 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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 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. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. 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. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

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. Table C- Security Relevant Protocols Used in Approved Mode Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Protocol

Protocol

Key Exchange TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_256_CCM for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_128_CCM for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE

Key Exchange

Server/ Host Auth ECDSA ECDSA ECDSA ECDSA ECDSA ECDSA ECDSA ECDSA ECDSA RSA RSA

Server/ Host Auth

Cipher AES‐GCM‐256 AES-CCM-256 AES-CCM-256 AES-CCM-128 AES-CCM-128 AES-CBC-256 AES-CBC-128 AES-CBC-256 AES-CBC-128 AES-CBC-128 AES-CBC-256

Cipher

Integrity AES‐GCM‐256 AES-CCM-256 AES-CCM-256 AES-CCM-128 AES-CCM-128 HMAC SHA2-384 HMAC SHA2-256 HMAC SHA-1 HMAC SHA-1 HMAC SHA2-256 HMAC SHA2-256

Integrity

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Protocol IPsec-v3

Protocol

Key Exchange TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE TLS_DHE_RSA_WITH_AES_256_CCM_8 for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_256_CCM for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_128_CCM_8 for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_128_CCM for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 DHE TLS_DHE_RSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 DHE diffie-hellman MODP-2048, MODP-3072, MODP-4096,

Key Exchange

Server/ Host Auth RSA RSA RSA RSA RSA RSA RSA RSA RSA RSA

Server/ Host Auth

Cipher AES-CBC-256 AES-CBC-128 AES-CCM-256 AES-CCM-256 AES-CCM-128 AES-CCM-128 AES-CBC-256 AES-CBC-128 AES-CBC-256 AES-CBC-128 AES-GCM-128 AES-GCM-192 AES-GCM-256 AES-CBC-128

Cipher

Integrity HMAC SHA-1 HMAC SHA-1 AES-CCM-256 AES-CCM-256 AES-CCM-128 AES-CCM-128 HMAC SHA2-256 HMAC SHA2-256 HMAC SHA-1 HMAC SHA-1 AES-GCM-128 AES-GCM-192 AES-GCM-256 HMAC-SHA2-256

Integrity

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Protocol

Protocol

Key Exchange MODP-6144, MODP-8192 ec diffie-hellman secp256r1, secp384r1, secp521r1

Key Exchange

Server/ Host Auth

Server/ Host Auth

Cipher AES-CBC-192 AES-CBC-256 AES-CTR-128 AES-CTR-192 AES-CTR-256 AES-CCM-128 AES-CCM-192 AES-CCM-256

Cipher

Integrity HMAC-SHA2-384 HMAC-SHA2-512 AES-CCM-128 AES-CCM-192 AES-CCM-256

Arista Networks Inc. Table D - Security Relevant Protocols Used in Approved Mode

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”.

3.0 - Cryptographic Module Interfaces

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. Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

N/A

Status Output

API return codes, error messages, logging messages

Role CO CO CO CO

Role

Service Authenticated Decryption Authenticated Encryption Decryption Encryption

Service

Input Ciphertext, authentication tag, key, IV Plaintext, key, IV Ciphertext, key Plaintext, key

Input

Output Plaintext Ciphertext, authentication tag Plaintext Ciphertext

Output

Arista Networks Inc. Table 12 – Ports and Interfaces The module does not support Control Output.

4.0 - Roles, Services and Authentication

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 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. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Role CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO CO

Role

Service Key Derivation (TLS) Key Derivation (SSH) Key Derivation (IKE) Key Derivation (SP 800-108r1) Key Encapsulation Key Generation Key Un-encapsulation Key Verification Initialize Message Authentication Generation Message Digest On-Demand Integrity Test On-Demand self-test Random number generation Shared secret computation Show Status Show Version Signature Generation Signature Verification Zeroise

Service

Input PRF algorithm, TLS master secret PRF algorithm, SSH shared secret PRF algorithm, IKE shared secret Shared secret, key size RSA keypair, keying material to encapsulate Algorithm, key size RSA keypair, keying material to un- encapsulate Key to verify Crypto Officer Password Message, Algorithm, key Message None None Size EC Curve or DH parameters, V's public key None None Message, hash algorithm, private key Message, Signature, hash algorithm, public key Context containing SSPs

Input

Output Derived Keys Derived Keys Derived Keys Derived Keys Encapsulated key Key Pair Un-encapsulated key Return codes and log messages None Message Authentication code Digest of the message Result of test (pass/fail) Result of self-test (pass/fail) Random bytes Shared secret Return code of 1 indicates approved mode enabled, 0 is disabled String indicating the module version and name Signature Verification result None

Output

Arista Networks Inc. Table 13

• Roles, Services, Input, and Output Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Role CO (Crypto Officer)

Role

Authentication Method Password

Authentication Method

Authentication Strength 95^16 (module enforces 16 character minimum password length); chance of guessing in one minute 1 in 9.03*10^18

Authentication Strength

Arista Networks Inc. Table 14 lists all operator roles supported by the module (for the role, CO indicates “Crypto Officer”) and the security strength of the authentication. The Module does not support a maintenance role nor bypass capability. The Module does not support concurrent operators. 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 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. G, R Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. R 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”. Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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.

The following table lists the non-approved services that utilize non-approved security functions. Table E - Non-approved services Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

4.5 External Software/Firmware Loaded – N/A

5.0 - Software/Firmware security

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 digest.

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.

7.0 - Physical security – N/A

8.0 - Non-invasive security – N/A

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 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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 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.

Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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. Table G – Pre-Operational Test Methods

Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Arista Networks Inc. Table H

• Conditional Self-Tests Cryptographic Algorithm Self-Tests Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. 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 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, Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Abbreviation

Abbreviation

Full Specification Name

Full Specification Name

Arista Networks Inc. which in turn is distributed as part of the Cloudvision Portal product through the Arista software downloads website. While there is no need for the library to be built by the user at any point in time, the fipscanister.o 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. When downloading the Cloudvision Portal image, the SHA-256 hash of the image is also made available. When an authorized operator downloads the Cloudvision Portal image, they can also download the hash file and compare the SHA-256 hash of the Cloudvision Portal image to the one listed in the file to make sure that the downloaded image is correct. Then they can install the Cloudvision Portal 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 which will display the module base name and version number “Arista Crypto Module v3.0“. Finally ensure correct operation of the module by running the on-demand self-test service as specified in Section 5 by calling “openssl --fips” from bash.

11.4 Maintenance Requirements – N/A

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.

12.0 Mitigation of other attacks – N/A

The following standards are referred to in this Security Policy. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Abbreviation [NIST] [FIPS140‐3] [IG] [ISO19790] [38A] [38B] [38C] [38D] [38E] [38F] [56Ar3] [56Ar2] [56Br2] [67]

Abbreviation

Full Specification Name National Institute of Standards and Technology Security Requirements for Cryptographic Modules, March 22, 2019 Implementation Guidance for FIPS PUB 140‐3 and the Cryptographic Module Validation Program Information technology

• Security techniques
• Security requirements for cryptographic modules, 2012(2014) NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, December 2001 NIST Special Publication 800‐38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, May 2005 NIST Special Publication 800‐38C, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, May 2004 NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007 NIST Special Publication 800‐38E, Recommendation for Block Cipher Modes of Operation: The XTS‐AES Mode for Confidentiality on Storage Devices, January 2010 NIST Special Publication 800‐38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, December 2012 NIST Special Publication 800‐56A Revision 3, Recommendation for Pair‐Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 NIST Special Publication 800‐56A Revision 2, Recommendation for Pair‐Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, May 2013 NIST Special Publication 800‐56B Revision 2, Recommendation for Pair‐Wise Key Establishment Schemes Using Integer Factorization Cryptography, March 2019 NIST Special Publication 800‐67 Revision 2, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, November 2017

Full Specification Name

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Abbreviation [90A] [90B] [90C] [108] [131A] [132] [133] [135] [180] [186] [186‐2] [197] [198] [202] [RFC 4581]

Abbreviation

Full Specification Name NIST Special Publication 800‐90A Revision 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015. NIST Special Publication 800‐90B, Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018 (Second Draft) NIST Special Publication 800‐90C, Recommendation for Random Bit Generator (RBG) Constructions, April 2016 NIST Special Publication 800‐108, Recommendation for Key Derivation Using Pseudorandom Functions (Revised), October 2009 NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019 NIST Special Publication 800‐132, Recommendation for Password‐Based Key Derivation, Part 1: Storage Applications, December 2010 NIST Special Publication 800‐133 Revision 2, Recommendation for Cryptographic Key Generation, June 2020 NIST Special Publication 800‐135 Revision 1, Recommendation for Existing Application‐Specific Key Derivation Functions, December 2011 Federal Information Processing Standards Publication 180-4, Secure Hash Standard (SHS), August 2015 Federal Information Processing Standards Publication 186‐4, Digital Signature Standard (DSS), July1 2013 Federal Information Processing Standards Publication 186-2, Digital Signature Standard (DSS), January 2000 Federal Information Processing Standards Publication 197, Advanced Encryption Standard (AES), November 26, 2001 Federal Information Processing Standards Publication 198‐1, The Keyed‐Hash Message Authentication Code (HMAC), July 2008 Federal Information Processing Standards Publication 202, SHA‐3 Standard: Permutation‐Based Hash and Extendable‐Output Functions, August 2015 IETF, The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP‐FAST), May 2007

Full Specification Name

Arista Networks Inc. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).

Acronym CO CloudEOS VA

Acronym

Definition Cryptographic Officer role Name of the Arista operating system Vendor Affirmed cryptographic algorithms are Approved algorithms for which no CAVP tests are available yet. The vendor performs their own testing as the basis for their affirmation.

Definition

Arista Networks Inc. Table J - References Table K - Acronyms and Definitions Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision).