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

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.

ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6.

1 General 1

2 Cryptographic module specification 1

3 Cryptographic module interfaces 1

4 Roles, services, and authentication 2

5 Software/Firmware security 1

6 Operational environment 1

7 Physical security N/A

8 Non-invasive security N/A

9 Sensitive security parameter management 1

10 Self-tests 1

11 Life-cycle assurance 1

12 Mitigation of other attacks N/A

Table 1

• Security Levels Overall security level 1.

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). Module Type: Software 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.

Type Versions Software Name: Arista Crypto Module v3.0 [Software, Software IPsec, Web Portal] Version: 3.0 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. Hardware Operating Environments

• N/A 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. # Operating System Hardware Processor PAA/Acceleration Platform CloudVision Portal 2023.2.0 Supermicro SYS- Intel Xeon Gold Yes

CentOS 7 CloudVision Portal 2023.2.0 Supermicro SYS- Intel Xeon Gold No

CentOS 7 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: # Operating System Hardware Platform

6 CloudVision Portal Any general-purpose computer (GPC)

7 Any compatible OS with any Any general-purpose computer (GPC)

virtualization software 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: Name Description Approved Mode Status Indicator Approved Mode Single Approved Yes The status indicator is a return value Mode

• selected 1 from the FIPS_mode() function. by calling the FIPS_mode_set( 1) function. Non-Approved Selected by No The status indicator is a return value Mode default in 0 from the FIPS_mode() function. CloudVision Portal 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”. 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. CAVP Algorithm Mode / Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) A4153 AES-CBC AES 128, 192, 256 Encrypt, Decrypt A4153 AES-CCM AES 128, 192, 256 Encrypt, Decrypt A4153 AES-CFB1 AES 128, 192, 256 Encrypt, Decrypt A4153 AES-CFB128 AES 128, 192, 256 Encrypt, Decrypt A4153 AES-CFB8 AES 128, 192, 256 Encrypt, Decrypt A4153 AES-CMAC AES 128, 192, 256 Message Authentication A4153 AES-CTR AES 128, 192, 256 Encrypt, Decrypt A4153 AES-ECB AES 128, 192, 256 Encrypt, Decrypt A4153 AES-GCM AES 128, 192, 256 Authenticated Encrypt, Authenticated Decrypt, Message Authentication A4153 AES-XTS Testing AES 128, 256 Confidentiality on storage Revision 2.0 devices only [XTS-AES is compliant to IG C.I by checking for Key_1 ≠ Key_2.] A4153 Counter DRBG Counter DRBG 128, 192, 256 Deterministic Random Bit Generation [Module defaults to Counter DRBG with 256bit security strength] A4153 ECDSA KeyGen Secret Generation P-256, P-384, P-521 KeyGen (FIPS186-4) Mode: Testing Candidates A4153 ECDSA KeyVer ECDSA KeyVer P-256, P-384, P-521 KeyVer (FIPS186-4) A4153 ECDSA SigGen ECDSA SigGen Curve: P-256, P-384, P-521; SigGen (FIPS186-4) Hash Algorithm: SHA2-224, SHA2-256, SHA2-384, SHA2-512 A4153 ECDSA SigVer ECDSA SigVer Curve: P-256, P-384, P-521; SigVer (FIPS186-4) Hash Algorithm: SHA-1, SHA2224, SHA2-256, SHA2-384, SHA2-512 A4153 HMAC DRBG HMAC DRBG SHA-1, SHA2-224, SHA2-256, Deterministic Random Bit SHA2-384, SHA2-512 Generation A4153 HMAC-SHA-1 HMAC Key: 112-2048 Increment 8; Message Authentication, MAC: 80-160 Increment 8 password obfuscation A4153 HMAC-SHA2-224 HMAC Key: 112-2048 Increment 8; Message Authentication MAC: 112-224 Increment 16 Arista Networks Inc. Public Material

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

Arista Networks Inc. CAVP Algorithm Mode / Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) A4153 HMAC-SHA2-256 HMAC Key: 112-2048 Increment 8; Message Authentication, MAC: 128-256 Increment 64 KDF primitive, integrity test A4153 HMAC-SHA2-384 HMAC Key: 112-2048 Increment 8; Message Authentication, MAC: 192-384 Increment 64 KDF primitive A4153 HMAC-SHA2-512 HMAC Key: 112-2048 Increment 8; Message Authentication, MAC: 256-512 Increment 64 KDF primitive A4153 Hash DRBG Hash DRBG SHA-1, SHA2-224, SHA2-256, Deterministic Random Bit SHA2-384, SHA2-512 Generation A4153 KAS-ECC-SSC KAS ephemeralUnified: P-256, P-384, Key Agreement [Relies on Sp800-56Ar3 P-521 calling application to feed shared secret into KDF A4153 KAS-FFC-SSC KAS dhEphem: ffdhe2048, ffdhe3072, Key Agreement [Relies on Sp800-56Ar3 ffdhe4096, ffdhe6144, MODP- calling application to feed 2048, MODP-3072, MODP-4096, shared secret into KDF] MODP-6144, MODP-8192 A4153 KDF IKEv1 CVL KDF IKEv1 Hash Algorithm: SHA-1, SHA2- Key Derivation for IKEv1 256, SHA2-384, SHA2-512 A4153 KDF IKEv2 CVL KDF IKEv2 Hash Algorithm: SHA-1, SHA2- Key Derivation for IKEv2 256, SHA2-384, SHA2-512 A4153 KDF SP800-108 KDF SP800-108 KDF Mode: Counter; MAC Mode: Key Derivation CMAC-AES128, CMAC-AES256 A4153 KDF SSH CVL KDF SSH Hash Algorithm: SHA-1, SHA2- Key Derivation for SSHv2 224, SHA2-256, SHA2-384, SHA2-512 A4153 KDF TLS CVL KDF TLS TLS Version: v1.0/1.1 Key Derivation for TLS A4153 KTS-IFC KTS Modulo: 2048, 3072, 4096; KTS- Key Transport OAEP-basic A4153 RSA KeyGen RSA KeyGen Key Generation Mode: B.3.3; KeyGen (FIPS186-4) Modulo: 2048, 3072, 4096 A4153 RSA SigGen RSA SigGen Modulo 2048, 3072, 4096; ANSI SigGen (FIPS186-4) X9.31 (SHA2-256, SHA2-384, SHA2-512), PKCS 1.5 (SHA2224, SHA2-256, SHA2-384, SHA2-512), PKCSPSS (SHA2224, SHA2-256, SHA2-384, SHA2-512) A4153 RSA SigVer RSA SigVer Modulo 1024, 2048, 3072, 4096; SigVer (FIPS186-4) ANSI X9.31 (SHA-1 SHA2-256, SHA2-384, SHA2-512), PKCS 1.5 (SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512), PKCSPSS (SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2512) Arista Networks Inc. Public Material

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

Arista Networks Inc. CAVP Algorithm Mode / Method Description / Key Size(s) / Use / Function Cert and Standard Key Strength(s) A4153 SHA-1 SHS Message Length: 0-65536 Message Digest Generation Increment 8 A4153 SHA2-224 SHS Message Length: 0-65536 Message Digest Generation Increment 8 A4153 SHA2-256 SHS Message Length: 0-65536 Message Digest Generation Increment 8 A4153 SHA2-384 SHS Message Length: 0-65536 Message Digest Generation Increment 8 A4153 SHA2-512 SHS Message Length: 0-65536 Message Digest Generation Increment 8 A4153 TLS v1.2 KDF TLS v1.2 KDF Hash Algorithm: SHA2-256, Key Derivation for TLS RFC7627 RFC7627 SHA2-384, SHA2-512 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. Algorithm Caveat Use or Function CKG [IG D.H] Cryptographic key generation per SP 800-133rev2 and IG D.I * Generation of asymmetric keys for signature generation per [133] section 5.1. * Generation of asymmetric keys for key establishment per [133] section 5.2. * Symmetric key derivation for industry standard 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. Algorithm Caveat Use or Function MD5 Allowed per IG 2.4.A Message digest used in TLS 1.0/1.1 KDF only Table 8

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Security Function Implementation (SFI) Name Type Description SF Properties [O] Algorithms/CAV P Cert KAS- KAS SP 800-56Arev3. KAS_ECC_SSC per IG P-256, P-384, P-521 curves KAS-ECC-SSC ECC D.F Scenario 2, path (2). No key providing 128, 192, or 256 Sp800-56Ar3/A4153 confirmation, key derivation per IG 2.4.B. bits of encryption strength KDF IKEv1/A4153 SP 800-135. KDFs (TLS 1.0/1.1, 1.2, KDF IKEv2/A4153 SSHv2, IKE v1, IKE v2) KDF SSH/A4153 KDF TLS/A4153 TLS v1.2 KDF RFC7627/A4153 KAS- KAS SP 800-56Arev3. KAS_FFC_SSC per IG 2048, 3072, 4096, 6144, KAS-FFC-SSC FFC D.F Scenario 2, path (2). No key and 8192-bit moduli Sp800-56Ar3/A4153 confirmation, key derivation per IG 2.4.B. providing 112, 128, 152, KDF IKEv1/A4153 SP 800-135. KDFs (TLS 1.0/1.1, 1.2, 176, or 200 bits of KDF IKEv2/A4153 SSHv2, IKE v1, IKE v2) encryption strength KDF SSH/A4153 KDF TLS/A4153 TLS v1.2 KDF RFC7627/A4153 KTS-IFC KTS SP 800-56Brev2. KTS-IFC (key 2048, 3072, and 4096-bit KTS-IFC KTS-OAEPencapsulation and un-encapsulation) per IG moduli providing 112, 128, basic/A4153 D.G. or 152 bits of encryption strength TLS- KTS SP 800-38D and SP 800-38F. KTS (key 128 and 256-bit keys AES-GCM/A4153 KTS wrapping and unwrapping) per IG D.G, providing 128 or 256 bits of AES-CCM/A4153 Additional Comment 8. encryption strength AES-CBC/A4153 HMAC/A4153 SSHv2- KTS SP 800-38D and SP 800-38F. KTS (key 128, 192, 256-bit keys AES-GCM/A4153 KTS wrapping and unwrapping) per IG D.G, providing 128, 192, or 256 AES-CBC/A4153 Additional Comment 8. bits of encryption strength AES-CTR/A4153 HMAC/A4153 IPsec- KTS SP 800-38D and SP 800-38F. KTS (key 128, 192, 256-bit keys AES-GCM/A4153 KTS wrapping and unwrapping) per IG D.G, providing 128, 192, or 256 AES-CCM/A4153 Additional Comment 8. bits of encryption strength AES-CBC/A4153 HMAC/A4153 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. Algorithm/Function Use/Function DSA (disallowed) Digital Signature and Asymmetric Key Generation; PQG Gen, Key Pair Gen, Sig Gen RSA (disallowed) Key Encryption, Decryption using PKCS#1 v1.5 Hash DRBG w/ SHA2-224 or SHA2- Random Bit Generation

HMAC DRBG w/ SHA2-224 or SHA2- Random Bit Generation

AES/Triple‐DES KW (non‐compliant) Key wrapping [algorithm disabled by module in approved mode] Blowfish Encryption and Decryption [algorithm disabled by module in approved mode] Camellia 128/192/256 Encryption and Decryption [algorithm disabled by module in approved mode] CAST5 Encryption and Decryption [algorithm disabled by module in approved mode] DES Encryption and Decryption [algorithm disabled by module in approved mode] DES‐X Encryption and Decryption [algorithm disabled by module in approved mode] IDEA Encryption and Decryption [algorithm disabled by module in approved mode] RC2 Encryption and Decryption [algorithm disabled by module in approved mode] RC5 Encryption and Decryption [algorithm disabled by module in approved mode] SEED Encryption and Decryption [algorithm disabled by module in approved mode] Triple-DES Encryption and Decryption [algorithm disabled by module in approved mode] MD4 Message Digest [algorithm disabled by module in approved mode] MD5 Message Digest [algorithm disabled by module in approved mode] RIPEMD‐160 Message Digest [algorithm disabled by module in approved mode] Whirlpool Message Digest [algorithm disabled by module in approved mode] Triple‐DES MAC Message Digest [algorithm disabled by module in approved mode] HMAC‐MD5 Keyed Hash [algorithm disabled by module in approved mode] 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. Protocol Reference SSHv2 [IG D.F and SP 800‐135] TLS v1.0/v1.1/v1.2 [IG D.F, IG D.G and SP 800‐135] IPsec-v3 [RFC 4106, 5282, 7296] Table C- Security Relevant Protocols Used in Approved Mode Protocol Key Exchange Server/ Host Cipher Integrity Auth DTLS See TLS entry in this table. [IG D.G] SSHv2 ECDH‐SHA2‐NIST ECDSA AES-GCM-128 HMAC SHA-1 [IG D.F and P521, P‐521, AES-GCM-256 HMAC SHA2‐256 SP 800‐135] ECDH‐SHA2‐NIST ECDSA AES-CBC-128 HMAC SHA2‐512 P384, P‐384, AES-CBC-192 AES-GCM-128 ECDH‐SHA2‐NIST AES-CBC-256 AES-GCM-256 ECDSA P‐256, P256, AES-CTR-128 DIFFIE‐HELLMAN RSA AES-CTR-192 GROUP14‐SHA1, AES-CTR-256 DIFFIE‐HELLMAN GROUP14‐SHA256, DIFFIE‐HELLMAN GROUP16‐SHA512 TLS TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE RSA AES‐GCM-128 AES‐GCM-128 [IG D.G and SP 800‐135] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS v1.0, v1.1, v1.2 ECDHE RSA AES-GCM-256 AES-GCM-256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES‐GCM‐128 AES‐GCM‐128 Arista Networks Inc. Public Material

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

Arista Networks Inc. Protocol Key Exchange Server/ Host Cipher Integrity Auth TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES‐GCM‐256 AES‐GCM‐256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CCM-256 AES-CCM-256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CCM-256 AES-CCM-256 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CCM-128 AES-CCM-128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CCM-128 AES-CCM-128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CBC-256 HMAC SHA2-384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CBC-128 HMAC SHA2-256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CBC-256 HMAC SHA-1 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE ECDSA AES-CBC-128 HMAC SHA-1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE RSA AES-CBC-128 HMAC SHA2-256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256 for TLS v1.0, v1.1, v1.2 ECDHE RSA AES-CBC-256 HMAC SHA2-256 Arista Networks Inc. Public Material

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

Arista Networks Inc. Protocol Key Exchange Server/ Host Cipher Integrity Auth TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE RSA AES-CBC-256 HMAC SHA-1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 ECDHE RSA AES-CBC-128 HMAC SHA-1 TLS_DHE_RSA_WITH_AES_256_CCM_8 for TLS v1.0, v1.1, v1.2 DHE RSA AES-CCM-256 AES-CCM-256 TLS_DHE_RSA_WITH_AES_256_CCM for TLS v1.0, v1.1, v1.2 DHE RSA AES-CCM-256 AES-CCM-256 TLS_DHE_RSA_WITH_AES_128_CCM_8 for TLS v1.0, v1.1, v1.2 DHE RSA AES-CCM-128 AES-CCM-128 TLS_DHE_RSA_WITH_AES_128_CCM for TLS v1.0, v1.1, v1.2 DHE RSA AES-CCM-128 AES-CCM-128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS v1.0, v1.1, v1.2 DHE RSA AES-CBC-256 HMAC SHA2-256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLS v1.0, v1.1, v1.2 DHE RSA AES-CBC-128 HMAC SHA2-256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA for TLS v1.0, v1.1, v1.2 DHE RSA AES-CBC-256 HMAC SHA-1 TLS_DHE_RSA_WITH_AES_128_CBC_SHA for TLS v1.0, v1.1, v1.2 DHE RSA AES-CBC-128 HMAC SHA-1 IPsec-v3 diffie-hellman AES-GCM-128 AES-GCM-128 MODP-2048, AES-GCM-192 AES-GCM-192 MODP-3072, AES-GCM-256 AES-GCM-256 MODP-4096, AES-CBC-128 HMAC-SHA2-256 Arista Networks Inc. Public Material

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

Arista Networks Inc. Protocol Key Exchange Server/ Host Cipher Integrity Auth MODP-6144, AES-CBC-192 HMAC-SHA2-384 MODP-8192 AES-CBC-256 HMAC-SHA2-512 ec diffie-hellman AES-CTR-128 AES-CCM-128 secp256r1, AES-CTR-192 AES-CCM-192 secp384r1, AES-CTR-256 AES-CCM-256 secp521r1 AES-CCM-128 AES-CCM-192 AES-CCM-256 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”.

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. Physical Port Logical Interface Data that passes over the interface N/A Data Input API input parameters for data N/A Data Output API output parameters for data N/A Control Input API function calls Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. N/A Status Output API return codes, error messages, logging messages 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 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. Role Service Input Output CO Authenticated Decryption Ciphertext, authentication tag, key, IV Plaintext CO Authenticated Encryption Plaintext, key, IV Ciphertext, authentication tag CO Decryption Ciphertext, key Plaintext CO Encryption Plaintext, key Ciphertext Arista Networks Inc. Public Material

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

Arista Networks Inc. Role Service Input Output CO Key Derivation (TLS) PRF algorithm, TLS master secret Derived Keys CO Key Derivation (SSH) PRF algorithm, SSH shared secret Derived Keys CO Key Derivation (IKE) PRF algorithm, IKE shared secret Derived Keys CO Key Derivation (SP 800-108r1) Shared secret, key size Derived Keys CO Key Encapsulation RSA keypair, keying material to Encapsulated key encapsulate CO Key Generation Algorithm, key size Key Pair CO Key Un-encapsulation RSA keypair, keying material to un- Un-encapsulated key encapsulate CO Key Verification Key to verify Return codes and log messages CO Initialize Crypto Officer Password None CO Message Authentication Message, Algorithm, key Message Authentication code Generation CO Message Digest Message Digest of the message CO On-Demand Integrity Test None Result of test (pass/fail) CO On-Demand self-test None Result of self-test (pass/fail) CO Random number generation Size Random bytes CO Shared secret computation EC Curve or DH parameters, V's public Shared secret key CO Show Status None Return code of 1 indicates approved mode enabled, 0 is disabled CO Show Version None String indicating the module version and name CO Signature Generation Message, hash algorithm, private key Signature CO Signature Verification Message, Signature, hash algorithm, Verification result public key CO Zeroise Context containing SSPs None Table 13

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

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. Role Authentication Method Authentication Strength CO (Crypto Password 95^16 (module enforces 16 Officer) character minimum password 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 functions. Service Description Approved Keys/SSPs Roles Access rights Indicator Security to Keys/SSPs Functions Authenticated Authenticated AES-GCM, AES key CO W, E Return code 1, log Decryption Decryption AES-CCM message indicating approval Authenticated Authenticated AES-GCM, AES key CO W, E Return code 1, log Encryption Encryption AES-CCM message indicating approval Decryption Decryption AES CBC, CTR, AES key CO W, E Return code 1, log ECB, CFB1, message indicating CFB128, CFB8, approval XTS Encryption Encryption AES CBC, CTR, AES key CO W, E Return code 1, log ECB, CFB1, message indicating CFB128, CFB8, approval XTS Key Deriving TLS KDF TLS TLS CO TLS Return code 1, log Derivation keys 1.0/1/1/1.2 pre_master_secret; pre_master_secret message indicating (TLS) TLS master secret; - W, E; TLS approval TLS derived keys master secret - G, E; TLS derived keys G, R Key Deriving SSH KDF SSH v2 SSH shared secret; CO SSH shared Return code 1, log Arista Networks Inc. Public Material

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

Arista Networks Inc. Service Description Approved Keys/SSPs Roles Access rights Indicator Security to Keys/SSPs Functions Derivation keys SSH derived keys secret - W, E; message indicating (SSH) SSH derived key - approval G, R Key Deriving IKE KDF IKE v1, v2 IKE shared secret; CO IKE shared secret Return code 1, log Derivation keys IKE derived key - W, E; IKE message indicating (IKE) derived key - G, R approval Key Deriving keys KDF SP800-108 Shared secret; 800- CO Shared secret - W, Return code 1, log Derivation 108 derived key E; 800-108 message indicating (SP 800- derived key - G, R approval 108r1) Key Key KTS-IFC RSA key pair, CO RSA key pair - W, Return code 1, log Encapsulation Encapsulation keying material E; keying material message indicating per SP 800- - W, R approval 56Br2 Key Generating Key ECDSA, RSA, ECDSA key pair; CO ECDSA key pair; Return code 1, log Generation pair DRBG RSA key pair RSA key pair - G, message indicating R; DRBG Seed, V, approval C, Key - W, E Key Un- Key Un- KTS-IFC RSA key pair, CO RSA key pair - W, Return code 1, log encapsulation encapsulation keying material E; keying material message indicating per SP 800- - W, R approval 56Br2 Key Verifying the ECDSA ECDSA public key CO W, E Return code 1, log Verification public key message indicating approval Initialize Initialize FIPS HMAC SHA-1 Crypto Officer CO Crypto Officer Return code 1 password using Password, Hashed Password - W, E; FIPS_set_pass Password Hashed Password word -E Message MAC AES CMAC, AES key; HMAC CO W, E Return code 1, log Authentication computation HMAC key message indicating Generation approval Message Generating SHS N/A CO N/A Return code 1, log Digest message digest message indicating approval On-Demand Initiate integrity HMAC SHA2- N/A (keys for self- CO N/A Return code 1 Integrity Test test on-demand 256 tests are not SSPs) through FIPS_check_inc ore_fingerprint On-Demand Initiate pre- AES, CMAC, N/A (keys for self- CO N/A Return code 1 self-test operational and DRBG, ECDSA, tests are not SSPs) Arista Networks Inc. Public Material

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

Arista Networks Inc. Service Description Approved Keys/SSPs Roles Access rights Indicator Security to Keys/SSPs Functions conditional HMAC, KASCAST self-tests ECC-SSC, through KAS-FFC-SSC, FIPS_selftest KDF, KTS, IKE KDF, RSA, SHS, TLS KDF, SSH KDF Random Generating DRBG DRBG Entropy CO DRBG Entropy Return code 1, log number random Input; DRBG Seed, Input - W, E; message indicating generation numbers V, C, Key DRBG Seed, V, C, approval Key - G, E Shared secret Calculating KAS-ECC-SSC, DH key pair; ECDH CO DH key pair - G, Return code 1, log computation Shared secret KAS-FFC-SSC, key pair; DRBG E, Z; ECDH key message indicating DRBG Seed, V Key; pair G, E, Z; approval Shared secret DRBG Seed, V, C, Key - W, E; Shared secret - G, R Show Status Show status of N/A N/A CO N/A N/A the module state using FIPS_mode Show Version Show the N/A N/A CO N/A N/A version of the module using FIPS_module_v ersion_text Signature Generating ECDSA, RSA, ECDSA key pair; CO W, E Return code 1, log Generation signature SHS RSA key pair message indicating approval Signature Verifying ECDSA, RSA, ECDSA key pair; CO W, E Return code 1, log Verification signature SHS RSA key pair message indicating approval Zeroise Zeroise SSP in N/A Context containing CO SSPs

• Z N/A volatile memory SSPs Table 15
• Approved services Service Indicator 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. Name Description Algorithms Role Indicator Accessed Decryption Decryption Blowfish, CO Return code 0, Camillia, CAST5, absence of DES, DES-X, approved log IDEA, RC2, message RC5, SEED, Triple-DES listed in Table 11 Encryption Encryption Blowfish, CO Return code 0, Camillia, CAST5, absence of DES, DES-X, approved log IDEA, RC2, message RC5, SEED, Triple-DES listed in Table 11 Key Wrapping Encrypting/Decry AES/Triple-DES CO Return code 0, pting key KW, RSA PKCS absence of #1 v1.5 listed in approved log Table 11 message Message Digest Hash MD4, MD5 CO Return code 0, computation outside TLS 1.0 absence of usage, RIPEMD- approved log 160, Whirlpool, message Triple-DES MAC, HMACMD5 listed in Table 11 Table E - Non-approved services Arista Networks Inc. Public Material

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

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.

Name Description Persistence Type RAM System Memory Dynamic 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.

Key/SSP/Name/ Strength Security Generation Import/Export Establishment Storage Zeroisation Use & related keys Type Function Cert Number 800-108 derived 128, 192, 256 A3592 SP 800-108 KDF N/A / Plaintext N/A Ephemeral in RAM OPENSSL_cleanse Derived for output to calling key application. Used with Shared Secret AES Key 128, 192, 256 A3592 External or KDF Plaintext / Plaintext KAS-ECC or Ephemeral in RAM OPENSSL_cleanse Authenticated Encryption, KAS-FFC Authenticated Decryption, Encryption, Decryption, Message Authentication Generation. Used with Shared Secret Crypto Officer N/A N/A N/A Plaintext / N/A N/A Ephemeral in RAM Automatic at end of Crypto Officer authentication. Password service call Used with Hashed Password Hashed N/A A3592 HMAC SHA-1 of N/A N/A Ephemeral in RAM Restart module Crypto Officer authentication. Password Crypto Officer Used with Crypto Officer Password Password DH key pair 112

• 200 A3592 Internal per SP 800- N/A / Public key in N/A Ephemeral in RAM DH_free Key agreement. Used with: DRBG 56Arev3 plaintext Seed, V, C, and Key, Shared Secret DRBG Entropy 384 A3592 External Plaintext / N/A N/A Ephemeral in RAM FIPS_DRBG_free Random number generation. Input Used with DRBG Seed, V, C, and Key DRBG Seed 256 A3592 From DRBG entropy N/A / N/A N/A Ephemeral in RAM FIPS_DRBG_free Random number generation. input; within SP 800- Used with DRBG Entropy Input 90A Hash_DRBG, and generated keys HMAC_DRBG, and CTR_DRBG DRBGs DRBG V 256 A3592 From DRBG entropy N/A / N/A N/A Ephemeral in RAM FIPS_DRBG_free Random number generation. input; within SP 800- Used with DRBG Entropy Input 90A Hash_DRBG, and generated keys HMAC_DRBG, and CTR_DRBG DRBGs DRBG C 256 A3592 From DRBG entropy N/A / N/A N/A Ephemeral in RAM FIPS_DRBG_free Random number generation. input; within SP 800- Used with DRBG Entropy Input 90A Hash_DRBG and generated keys DRBG Key 256 A3592 From DRBG entropy N/A / N/A N/A Ephemeral in RAM FIPS_DRBG_free Random number generation. input; within SP 800- Used with DRBG Entropy Input 90A HMAC_DRB, and and generated keys CTR_DRBG DRBGs Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Arista Networks Inc. Key/SSP/Name/ Strength Security Generation Import/Export Establishment Storage Zeroisation Use & related keys Type Function Cert Number ECDH key pair 128-256 A3592 Internal per SP 800- N/A / Public key in N/A Ephemeral in RAM EC_GROUP_free, Key agreement. Used with: DRBG 56Arev3 plaintext EC_POINT_free, Seed, V, C, and Key, Shared EC_KEY_free Secret ECDSA key pair 128, 192, 256 A3592 External or per FIPS Plaintext / Plaintext N/A Ephemeral in RAM EC_GROUP_free, Signature generation and 186-4 EC_POINT_free, verification. Used with DRBG EC_KEY_free Seed, V, C, and Key HMAC key 112 or greater A3592 External or KDF Plaintext / Plaintext KAS-ECC or Ephemeral in RAM HMAC_CTX_cleanup Message Authentication. Used KAS-FFC with Shared secret IKE shared 112 -256 A3592 N/A Plaintext / Plaintext KAS-ECC-SSC Ephemeral in RAM OpenSSL_cleanse KE key agreement. Used with IKE secret or KAS-FFC- derived key, DH key pair, ECDH SSC key pair IKE Derived 112 or greater A3592 KDF IKE N/A / Plaintext N/A Ephemeral in RAM OpenSSL_cleanse IKE key agreement Used with IKE key/AES & shared secret HMAC Keying material 112 or greater A3592 External Plaintext or Encrypted / KTS-IFC Ephemeral in RAM OpenSSL_cleanse KTS-IFC keying material to be Encrypted or Plaintext encapsulated or un-encapsulated by RSA-OAEP_basic. Used with RSA key pair RSA key pair 112, 128, 152 A3592 External or per FIPS Plaintext / Plaintext N/A Ephemeral in RAM RSA_free Signature generation and 186-4 verification or KTS-IFC. Used with DRBG Seed, V, C, and Key; and keying material to encapsulate/un-encapsulate Shared secret 112 or greater A3592 N/A Plaintext / Plaintext KAS-ECC-SSC Ephemeral in RAM OpenSSL_cleanse For key agreement. Used with DH or KAS-FFC- key pair, ECDH key pair SSC SSH shared 112 or greater A3592 N/A Plaintext / Plaintext KAS-ECC-SSC Ephemeral in RAM OpenSSL_cleanse SSH key agreement. Used with secret or KAS-FFC- SSH Derived key, DH key pair, SSC ECDH key pair SSH Derived 112 or greater A3592 KDF SSH N/A / Plaintext N/A Ephemeral in RAM OpenSSL_cleanse SSH key agreement Used with key/AES & SSH shared secret HMAC TLS Derived 112 or greater A3592 KDF TLS 1.0/1.1, 1.2 N/A / Plaintext N/A Ephemeral in RAM OpenSSL_cleanse TLS key agreement Used with key/AES & RFC7627 TLD master secret, TLS preHMAC master secret TLS master 112-256 A3592 From TLS pre-master Plaintext / Plaintext KAS-ECC-SSC Ephemeral in RAM OpenSSL_cleanse TLS key agreement Used with secret secret or KAS-FFC- TLS pre-master secret, TLS SSC Derived key TLS pre-master 112 - 256 A3592 N/A Plaintext / Plaintext KAS-ECC-SSC Ephemeral in RAM OpenSSL_cleanse TLS key agreement Used with secret or KAS-FFC- TLS master secret, TLS Derived SSC key 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. Algorithm Implement Test Test Type Indicator Test Details Tested ation Properties Method HMAC- 128-bit Compare SW Stdout, log Single SHA2-256 hardcoded Hash Integrity message encompassing key Results message authentication code Table G

• Pre-Operational Test Methods

Algorithm Implement Test Test Type Indicator Test Details Conditions Tested ation Properties Method AES AES-ECB 128 KAT CAST Stdout, Encrypt/ Power-up log Decrypt message AES AES-GCM 256 KAT CAST Stdout, Encrypt/ Power-up log Decrypt message AES AES-CCM 192 KAT CAST Stdout, Encrypt/ Power-up log Decrypt message AES AES-XTS 128, 256 KAT CAST Stdout, Encrypt/ Power-up log Decrypt message CMAC CMAC-AES 128, 192, KAT CAST Stdout, Generate/ Power-up

256 log Verify

message DRBG Counter Chained KAT CAST Stdout, SP 800-90A Power-up DRBG instantiate, log section 11.3 reseed, message health tests generate Arista Networks Inc. Public Material

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

Arista Networks Inc. Algorithm Implement Test Test Type Indicator Test Details Conditions Tested ation Properties Method DRBG Hash Chained KAT CAST Stdout, SP 800-90A Power-up DRBG instantiate, log section 11.3 reseed, message health tests generate DRBG HMAC Chained KAT CAST Stdout, SP 800-90A Power-up DRBG instantiate, log section 11.3 reseed, message health tests generate ECDSA P-224, P- KAT CAST Stdout, Sign/ Verify Power-up

message HMAC HMAC KAT CAST Stdout, Generate Power-up SHA2-224 log message HMAC HMAC KAT CAST Stdout, Generate Power-up SHA2-256 log message HMAC HMAC KAT CAST Stdout, Generate Power-up SHA2-512 log message IKE KDF KAT CAST Stdout, Derive Power-up log message KAS-ECC- P-224, P256 KAT CAST Stdout, Shared Power-up SSC log secret “z” message computation KAS-FFC- 2048 KAT CAST Stdout, Shared Power-up SSC log secret “z” message computation KBKDF Counter KAT CAST Stdout, Derive Power-up mode log message RSA 2048; PKCS KAT CAST Stdout, Sign/ Verify Power-up

SHA2-224, message SHA2-256, SHA2-384, SHA2-512 RSA KTS-IFC 2048 KAT CAST Stdout, Encrypt/ Power-up log Decrypt Arista Networks Inc. Public Material

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

Arista Networks Inc. Algorithm Implement Test Test Type Indicator Test Details Conditions Tested ation Properties Method message SHS SHA-1 KAT CAST Stdout, Generate Power-up log message SHS SHA2-224 KAT CAST Stdout, Generate Power-up log message SHS SHA2-256 KAT CAST Stdout, Generate Power-up log message SHS SHA2-384 KAT CAST Stdout, Generate Power-up log message SHS SHA2-512 KAT CAST Stdout, Generate Power-up log message SSH KDF KAT CAST Stdout, Derive Power-up log message TLS KDF KAT CAST Stdout, Derive Power-up log message ECDSA PCT CPCT N/A Sign/ Verify Generate Key Pair KAS-ECC- PCT CPCT N/A SP 800- Generate SSC 56Arev3 Key Pair assurance checks KAS-FFC- PCT CPCT N/A SP 800- Generate SSC 56Arev3 Key Pair assurance checks RSA PCT CPCT N/A Sign/ Verify Generate Key Pair 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.

Name Description Conditions Recovery Indicator Method Conditional Error Conditional test The module Error message is failure generates a new placed into the key and tests the error queue and key via a PCT. If an error is the test fails, an returned from the error is returned. API. PreOp Error Pre-operational The module is Error message is test failure aborted

• restart output on stderr. module 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).

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.

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. Abbreviation Full Specification Name Arista Networks Inc. Public Material

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

Arista Networks Inc. Abbreviation Full Specification Name [NIST] National Institute of Standards and Technology [FIPS140‐3] Security Requirements for Cryptographic Modules, March 22, 2019 [IG] Implementation Guidance for FIPS PUB 140‐3 and the Cryptographic Module Validation Program [ISO19790] Information technology

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

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

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

Arista Networks Inc. Table J - References Acronym Definition CO Cryptographic Officer role CloudEOS Name of the Arista operating system VA 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. Table K - Acronyms and Definitions Arista Networks Inc. Public Material

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