Arista Crypto Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Arista Crypto Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>status output</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
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>status output</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. FIPS 140-3 Security Policy Arista Networks, Inc. Arista Crypto Module August 8th, 2024 Document prepared by: http://www.lightshipsec.com Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table of Contents Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy List of Tables Table 3: Tested Module Identification

• Software/Firmware/Hybrid (Executable Code Sets) Table 4: Tested Module Identification
• Hybrid Disjoint Hardware Error! Bookmark not defined. Table 5: Tested Operational Environments - Software, Firmware, Hybrid .. Error! Bookmark not defined. Bookmark not defined. defined. List of Figures Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy

This non-proprietary FIPS 140-3 Security Policy for the Arista Cryptographic Module, v4.0 describes how the module meets the security requirements specified in FIPS 140-3 (Federal Information Processing Standard 140-3) for an overall security level 1 module and outlines the security rules and operating procedures required to maintain compliance.

Purpose and Use: The module is a dynamic software library providing an application programming interface (API) intended to be used via OpenSSL interfaces to serve cryptographic functionalities for applications running in the user space of the underlying operating system. Module Embodiment: Multi-Chip Standalone Module Characteristics: Cryptographic Boundary: The module’s cryptographic boundary (represented by the red dotted line in Figure 1) consists of the entire Arista Cryptographic Module executable code. Tested Operational Environment’s Physical Perimeter (TOEPP): Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy The module was tested on the Arista AWE-5510 router, running Arista’s EOS operating system. Figure 1: Block Diagram

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Tested Module Identification

• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Arista Networks Inc. Public Material
• May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid 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.

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

Arista Networks, Inc. FIPS 140-3 Security Policy There are no components excluded from the module’s cryptographic boundary or the FIPS security requirements.

Modes List and Description: Table 5: Modes List and Description The module is able to alternate between the approved and non-approved mode of operation based on service invocation. In the non-approved mode of operation, the module can offer Triple-DES encryption and decryption. When the Triple-DES encrypt and decrypt services are called, the module transitions to the non-approved state and a static return code of ‘0’, representing the invocation of a non-approved service is returned from the module.

Approved Algorithms: The table below lists the approved cryptographic algorithms of the module and implemented modes of operation of the algorithms. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 6: Approved Algorithms Vendor-Affirmed Algorithms: The vendor affirms the approved implementation of the following security methods: Table 7: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. The module does not implement any non-approved algorithms allowed in the approved mode of operation. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. The module does not implement any non-approved algorithms, allowed in the approved mode of operation, with no security claimed. Non-Approved, Not Allowed Algorithms: Table 8: Non-Approved, Not Allowed Algorithms

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

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy (1) (1) Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 9: Security Function Implementations

The following algorithm specific information applies to algorithms used by the module in the approved mode of operation. SHA-1: Per NIST SP 800-131A rev3, usage of the SHA-1 service as part of digital signature generation is disallowed in the approved mode of operation. AES-GCM: Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Per FIPS 140-3 IG C.H, the module implements deterministic IV construction as described in NIST SP 800-38D, section 8.2.1. The IV is constructed internally, and deterministically, with a length of 96 bits. The module provides the AES-GCM service to the calling application in a manner compatible with the TLS v1.2 protocol per RFC5246 and using cipher suites listed in section 3.3.1 or NIST SP 800-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 2^64-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 Module power is lost and restored the calling application must ensure that any AES GCM keys used for encryption or decryption are re-distributed. AES-XTS: Per NIST SP 800-38E, the module implements the AES-XTS algorithm. Per IG A.9, AES-XTS is to be used for storage applications only. The module performs the required key uniqueness check (Key_1 =/= Key_2) before processing data with the AES-XTS keys. The user shall enforce the length of the data unit used by any AES-XTS implementation does not exceed 2^20 blocks.

N/A for this module. N/A for this module. The module’s entropy source is located within the TOEPP, but outside the cryptographic boundary of the module. The module passively receives entropy based on request by the calling applications and exercises no control over the amount of quality of the obtained entropy. As such, there is No assurance of the minimum strength of generated SSPs (e.g., keys). By default, the module requests 256 bits of entropy per request.

When generating asymmetric keys, the module uses the direct output of its approved DRBG to generate random numbers and seeding material, per the guidance in NIST SP 800-133rev2, Section 5.

The module implements the following approved key agreement methods: Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy - KAS-ECC-SSC - NIST SP 800-56A Rev. 3 (FIPS 140-3 IG D.F, Scenario 2, Path (1) - KAS-FFC-SSC - NIST SP 800-56A Rev. 3 (FIPS 140-3 IG D.F, Scenario 2, Path (1) While the module implements the protocol-specific KDFs in support of key agreement operations, the module only offers cryptographic services at the API-level to calling applications and does not implement full key agreement within the module boundary. The module implements the following key transport method: - KTS-IFC – NIST SP 800-56B Rev. 2 (FIPS 140-3 IG D.G, Key Encapsulation/Unencapsulation) - AES Key wrapping using AES-KW and KWP (FIPS 140-3 IG D.G, Key Wrapping/Unwrapping)

The module implements approved cryptography to support the following industry-specific protocols: - IKEv1, IKEv2, SSH, TLS v1.2, MACsec However, the module only offers cryptographic services to calling applications and does not contain full implementations of industry protocols. No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 10: Ports and Interfaces As a software cryptographic toolkit, all of the module’s interfaces are defined at the Software/Firmware Module Interface (SFMI). The FIPS-defined logical interfaces are mapped to specific calls via a well-defined API, with which the operator interacts. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy The data output interface is inhibited when the module is performing self-tests, performing zeroisation, or while in an error state.

N/A for this module. The module does not implement an authentication mechanism. The operator role of Crypto Officer is assumed implicitly.

Table 11: Roles The module only supports 1 role: Crypto Officer (CO). This role is assumed implicitly by the operator when performing an approved service.

The module performs the following approves services: W,E G,R Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy G,R G,R W,E W,E 'V' W,E 'C' W,E G,E,Z W,E W,E Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy W,E W,E W,E W,E W,E G W,E W,E G Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy G,R G,R G,R G,R G,R G,R G,R Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy 'C' 'V' Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Z Z Z Z Z Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 12: Approved Services Table 13: Non-Approved Services

The module does not support loading of external software.

The module verifies the integrity of all software components within the cryptographic boundary using an HMAC-SHA2-256-based integrity technique. The module computes the HMAC digest of the entire software package that represents the module and compares the result against a stored pre-computed digest. The module’s pre-operational integrity check is performed automatically at module power-up. The module integrity check can be performed on demand by the module operator by rebooting Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy

The module is based on the open-source OpenSSL FIPS Provider, version 3.1.5. The module was built using the following open-source compiler: - GCC – Version 11.3.1 20221121 (Red Hat 11.3.1-4)

Type of Operational Environment: Modifiable How Requirements are Satisfied: The cryptographic module has control over its own SSPs. The EOSv4 operating system used by the module’s operational environment uses proper memory and process management to prevent unauthorized access to CSPs and uncontrolled modifications of SSPs while the module is in process space. The OS also ensures via process management that processes spawned by the module are owned by the module itself, and not by external processes/operators. The module does not persistently store SSPs.

The cryptographic module is a multi-chip standalone software module and does not include any physical components. Therefore, no physical security mechanisms or protections are implemented, and the section 7 requirements do not apply to the module.

The module does not claim any mitigations against non-invasive attacks. Additionally, there are no non-invasive attack mitigations outlined in Annex F of ISO/IEC 19790:2012. Therefore, the section 8 requirements do not apply to the module.

Table 14: Storage Areas Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy The table above lists the SSP storage areas implemented by the module. The module does not implement persistent storage of SSPs, and only stores keys temporarily in RAM, within the process space of the module. Table 15: SSP Input-Output Methods The table above lists the SSP Input-Output methods implemented by the module. The module only inputs or outputs SSPs using automated, electronic means to and from within the module TEOPP. Table 16: SSP Zeroization Methods The module does not persistently store keys; therefore, all keys are held in the module’s process space in volatile memory and are effectively zeroized upon reboot of the host platform. The zeroize API function can be invoked by the calling application and zeroizes all SSPs in the module storage space. The module supports the keys and other SSPs listed in the table below: Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy h Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy h Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy h t Table 17: SSP Table 1 Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 18: SSP Table 2

The module performs the following pre-operational self-test: Table 19: Pre-Operational Self-Tests The pre-operational integrity self-test is performed after the module is instantiated, but before the module transitions to the approved mode of operation. The HMAC-SHA2-256 CAST is performed conditionally, before the integrity test, and therefore before the first operational use of the algorithm. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy

The module performs the following conditional self-tests: Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 20: Conditional Self-Tests Conditional CASTs are performed at module initialization, after the module integrity test, and before the first operational use of the algorithms. Pairwise consistency tests are performed conditionally upon generation of an asymmetric keypair. guidance in IG 10.3.A, Resolution 7. Table 21: Pre-Operational Periodic Information Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)

Arista Networks, Inc. FIPS 140-3 Security Policy Table 22: Conditional Periodic Information The module can perform the periodic pre-operational, and conditional self-tests procedurally, on demand, by power cycling the host platform.

Table 23: Error States Failure of any module self-test will cause the module to set an internal flag and transition to the error state. In the error state, all cryptographic functions are inhibited. The data output interface is also inhibited when the module is in the error state. Any further requests to the module for cryptographic services will cause the module to return an error indicator. To recover from the error state, the host platform must be power cycled. Power cycling will cause the module to perform the pre-operational self-tests and transition to the approved mode of operation. Optional statement - If the module self-tests continue to fail after rebooting, the CO should contact Arista Networks, Inc. for assistance.

The module operator can initiate the pre-operational and conditional self-tests by power cycling the host platform.

The cryptographic module is distributed as part of Arista products, in the images accessible through the Arista software downloads portal. Products bundle together the operating system, applications, OpenSSL, and fips.so. While there is no need for the module to be built by the user at any point in time, it can be verified as the correct one by checking an unique version identifier, embedded into the module during the build process. The version identifier can be checked by issuing the following command: objcopy --dump-section .rodata2=/dev/stdout $(openssl info -modulesdir)/fips.so && echo The output of the above command should be: e8271acdca4674621a29e55d83fdbfb8990fbeb56b1a6eaf34082e562e5261e1

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

Arista Networks, Inc. FIPS 140-3 Security Policy The module comes pre-configured on the Arista device and will perform approved services without any operator intervention.

The module only implements the crypto-officer role, which is implicitly assumed. Therefore, there is no separate guidance required for non-administrator usage of the module.

The module implements mitigations against 2 types of timing attacks against digital signature services. Digital signature timing attacks involve measuring either the total processing time of digital signature and RSA operations, or the differences in execution times of processes during cryptographic operations. The module implements mitigations against 2 types of timing attacks. Constant-time implementations: Constant-time implementations regulate the execution time deltas between cryptographic operations to prevent an attacker from reverse-engineering sensitive data or cryptographic keys during processing. Numeric blinding: Numeric blinding uses random values during RSA processing. Those values act as a blinding factor preventing the attacker from determining which operation has been called and what processed data was via measuring the total execution time of the cryptographic operation. Arista Networks Inc. Public Material – May be reproduced only in its original entirety (without revision)