Arista Networks 7280 Series Switches
Running EOS 4.28
Common Criteria Security Target
Version: 0.5
07/19/2023
Prepared By:
Acumen Security, LLC
2400 Research Blvd., Suite 395
Rockville, MD 20850
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 2 of 52
Table of Contents
1. Security Target (ST) Introduction 5
1.1 Security Target Reference 5
1.2 Target of Evaluation Reference 5
1.3 Target of Evaluation Overview 5
1.3.1 TOE Type 5
1.3.2 TOE Usage 5
1.3.3 TOE Major Security Features Summary 5
1.3.4 Operational Environment 6
1.4 Target of Evaluation Description 7
1.4.1 Target of Evaluation Architecture 8
1.4.2 Target of Evaluation Physical Boundary 9
1.4.3 Target of Evaluation Logical Boundary 9
1.4.3.1 Security Audit 10
1.4.3.2 Cryptographic Support 10
1.4.3.3 Identification and Authentication 10
1.4.3.4 Security Management 10
1.4.3.5 Protection of the TSF 10
1.4.3.6 TOE Access 10
1.4.3.7 Trusted Path/Channels 11
1.5 Excluded Functionality 11
2. Conformance Claims 12
2.1 Common Criteria Conformance Claims 12
2.2 Conformance to Protection Profiles 12
2.3 Conformance to Technical Decisions 12
2.4 Conformance to Security Packages 12
2.5 Conformance Claims Rationale 13
3. Security Problem Definition 13
3.1 Threats 13
3.2 Organizational Security Policies 15
3.3 Assumptions 15
4. Security Objectives 17
4.1 Security Objectives for the Operational Environment 17
5. Extended Components Definition 18
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 3 of 52
5.1 Extended Security Functional Components 18
5.2 Extended Security Functional Requirements Rationale 18
6. Security Requirements 18
6.1 Security Functional Requirements 18
6.1.1 Security Audit (FAU) 20
6.1.1.1 FAU_GEN.1 Audit Data Generation 20
6.1.1.2 FAU_GEN.2 User Identity Association 24
6.1.1.3 FAU_STG_EXT.1 Protected Audit Event Storage 24
6.1.2 Cryptographic Support (FCS) 24
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation 24
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment 24
6.1.2.3 FCS_CKM.4: Cryptographic Key Destruction 24
6.1.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
25
6.1.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) 25
6.1.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) 25
6.1.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) 25
6.1.2.8 FCS_RBG_EXT.1 Random Bit Generation 26
6.1.2.9 FCS_SSHC_EXT.1 SSH Client Protocol (Selection Based) 26
6.1.2.10 FCS_SSHS_EXT.1 SSH Server Protocol (Selection Based) 27
6.1.2.11 FCS_TLSS_EXT.1 TLS Server Protocol without Mutual Authentication 27
6.1.2.12 FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication 28
6.1.3 Identification and Authentication (FIA) 28
6.1.3.1 FIA_AFL.1 Authentication Failure Management 28
6.1.3.2 FIA_PMG_EXT.1 Password Management 29
6.1.3.3 FIA_UIA_EXT.1 User Identification and Authentication 29
6.1.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism 29
6.1.3.5 FIA_UAU.7 Protected Authentication Feedback 29
6.1.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation (Selection Based) 29
6.1.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication 30
6.1.3.8 FIA_X509_EXT.3 X.509 Certificate Requests 30
6.1.4 Security Management (FMT) 30
6.1.4.1 FMT_MOF.1/Functions Management of Security Functions Behaviour 30
6.1.4.2 FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour 30
6.1.4.3 FMT_MTD.1/CoreData Management of TSF Data 31
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 4 of 52
6.1.4.4 FMT_MTD.1/CryptoKeys Management of TSF Data 31
6.1.4.5 FMT_SMF.1 Specification of Management Functions 31
6.1.4.6 FMT_SMR.2 Restrictions on Security Roles 31
6.1.5 Protection of the TSF (FPT) 32
6.1.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and
private keys) 32
6.1.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords 32
6.1.5.3 FPT_TST_EXT.1 TSF Testing 32
6.1.5.4 FPT_TUD_EXT.1 Trusted Update 32
6.1.5.5 FPT_STM_EXT.1: Reliable Time Stamps 32
6.1.6 TOE Access (FTA) 33
6.1.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking 33
6.1.6.2 FTA_SSL.3 TSF-initiated Termination 33
6.1.6.3 FTA_SSL.4 User-initiated Termination 33
6.1.6.4 FTA_TAB.1: Default TOE Access Banners 33
6.1.7 Trusted Path/Channels (FTP) 33
6.1.7.1 FTP_ITC.1 Inter-TSF Trusted Channel 33
6.1.7.2 FTP_TRP.1/Admin Trusted Path 33
6.2 Security Assurance Requirements 34
6.2.1 Security Assurance Requirements for the TOE 34
6.2.2 Security Assurance Requirements for the TOE 35
6.3 Rationale 35
7. TOE Summary Specification 35
7.1 Security Audit (FAU) 35
7.2 Cryptographic Support (FCS) 36
7.3 Identification and Authentication (FIA) 44
7.4 Security Management (FMT) 47
7.5 Protection of the TSF (FPT) 47
7.6 TOE Access (FTA) 50
7.7 Trusted Path/Channels (FTP) 50
8. Terms and Definitions 51
9. References 52
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 5 of 52
1. Security Target (ST) Introduction
1.1 Security Target Reference
The Security Target reference uniquely identifies the Security Target.
ST Title: Arista Networks 7280 Series Switches Running EOS 4.28
ST Version Number: Version 0.5
ST Date: 07/19/2023
Keywords: Network Device
1.2 Target of Evaluation Reference
The Target of Evaluation reference identifies the Target of Evaluation (TOE).
TOE Name: Arista Networks 7280 Series Switches Running EOS 4.28
TOE Developer: Arista Networks, Inc.
5453 Great America Parkway
Santa Clara, CA 95054
TOE Software Version: EOS 4.28
TOE Hardware: See Table 1
CC Identification: Common Criteria for Information Technology Security Evaluation, Version 3.1,
Revision 5, April 2017.
PP Identification: Collaborative Protection Profile for Network Devices, Version 2.2e, March 23,
2020.
1.3 Target of Evaluation Overview
1.3.1 TOE Type
The TOE is classified as a Network Device, that is, a device composed of both hardware and software that
is connected to the network and has an infrastructure role within the network.
1.3.2 TOE Usage
The Arista Networks Data Center and Cloud Computing Switches are networking switches (Network
Devices for CC purposes) that provide OSI model Layer 2, 3, and 4 Ethernet interconnectivity and network
management services (Data Link, Network, and Transport Layers, respectively). Each model of the TOE is
manufactured with high performance electronics, making it ideally suitable for a demanding data center
environment.
1.3.3 TOE Major Security Features Summary
• Security Audit
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 6 of 52
o Generates audit records, storing them locally and transmitting them to a remote audit
server.
o Supports secure communication to remote syslog-compatible audit servers protected by
the SSHv2 Trusted Channel.
• Cryptographic Support
o Utilization of NIST-specified and CAVP validated cryptographic algorithms for asymmetric
key generation, AES encryption/decryption, digital signature generation/verification,
hashing, and keyed-hashing (Message Authentication Code).
o Cryptographic-key Destruction using PP specified methods.
o Deterministic Random Bit Generation (DRBG).
o Assurance of seeding the DRBG with sufficient entropy (minimum of 256-bits of entropy).
• Identification and Authentication
o Administrative password management.
o Protected authentication data at the local and remote consoles.
o Identification and authentication of the Security Administrative user.
o X509 certificate-based authentication and validation.
o X509 certificate request generation.
• Security Management
o Trusted Update mechanism.
o Restriction of TSF management to the Security Administrator.
o Local and remote administration of the TOE by the Security Administrator.
• Protection of the TSF
o Protection of stored passwords.
o Prevention of disclosing passwords via normal management interfaces.
o Prevention of disclosing private keys via normal management interfaces.
o Automated self-testing upon boot-up.
o Querying of the TOE firmware/software.
o Reliable timestamps.
• TOE Access
o Session termination (TSF initiated, and User initiated).
o Display of a warning and consent banner on the local and remote management interfaces
prior to authentication.
• Trusted Path/Channels
o Cryptographically secure path between the TOE and the Security Administrative user for
remote management.
o Cryptographically secure channels between the TOE and authorized IT entities in the
Operational Environment to support the TSF.
1.3.4 Operational Environment
The TOE’s Operational Environment must provide the following services to support the secure operation
of the TOE in its evaluated configuration:
• Local Console Administrative Access
o RS-232 Serial Console.
o VT-100 terminal emulation program.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 7 of 52
• Remote Management
o The SSH client for remote interactive session utilizing SSH.
o The eAPI JSON-RPC Client capable of establishing a mutually authenticated TLS session.
• Audit Server
o The Syslog server capable of accepting an SSHv2 tunnel utilizing SSH Protocol Version 2
(SSHv2).
• Certificate Revocation List (CRL) Server
o The Server from where CRLs can be downloaded on the TOE to check validity of X509v3
certificates.
1.4 Target of Evaluation Description
The Arista 7280 series switches are fixed form factor switches. The 7280 series switches range in size
between 1 and 2 RU. The TOE'’ models vary in total throughput, port count, port speeds, route table scales
etc.
Each switch model runs Arista’s Linux-based network operating system called Extensible Operating
System (EOS). The same EOS binary image runs on all TOE hardware models. All EOS code is compiled to
the same i686 assembly, making it such that no processor runs anything different from any other
processor. All processors implement the i686 assembly language. All SFRs in this Security Target are
implemented by the EOS. Hence, they behave identically on every switch model.
The table below provides the list of appliances across different series:
Table 1: Hardware Appliances
Series Models Interfaces Host CPU
7280CR ● SKN-7280CR3-3C2 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-2 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-2-DEV 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-2G 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-3 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-3-DEV 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-3G 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-3C2-DEV 3x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C2 4x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C2-DEV 4x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C2G 4x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C6 3x100GbE (CFP2) + (9 or 10)x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C6-DEV 3x100GbE (CFP2) + (9 or 10)x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-4C6G 3x100GbE (CFP2) + (9 or 10)x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-5C2 5x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-5C2-DEV 5x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
● SKN-7280CR3-5C2G 5x100GbE (CFP2) + 2x100GbE Intel Broadwell-DE D1519
7280SR ● SKN-7280SR3-16YC8
4x CFP2 100G/200G + 4x 40/100G
QSFP + 16x 25/10GbE SFP
Intel Broadwell-DE D1519
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 8 of 52
The TOE supports local administration via the local console port. Remote administration is performed over
the Secure Shell v2 (SSHv2) protocol. Alternatively, the switch supports eAPI JSON-RPC interface over TLS
for remote automation scripts to perform management functions on the switch. This interface supports
only JSON request/response format. The eAPI interface supports both interactive and non-interactive
modes of operation. In interactive mode, a user can issue commands and receive immediate feedback
from the device. This allows for quick testing and debugging of eAPI scripts and applications, as well as ad
hoc configuration and monitoring tasks.
In non-interactive mode, the user can use a third-party eAPI JSON-RPC client, such as Ansible, Python
requests library, or cURL, to send eAPI requests and receive responses from the device. In the evaluated
configuration, the switch only supports eAPI non-interactive mode over TLS for remote automation scripts
to perform management functions on the switch.
The TOE also supports storage and forwarding of audit records, protected using SSHv2, to any syslog-
compatible network entity.
1.4.1 Target of Evaluation Architecture
The EOS includes subsystems designed to implement operational, security, management and networking
functions. The EOS contains management interface subsystem comprising of applications that implement
Serial Console, eAPI and SSH. This subsystem utilizes APIs, which are provided by the Crypto Module to
implement cryptographic algorithms. The keys and the certificates database support operation of
cryptographic algorithms. The AAA subsystem maintains administrative user credentials, which the
management subsystem relies on to identify and authenticate the users. The Audit Agent creates audit
logs on relevant events, sends them to remote audit server utilizing the services of SSH, and stores them
on local storage. The Config Database stores switch configuration. The Switching and Routing Engine
performs core function of the switch, which implements traffic forwarding logic. The rules generated by
this engine are programmed into line cards, which perform actual traffic forwarding function.
The TOE architecture and subsystem interactions are shown in Figure 1.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 9 of 52
Figure 1: TOE Architecture
1.4.2 Target of Evaluation Physical Boundary
The physical boundary of the TOE is a switch appliance of one of the models described in Table 1,
including all its hardware, firmware, software, local and remote management interfaces, and Arista
Extensible Operating System (EOS) version 4.28.
The TOE is delivered using a courier as a single device with the Arista EOS software installed. The TOE
model number can be verified through the shipping label and device front panel.
The switch appliance contains host CPU, DRAM and flash to run EOS. There are a fixed number of copper
or optical network ports on the appliance. The physical boundary of the TOE is the switch appliance as
shown in Figure 2.
Figure 2: Physical Boundary of 7280 Series Switch
1.4.3 Target of Evaluation Logical Boundary
The logical boundary of the TOE includes the security functions implemented exclusively by the TOE. These
security functions are summarized in Section 1.3.3 above and are further described throughout the
security target. A more detailed description of the implementation of these security functions are
provided in Section 7 “TOE Summary Specification”.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 10 of 52
1.4.3.1 Security Audit
• The TOE will audit all events and information defined in Table 7.
• The TOE will also include the identity of the user that caused the event (if applicable), date
and time of the event, type of event, and the outcome of the event.
• The TOE protects storage of audit information from unauthorized deletion.
• The TOE prevents unauthorized modifications to the stored audit records.
• The TOE can transmit audit data to an external IT entity using the SSHv2 protocol.
1.4.3.2 Cryptographic Support
The TOE implements CAVP validated cryptographic algorithms for the asymmetric key generation,
encryption/decryption, digital signature, integrity protection/verification and random bit generation.
These algorithms are used to provide security for the SSH and TLS connections of the Trusted Path and
Trusted Channel. The TOE implements the Arista EOS Crypto Module v2.0 which uses the underlying
OpenSSL FIPS Object Module 2.0.16 library for all cryptographic functions.
1.4.3.3 Identification and Authentication
• The TSF supports passwords consisting of alphanumeric and special characters. The TSF also
allows administrators to set a minimum password length and support passwords of 15
characters or greater.
• The TSF requires all administrative-users to authenticate before allowing the user to
perform any actions other than:
o Viewing the warning banner.
1.4.3.4 Security Management
• The TOE allows human users with the Security Administrator role to administer the TOE
over a remote console (SSH Trusted Path) and local CLI (Local Console).
• The eAPI JSON-RPC trusted IT entity client allows a machine user with the Security
Administrator role to administer the TOE over a remote TLS Trusted Channel.
These interfaces do not allow the Security Administrator to execute arbitrary commands or executables
on the TOE.
1.4.3.5 Protection of the TSF
• The TSF prevents the reading of secret keys, private keys, and passwords.
• The TOE runs a suite of self-tests, during the initial start-up (upon power on), and when
programs which utilize the cryptographic libraries are initialized, to demonstrate the correct
operation of the TSF.
• The TOE provides a means to verify firmware/software updates to the TOE using a published
hash prior to installing those updates.
• The TOE provides reliable time stamps for itself.
1.4.3.6 TOE Access
• The TOE, for local interactive sessions, terminates the session after Security Administrator-
specified period of session inactivity.
• The TOE terminates a remote interactive session after Security Administrator-configurable
period of session inactivity.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 11 of 52
• The TOE allows Administrator-initiated termination of the Administrator’s own interactive
session.
• Before establishing an administrative user session, the TOE is capable of displaying Security
Administrator-specified advisory notice and consent warning message regarding
unauthorized use of the TOE.
1.4.3.7 Trusted Path/Channels
• The TOE uses SSH or TLS to provide a trusted communication channel between itself and all
authorized IT entities that is logically distinct from other communication channels and
provides assured identification of its end points and protection of the channel data from
disclosure and modification.
• The TOE permits the TSF, or the authorized IT entities to initiate communication via the
trusted channel.
• The TOE permits remote administrators to initiate communication via the trusted path.
• The TOE requires the use of the trusted path for initial administrator authentication and all
remote administration actions.
1.5 Excluded Functionality
The following features should not be used in the CC evaluated configuration. They are disabled by default
(e.g., telnet) or require explicit additional configuration to make them work (e.g., integration with remote
authentication server). These have not been evaluated.
● Telnet management interface.
● HTTP and HTTPS web GUI management interface.
● Integration with external authentication server over RADIUS, TACACS+, and LDAP.
● Management interfaces for XMPP, Openconfig, CloudVision eXchange (CVX) and CloudVision
Portal (CVP).
● SNMP for management and notification.
● SMTP to post email notifications.
● Real-time streaming of switch state to remote server using `TerminAttr’ service.
● Remote configuration backup with CLI command.
● FTP server.
● Integration with orchestration services such as Puppet, Ansible, Chef, Prometheus etc. by
installing their agents on the switch.
The following features have also not been evaluated as their RFC-compliant implementations are unable
to satisfy cryptographic requirements outlined in the PP:
● Routing protocols that integrate authentication or encryption such as Routing Information
Protocol (RIPv1, RIPv2), Open Shortest Path First (OSPFv2), Border Gateway Protocol (BGP),
Intermediate System to Intermediate System (IS-IS), and Virtual Router Redundancy Protocol
(VRRP)
● The eAPI interface in interactive mode.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 12 of 52
2. Conformance Claims
2.1 Common Criteria Conformance Claims
This Security Target is conformant to the Common Criteria Version 3.1 R5, CC Part 2 extended, and CC
Part 3 conformant.
2.2 Conformance to Protection Profiles
This Security Target claims exact compliance to the collaborative Protection Profile for Network Devices,
Version 2.2e, dated March 23, 2020. This Protection Profile will be referred to as cPP or PP throughout
this Security Target.
2.3 Conformance to Technical Decisions
The TOE complies with the following Technical Decisions.
• 0738: NIT Technical Decision for Link to Allowed-With List
• 0638 – NIT Technical Decision for Key Pair Generation for Authentication
• 0636 – NIT Technical Decision for Clarification of Public Key User Authentication for SSH
• 0635 – NIT Technical Decision for TLS Server and Key Agreement Parameters
• 0631 – NIT Technical Decision for Clarification of public key authentication for SSH Server
• 0592 – NIT Technical Decision for Local Storage of Audit Records
• 0581 – NIT Technical Decision for Elliptic curve-based key establishment and NIST SP 800-56Arev3
• 0580 – NIT Technical Decision for clarification about use of DH14 in NDcPPv2.2e
• 0572 – NIT Technical Decision for Restricting FTP_ITC.1 to only IP address identifiers
• 0571 – NIT Technical Decision for Guidance on how to handle FIA_AFL.1
• 0570 – NIT Technical Decision for Clarification about FIA_AFL.1
• 0569 – NIT Technical Decision for Session ID Usage Conflict in FCS_DTLSS_EXT.1.7
• 0564 – NIT Technical Decision for Vulnerability Analysis Search Criteria
• 0563 – NIT Technical Decision for Clarification of audit date information
• 0556 – NIT Technical Decision for RFC 5077 question
• 0555 – NIT Technical Decision for RFC Reference incorrect in TLSS Test
• 0547 – NIT Technical Decision for Clarification on developer disclosure of AVA_VAN
• 0536 – NIT Technical Decision for Update Verification Inconsistency
• 0527 – NIT Technical Decision for Updates to Certificate Revocation Testing (FIA_X509_EXT.1)
Note: Technical decisions 0528, 0537, 0546, 0591, 0632, 0633, 0634, 0639, 0670 are not applicable to the
TOE.
2.4 Conformance to Security Packages
This Security Target does not claim conformance to any security function requirements or security
assurance requirements packages, neither as package-conformant or package-augmented.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 13 of 52
2.5 Conformance Claims Rationale
To demonstrate that exact conformance is met, this rationale shows all threats are addressed, all OSP are
satisfied, no additional assumptions are made, all objectives have been addressed, and all SFRs and SARs
have been instantiated.
The following address the completeness of the threats, OSP, and objectives, limitations on the
assumptions, and instantiation of the SFRs and SARs:
● Threats
o All threats defined in the cPP are carried forward to this ST.
o No additional threats have been defined in this ST.
● Organizational Security Policies
o All OSP defined in the cPP are carried forward to this ST.
o No additional OSPs have been defined in this ST.
● Assumptions
o All assumptions defined in the cPP are carried forward to this ST.
o No additional assumptions for the operational environment have been defined in this ST.
● Objectives
o All objectives defined in the cPP are carried forward to this ST.
● All mandatory and selection-based SFRs and SARs defined in the cPP are carried forward to this
Security Target.
Rationale presented in the body of this ST shows all assumptions on the operational environment have
been upheld, all the OSP are enforced, all defined objectives have been met and these objectives counter
the defined threats.
Additionally, all SFRs and SARs defined in the cPP have been properly instantiated in this Security Target;
therefore, this ST shows exact compliance to the cPP.
3. Security Problem Definition
3.1 Threats
The following table defines the security threats for the TOE, characterized by a threat agent, an asset, and
an adverse action of that threat agent on that asset. These threats are taken directly from the PP
unchanged.
Table 2: Threats
Threat Description
T.UNAUTHORIZED_ADMIN
ISTRATOR_ACCESS
Threat agents may attempt to gain administrator access to the network
device by nefarious means such as masquerading as an administrator to
the device, masquerading as the device to an administrator, replaying an
administrative session (in its entirety, or selected portions), or
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 14 of 52
performing man-in-the-middle attacks, which would provide access to
the administrative session, or sessions between network devices.
Successfully gaining administrator access allows malicious actions that
compromise the security functionality of the device and the network on
which it resides.
T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a
cryptographic exhaust against the key space. Poorly chosen encryption
algorithms, modes, and key sizes will allow attackers to compromise the
algorithms, or brute force exhaust the key space and give them
unauthorized access allowing them to read, manipulate and/or control
the traffic with minimal effort.
T.UNTRUSTED_COMMUNI
CATION_CHANNELS
Threat agents may attempt to target network devices that do not use
standardized secure tunneling protocols to protect the critical network
traffic. Attackers may take advantage of poorly designed protocols or
poor key management to successfully perform man-in-the-middle
attacks, replay attacks, etc. Successful attacks will result in loss of
confidentiality and integrity of the critical network traffic, and potentially
could lead to a compromise of the network device itself.
T.WEAK_AUTHENTICATIO
N_ENDPOINTS
Threat agents may take advantage of secure protocols that use weak
methods to authenticate the endpoints – e.g., shared password that is
guessable or transported as plaintext. The consequences are the same as
a poorly designed protocol, the attacker could masquerade as the
administrator or another device, and the attacker could insert
themselves into the network stream and perform a man-in-the-middle
attack. The result is the critical network traffic is exposed and there could
be a loss of confidentiality and integrity, and potentially the network
device itself could be compromised.
T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the
software or firmware which undermines the security functionality of the
device. Non-validated updates or updates validated using non-secure or
weak cryptography leave the update firmware vulnerable to
surreptitious alteration.
T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security
functionality of the network device without administrator awareness.
This could result in the attacker finding an avenue (e.g., misconfiguration,
flaw in the product) to compromise the device and the administrator
would have no knowledge that the device has been compromised.
T.SECURITY_FUNCTIONALI
TY_COMPROMISE
Threat agents may compromise credentials and device data enabling
continued access to the network device and its critical data. The
compromise of credentials includes replacing existing credentials with an
attacker’s credentials, modifying existing credentials, or obtaining the
administrator or device credentials for use by the attacker.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 15 of 52
T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak administrative
passwords to gain privileged access to the device. Having privileged
access to the device provides the attacker unfettered access to the
network traffic and may allow them to take advantage of any trust
relationships with other network devices.
T.SECURITY_FUNCTIONALI
TY_FAILURE
An external, unauthorized entity could make use of failed or
compromised security functionality and might therefore subsequently
use or abuse security functions without prior authentication to access,
change or modify device data, critical network traffic or security
functionality of the device.
3.2 Organizational Security Policies
The following table defines the organizational security policies which are a set of rules, practices, and
procedures imposed by an organization to address its security needs. These threats are taken directly
from the PP unchanged.
Table 3: Organizational Security Policies
OSP Description
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of
use, legal agreements, or any other appropriate information to
which users consent by accessing the TOE.
3.3 Assumptions
This section describes the assumptions on the operational environment in which the TOE is intended to
be used. It includes information about the physical, personnel, and connectivity aspects of the
environment. The operational environment must be managed in accordance with the provided guidance
documentation. The following table defines specific conditions that are assumed to exist in an
environment where the TOE is deployed. These assumptions are taken directly from the PP unchanged.
Table 4: Assumptions
Assumption Description
A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its
operational environment and not subject to physical attacks
that compromise the security and/or interfere with the device’s
physical interconnections and correct operation. This
protection is assumed to be sufficient to protect the device and
the data it contains. As a result, the cPP will not include any
requirements on physical tamper protection or other physical
attack mitigations. The cPP will not expect the product to
defend against physical access to the device that allows
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 16 of 52
Assumption Description
unauthorized entities to extract data, bypass other controls, or
otherwise manipulate the device.
A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its
core function and not provide functionality/services that could
be deemed as general-purpose computing. For example, the
device should not provide computing platform for general
purpose Applications (unrelated to networking functionality).
A.NO_THRU_TRAFFIC_PROTECTION A standard/generic network device does not provide any
assurance regarding the protection of traffic that traverses it.
The intent is for the network device to protect data that
originates on or is destined to the device itself, to include
administrative data and audit data. Traffic that is traversing the
network device, destined for another network entity, is not
covered by the ND cPP. It is assumed that this protection will be
covered by cPPs and PP-modules for particular types of
network devices (e.g., firewall).
A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device are
assumed to be trusted and to act in the best interest of security
for the organization. This includes appropriately trained,
following policy, and adhering to guidance documentation.
Administrators are trusted to ensure passwords/credentials
have sufficient strength and entropy and to lack malicious
intent when administering the device. The Network Device is
not expected to be capable of defending against a malicious
Administrator that actively works to bypass or compromise the
security of the device.
For TOEs supporting X.509v3 certificate-based authentication,
the Security Administrator(s) are expected to fully validate
(e.g., offline verification) any CA certificate (root CA certificate
or intermediate CA certificate) loaded into the TOE’s trust store
(aka 'root store', ' trusted CA Key Store', or similar) as a trust
anchor prior to use (e.g., offline verification).
A.REGULAR_UPDATES The network device firmware and software is assumed to be
updated by an administrator on a regular basis in response to
the release of product updates due to known vulnerabilities.
A.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the
network device are protected by the platform on which they
reside.
A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized
access possible for sensitive residual information (e.g.,
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 17 of 52
Assumption Description
cryptographic keys, keying material, PINs, passwords etc.) on
networking equipment when the equipment is discarded or
removed from its operational environment.
4. Security Objectives
4.1 Security Objectives for the Operational Environment
Table 5: Security Objectives for the Operational Environment
Objective Description
OE.PHYSICAL Physical security, commensurate with the value of the
TOE and the data it contains, is provided by the
environment.
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities
(e.g., compilers or user applications) available on the
TOE, other than those services necessary for the
operation, administration and support of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that
traverses it. It is assumed that protection of this traffic
will be covered by other security and assurance measures
in the operational environment
OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all
guidance documentation in a trusted manner.
For TOEs supporting X.509v3 certificate-based
authentication, the Security Administrator(s) are
assumed to monitor the revocation status of all
certificates in the TOE's trust store and to remove any
certificate from the TOE’s trust store in case such
certificate can no longer be trusted.
OE.UPDATES The TOE firmware and software is updated by an
administrator on a regular basis in response to the
release of product updates due to known vulnerabilities.
OE.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to
access the TOE must be protected on any other platform
on which they reside.
OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no
unauthorized access possible for sensitive residual
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 18 of 52
Objective Description
information (e.g., cryptographic keys, keying material,
PINs, passwords etc.) on networking equipment when
the equipment is discarded or removed from its
operational environment.
5. Extended Components Definition
5.1 Extended Security Functional Components
All extended components are sourced directly from NDcPP 2.2e.
5.2 Extended Security Functional Requirements Rationale
All extended security functional components are sourced directly from NDcPP 2.2e. Exact conformance
required by the cPP also mandates inclusion of all applicable extended components defined in the cPP.
6. Security Requirements
6.1 Security Functional Requirements
The following conventions have been applied in this document.
● Security Functional Requirements – Part 2 of the CC defines the approved set of operations that
may be applied to functional requirements: Iteration, assignment, selection, and refinement.
o Iteration: Allows a component to be used more than once with varying operations. In the
ST, iteration is indicated by a number in parenthesis following the requirement number,
e.g., FCS_COP.1.1(1).
o Assignment: Allows the specification of an identified parameter. Assignments made by
the ST author are identified with bold text.
o Selection: Allows the specification of one or more elements from a list. Selections are
identified with underlined text.
o Refinement: Allows the addition of details. Additions to the CC text are specified in
italicized bold and underlined text. Refinements that add text use bold and italicized text
to identify the added text. Refinements that perform a deletion, identifies the deleted
text with strikeout, bold, and italicized text.
Note that operations already performed in the PP are not identified in this Security Target.
● Explicitly stated Security Functional Requirements (i.e., those not found in Part 2 of the CC)
are identified “_EXT” in the component name.)
The TOE security functional requirements are listed in Table 6. All SFRs are based on requirements defined
in Part 2 of the Common Criteria or defined in cPP.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 19 of 52
Table 6: Security Functional Requirements
SFR Description
FAU_GEN.1 Audit Data Generation
FAU_GEN.2 User Identity Association
FAU_STG_EXT.1 Protected Audit Event Storage
FCS_CKM.1 Cryptographic Key Generation (Refined)
FCS_CKM.2 Cryptographic Key Establishment (Refined)
FCS_CKM.4 Cryptographic Key Destruction
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SSHC_EXT.1 SSH Client
FCS_SSHS_EXT.1 SSH Server
FCS_TLSS_EXT.1 TLS Server Protocol without Mutual Authentication
FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication
FIA_AFL.1 Authentication Failure Management
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU.7 Protected Authentication Feedback
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.3 X.509 Certificate Requests
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 20 of 52
SFR Description
FMT_MOF.1/ManualUpdate Management of Security Functions Behavior
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.2 Restrictions on Security Roles
FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys)
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
FPT_STM_EXT.1 Reliable Time Stamps
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.4 User-initiated Termination
FTA_TAB.1 Default TOE Access Banners
FTP_ITC.1 Inter-TSF Trusted Channel
FTP_TRP.1/Admin Trusted Path
6.1.1 Security Audit (FAU)
6.1.1.1 FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
● Administrative login and logout (name of user account shall be logged if individual user
accounts are required for Administrators).
● Changes to TSF data related to configuration changes (in addition to the information that a
change occurred it shall be logged what has been changed).
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 21 of 52
● Generating/import of, changing, or deleting of cryptographic keys (in addition to the action
itself a unique key name or key reference shall be logged).
● Resetting passwords (name of related user account shall be logged).
● no other actions;
d) Specifically defined auditable events listed in Table 7.
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure)
of the event; and
b) For each audit event type, based on the auditable event definitions of the functional components
included in the cPP/ST, information specified in column three of Table 7.
Table 7: Auditable Events (Table 2 of cPP)
SFR Description
Additional Audit Record
Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_RBG_EXT.1 None. None.
FCS_SSHC_EXT.1 Failure to establish an SSH
session
Reason for failure.
FCS_SSHS_EXT.1 Failure to establish an SSH
session
Reason for failure.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 22 of 52
SFR Description
Additional Audit Record
Contents
FCS_TLSS_EXT.1 Failure to establish a TLS
session
Reason for failure.
FCS_TLSS_EXT.2 Failure to authenticate the
client
Reason for failure
FIA_AFL.1 Unsuccessful login attempts
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of the identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU_EXT.2 All use of the identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/Rev Unsuccessful attempt to
validate a certificate
Any addition, replacement or
removal of trust anchors in the
TOE’s trust store.
Reason for failure of certificate
validation.
Identification of certificates
added, replaced or removed as
trust anchor in the TOE’s trust
store.
FIA_X509_EXT.2 None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/Functions None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a
manual update
None.
FMT_MTD.1/CoreData None. None.
FMT_MTD.1/CryptoKeys None. None.
FMT_SMF.1 All management activities of
TSF data.
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 23 of 52
SFR Description
Additional Audit Record
Contents
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update; result of
the update attempt (success or
failure)
None.
FPT_STM_EXT.1 Discontinuous changes
to time - either Administrator
actuated or changed via an
automated process.
(Note that no continuous
changes to time need to
be logged. See also
application note on
FPT_STM_EXT.1)
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
success and failure (e.g., IP
address).
FTA_SSL_EXT.1 The termination of a local
session by the session locking
mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None.
FTA_SSL.4 The termination of an
interactive session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted
channel.
Termination of the trusted
channel.
Failure of the trusted channel
functions.
Identification of the initiator
and target of failed trusted
channels establishment
attempt.
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted
path.
Failure of the trusted path
functions.
None.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 24 of 52
6.1.1.2 FAU_GEN.2 User Identity Association
FAU_GEN.2.1
For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable
event with the identity of the user that caused the event.
6.1.1.3 FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel
according FTP_ITC.1.
FAU_STG_EXT.1.2
The TSF shall be able to store generated audit data on the TOE itself. In addition [
● The TOE shall consist of a single standalone component that stores audit data locally].
FAU_STG_EXT.1.3
The TSF shall [overwrite previous audit records according to the following rule: periodic audit log rotation
(delete the oldest log file)] when the local storage space for audit data is full.
6.1.2 Cryptographic Support (FCS)
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.1.1 (TD0638)
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key
generation algorithm:
● RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following:
FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;
● ECC schemes using ‘NIST curves’ [P-384] that meet the following: FIPS PUB 186-4, “Digital
Signature Standard (DSS)”, Appendix B.4;
● FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special Publication 800-
56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography” and [RFC 3526, RFC 7919].
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 (TD0580 and TD0581)
The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key
establishment method:
● RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as
specified in Section 7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1”;
● FFC Schemes using “safe-prime” groups that meet the following: ‘NIST Special Publication
800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography” and [groups listed in RFC 3526, groups listed in RFC 7919].
6.1.2.3 FCS_CKM.4: Cryptographic Key Destruction
FCS_CKM.4.1
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 25 of 52
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction
method
● For plaintext keys in volatile storage, the destruction shall be executed by a single overwrite
consisting of zeroes;
● For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of
an interface provided by a part of the TSF that:
o logically addresses the storage location of the key and performs a single-pass overwrite
consisting of zeroses
that meets the following: No Standard.
6.1.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1.1/DataEncryption
The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES
used in CBC, GCM mode and cryptographic key sizes 128 bits, 256 bits that meet the following: AES as
specified in ISO 18033-3, CBC as specified in ISO 10116, GCM as specified in ISO 19772.
6.1.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1/SigGen
The TSF shall perform cryptographic signature services (generation and verification) in accordance with a
specified cryptographic algorithm [
● RSA Digital Signature Algorithm and cryptographic key sizes (modulus) 2048 bits
● Elliptic Curve Digital Signature Algorithm and cryptographic key sizes 384 bits
that meet the following:
● For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1
v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature
scheme 2 or Digital Signature scheme 3.
● For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix
D, Implementing “NIST curves” [P-384]; ISO/IEC 14888-3, Section 6.4
6.1.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash
The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic
algorithm SHA-1, SHA-256, SHA-384, SHA-512 and message digest sizes 160, 256, 384, 512 bits that meet
the following: ISO/IEC 10118-3:2004.
6.1.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash
The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic
algorithm HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 and cryptographic key sizes 256, 384, and
512-bits and message digest sizes 256, 384, 512 bits that meet the following: ISO/IEC 9797-2:2011,
Section 7 “MAC Algorithm 2”.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 26 of 52
6.1.2.8 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1
The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC
18031:2011 using CTR_DRBG (AES).
FCS_RBG_EXT.1.2
The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from 1
platform-based noise source with a minimum of 256 bits of entropy at least equal to the greatest security
strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of the
keys and hashes that it will generate.
6.1.2.9 FCS_SSHC_EXT.1 SSH Client Protocol (Selection Based)
FCS_SSHC_EXT.1.1
The TSF shall implement the SSH protocol in accordance with: RFCs 4251, 4252, 4253, 4254, [5656, 6668,
8308 section 3.1, 8332].
FCS_SSHC_EXT.1.2 (TD0636)
The TSF shall ensure that the SSH protocol implementation supports the following user authentication
methods as described in RFC 4252: public key-based, no other method.
FCS_SSHC_EXT.1.3
The TSF shall ensure that, as described in RFC 4253, packets greater than 262,144 bytes in an SSH transport
connection are dropped.
FCS_SSHC_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and
rejects all other encryption algorithms: aes128-cbc, aes256-cbc.
FCS_SSHC_EXT.1.5
The TSF shall ensure that the SSH public-key based authentication implementation uses rsa-sha2-256,
ecdsa-sha2-nistp384 as its public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHC_EXT.1.6
The TSF shall ensure that the SSH transport implementation uses hmac-sha2-256, hmac-sha2-512 as its
data integrity MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHC_EXT.1.7
The TSF shall ensure that diffie-hellman-group14-sha1 and no other methods are the only allowed key
exchange methods used for the SSH protocol.
FCS_SSHC_EXT.1.8
The TSF shall ensure that within SSH connections the same session keys are used for a threshold of no
longer than one hour, and each encryption key is used to protect no more than one gigabyte of data. After
any of the thresholds are reached a rekey needs to be performed.
FCS_SSHC_EXT.1.9
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 27 of 52
The TSF shall ensure that the SSH client authenticates the identity of the SSH server using a local database
associating each host name with its corresponding public key and no other methods as described in RFC
4251 section 4.1.
6.1.2.10 FCS_SSHS_EXT.1 SSH Server Protocol (Selection Based)
FCS_SSHS_EXT.1.1
The TSF shall implement the SSH protocol in accordance with: RFCs 4251, 4252, 4253, 4254, [5656, 6668,
8308 section 3.1, 8332].
FCS_SSHS_EXT.1.2 (TD0631)
The TSF shall ensure that the SSH protocol implementation supports the following user authentication
methods as described in RFC 4252: public key-based, password-based.
FCS_SSHS_EXT.1.3
The TSF shall ensure that, as described in RFC 4253, packets greater than 262,144 bytes in an SSH transport
connection are dropped.
FCS_SSHS_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and
rejects all other encryption algorithms: aes128-cbc, aes256-cbc.
FCS_SSHS_EXT.1.5
The TSF shall ensure that the SSH public-key based authentication implementation uses rsa-sha2-256,
ecdsa-sha2-nistp384 as its public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6
The TSF shall ensure that the SSH transport implementation uses hmac-sha2-256, hmac-sha2-512 as its
MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7
The TSF shall ensure that diffie-hellman-group14-sha1 and no other methods are the only allowed key
exchange methods used for the SSH protocol.
FCS_SSHS_EXT.1.8
The TSF shall ensure that within SSH connections, the same session keys are used for a threshold of no
longer than one hour, and each encryption key is used to protect no more than one gigabyte of data. After
any of the thresholds are reached, a rekey needs to be performed.
6.1.2.11 FCS_TLSS_EXT.1 TLS Server Protocol without Mutual Authentication
FCS_TLSS_EXT.1.1
The TSF shall implement TLS 1.2 (RFC 5246) and reject all other TLS and SSL versions. The TLS
implementation will support the following ciphersuites:
● TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
● TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
● TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 28 of 52
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● and no other ciphersuites.
FCS_TLSS_EXT.1.2
The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.
FCS_TLSS_EXT.1.3
The TSF shall perform key establishment for TLS using RSA with key size 2048 bits; Diffie-Hellman groups
ffdhe2048, ffdhe3072, ffdhe4096.
FCS_TLSS_EXT.1.4
The TSF shall support session resumption based on session IDs according to RFC 4346 (TLS1.1) or RFC 5246
(TLS 1.2).
6.1.2.12 FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication
FCS_TLSS_EXT.2.1
The TSF shall support TLS communication with mutual authentication of TLS clients using X.509v3
certificates.
FCS_TLSS_EXT.2.2
When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the client
certificate is invalid. The TSF shall also [
● Not implement any administrator override mechanism
].
FCS_TLSS_EXT.2.3
The TSF shall not establish a trusted channel if the identifier contained in a certificate does not match an
expected identifier for the client. If the identifier is a Fully Qualified Domain Name (FQDN), then the TSF
shall match the identifiers according to RFC 6125, otherwise the TSF shall parse the identifier from the
certificate and match the identifier against the expected identifier of the client as described in the TSS.
6.1.3 Identification and Authentication (FIA)
6.1.3.1 FIA_AFL.1 Authentication Failure Management
FIA_AFL.1.1
The TSF shall detect when an Administrator configurable positive integer within 1 to 255 unsuccessful
authentication attempts occur related to Administrators attempting to authenticate remotely using a
password.
FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been met, the TSF shall prevent
the offending Administrator from successfully establishing a remote session using any authentication
method that involves a password until an Administrator defined time period has elapsed.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 29 of 52
6.1.3.2 FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1
The TSF shall provide the following password management capabilities for administrative passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”;
b) Minimum password length shall be configurable to between 1 and 32 characters.
6.1.3.3 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1
The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification
and authentication process:
● Display the warning banner in accordance with FTA_TAB.1;
● no other actions.
FIA_UIA_EXT.1.2
The TSF shall require each administrative user to be successfully identified and authenticated before
allowing any other TSF-mediated actions on behalf of that administrative user.
6.1.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1
The TSF shall provide a local password-based authentication mechanism to perform local administrative
user authentication.
6.1.3.5 FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1
The TSF shall provide only obscured feedback to the administrative user while the authentication is in
progress at the local console.
6.1.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation (Selection Based)
FIA_X509_EXT.1.1/Rev
The TSF shall validate certificates in accordance with the following rules:
● RFC 5280 certificate validation and certificate path validation supporting a minimum path
length of three certificates.
● The certificate path must terminate with a trusted CA certificate designated as a trust anchor.
● The TSF shall validate a certification path by ensuring that all CA certificates in the certification
path contain the basicConstraints extension with the CA flag set to TRUE.
● The TSF shall validate the revocation status of the certificate using a Certificate Revocation
List (CRL) as specified in RFC 5280 Section 6.3.
● The TSF shall validate the extendedKeyUsage field according to the following rules:
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 30 of 52
o Certificates used for trusted updates and executable code integrity verification shall
have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication purpose (id-
kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication purpose (id-
kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP Certificates presented for OCSP responses shall have the OCSP Signing purpose
(id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the
CA flag is set to TRUE.
6.1.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for TLS, and no
additional uses.
FIA_X509_EXT.2.2 (TD0537)
When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall not
accept the certificate.
6.1.3.8 FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3.1
The TSF shall generate a Certificate Request as specified by RFC 2986 and be able to provide the following
information in the request: public key and Common Name, Organization, Organizational Unit, Country.
FIA_X509_EXT.3.2
The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate
Response.
6.1.4 Security Management (FMT)
6.1.4.1 FMT_MOF.1/Functions Management of Security Functions Behaviour
FMT_MOF.1.1/Functions
The TSF shall restrict the ability to modify the behaviour of the functions transmission of audit data to
an external IT entity to Security Administrators.
6.1.4.2 FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour
FMT_MOF.1.1/ManualUpdate
The TSF shall restrict the ability to enable the functions to perform manual updates to Security
Administrators.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 31 of 52
6.1.4.3 FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1.1/CoreData
The TSF shall restrict the ability to manage the TSF Data to Security Administrators.
6.1.4.4 FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_MTD.1.1/CryptoKeys
The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators.
6.1.4.5 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 (TD0631)
The TSF shall be capable of performing the following management functions:
● Ability to administer the TOE locally and remotely;
● Ability to configure the access banner;
● Ability to configure the session inactivity time before session termination or locking;
● Ability to update the TOE, and to verify the updates using hash comparison capability prior to
installing those updates;
● Ability to configure the authentication failure parameters for FIA_AFL.1;
o Ability to manage the cryptographic keys;
o Ability to configure the cryptographic functionality;
o Ability to modify the behaviour of the transmission of audit data to an external IT
entity;
o Ability to configure thresholds for SSH rekeying;
o
o Ability to set the time which is used for time-stamps;
o Ability to manage the TOE's trust store and designate X509.v3 certificates as trust
anchors;
o Ability to import X.509v3 certificates to the TOE's trust store;
o Ability to manage the trusted public keys database.
6.1.4.6 FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1
The TSF shall maintain the roles:
● Security Administrator.
FMT_SMR.2.2
The TSF shall be able to associate users with roles.
FMT_SMR.2.3
The TSF shall ensure that the conditions:
● The Security Administrator role shall be able to administer the TOE locally;
● The Security Administrator role shall be able to administer the TOE remotely
are satisfied.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 32 of 52
6.1.5 Protection of the TSF (FPT)
6.1.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric and
private keys)
FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys.
6.1.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1
The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext administrative passwords.
6.1.5.3 FPT_TST_EXT.1 TSF Testing
FPT_TST_EXT.1.1
The TSF shall run a suite of the following self-tests during initial start-up (on power on), at the conditions
as specified by FIPS PUB 140-2 Section 4.9.2 to demonstrate the correct operation of the TSF: Power-up
self-tests: Integrity check of the cryptographic module and Known Answer Tests (KAT) of cryptographic
primitives, and conditional self-tests: Key generation pairwise consistency tests and continuous random
number generator testing.
6.1.5.4 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1
The TSF shall provide Security Administrators the ability to query the currently executing version of the
TOE firmware/software and no other TOE firmware/software version.
FPT_TUD_EXT.1.2
The TSF shall provide Security Administrators the ability to manually initiate updates to TOE
firmware/software and no other update mechanism.
FPT_TUD_EXT.1.3
The TSF shall provide means to authenticate firmware/software updates to the TOE using a published
hash prior to installing those updates.
6.1.5.5 FPT_STM_EXT.1: Reliable Time Stamps
FPT_STM_EXT.1.1
The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 (TD0632)
The TSF shall allow the Security Administrator to set the time.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 33 of 52
6.1.6 TOE Access (FTA)
6.1.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1
The TSF shall, for local interactive sessions,
● terminate the session
after a Security Administrator-specified time period of inactivity.
6.1.6.2 FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1
The TSF shall terminate a remote interactive session after a Security Administrator-configurable time
interval of session inactivity.
6.1.6.3 FTA_SSL.4 User-initiated Termination
FTA_SSL.4.1
The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session.
6.1.6.4 FTA_TAB.1: Default TOE Access Banners
FTA_TAB.1.1
Before establishing an administrative user session the TSF shall display a Security Administrator-specified
advisory notice and consent warning message regarding use of the TOE.
6.1.7 Trusted Path/Channels (FTP)
6.1.7.1 FTP_ITC.1 Inter-TSF Trusted Channel
FTP_ITC.1.1
The TSF shall be capable of using [SSH, TLS] to provide a trusted communication channel between itself
and authorized IT entities supporting the following capabilities: audit server, [eAPI JSON-RPC Client]
that is logically distinct from other communication channels and provides assured identification of its end
points and protection of the channel data from disclosure and detection of modification of the channel
data.
FTP_ITC.1.2
The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted
channel.
FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for transmitting audit records to audit
server.
6.1.7.2 FTP_TRP.1/Admin Trusted Path
FTP_TRP.1.1/Admin
The TSF shall be capable of using [SSH] to provide a communication path between itself and authorized
remote Administrators that is logically distinct from other communication paths and provides assured
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 34 of 52
identification of its end points and protection of the communicated data from disclosure and provides
detection of modification of the channel data.
FTP_TRP.1.2/Admin
The TSF shall permit remote Administrators to initiate communication via the trusted path.
FTP_TRP.1.3/Admin
The TSF shall require the use of the trusted path for initial Administrator authentication and all remote
administration actions.
6.2 Security Assurance Requirements
6.2.1 Security Assurance Requirements for the TOE
This section defines the assurance requirements for the TOE. The assurance activities to be performed by
the evaluator are defined in cPP and are derived from Common Criteria Version 3.1, Revision 5. The
assurance requirements are summarized in the table below.
Table 8: Assurance Requirements
Assurance Class Assurance Component
Security Target (ASE) Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives for the operational environment
(ASE_OBJ.1)
Stated security requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Development (ADV) Basic functional specification (ADV_FSP.1)
Guidance documents (AGD) Operational user guidance (AGD_OPE.1)
Preparative procedures (AGD_PRE.1)
Life cycle support (ALC) Labeling of the TOE (ALC_CMC.1)
TOE CM coverage (ALC_CMS.1)
Tests (ATE) Independent testing – conformance (ATE_IND.1)
Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1)
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 35 of 52
6.2.2 Security Assurance Requirements for the TOE
This ST conforms to the [NDcPP], which draws from the CC Security Assurance Requirements (SARs) to
frame the extent to which the evaluator assesses the documentation applicable for the evaluation and
performs independent testing.
6.3 Rationale
This ST claims exact conformance to cPP. Therefore:
● All secure usage assumptions, organizational security policies, and threats are completely
covered by security objectives.
● Each objective counters or addresses at least one assumption, organizational security policy,
or threat.
● The set of components (requirements) in the ST are internally consistent and complete.
7. TOE Summary Specification
This section provides evaluators and potential consumers of the TOE with a high-level description of each
SFR, thereby enabling them to gain a general understanding of how the TOE is implemented. These
descriptions are intentionally not overly detailed, thereby disclosing no proprietary information. These
sections refer to SFRs defined in Section 6, Security Requirements.
The TOE consists of the following Security Functions:
● Security Audit
● Cryptographic Support
● Identification and Authentication
● Security Management
● Protection of the TSF
● TOE Access
● Trusted Path/Channels
7.1 Security Audit (FAU)
FAU_GEN.1, FAU_GEN.2
The TSF generates audit records of security relevant events using Linux rsyslog daemon. Individual
processes write messages to the rsyslog daemon interface as soon as their events happen. The messages
describe the events and their severity. When the AAA or CLI modules write their messages, they add the
subject identity, i.e., username, to the messages whenever applicable. The rsyslog daemon adds time
stamps to the messages from the system clock and routes them as soon as it receives them. There are
two targets specified for rsyslog daemon to route messages to: local Flash and connection endpoint to
the remote audit server. Thus, the rsyslog daemon makes one copy of audit log on the local Flash memory
and sends another copy to the configured remote audit server as soon as they are generated. Each audit
record generated by the TSF includes the date and time stamp of when the event that generated the audit
record occurred, type, subject identity (IP address, hostname, and/or username), the outcome (success
or failure), and any additional information specified in Table 7.
The following security relevant events are logged:
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 36 of 52
● Start-up and shut-down of the audit functions:
○ The auditing functions can be stopped with the “no logging on” CLI command and started with
the “logging on” CLI command.
● All of the following administrative action events:
o Administrative login and logout
▪ The name of the user account is included in the audit records.
o Security related configuration changes
▪ In addition to the information that a change occurred, what has been changed is included
in the audit records.
o Changes to cryptographic keys performed by security administrators:
▪ Generating SSH key pair. The same key pair is used by both SSH server and client.
▪ Generating key pair for Certificate Signing Request (CSR).
▪ Importing of new TLS server certificate.
In each of the above cases, SHA-256 hash of the public key or the certificate file is included in
the audit log to uniquely identify them.
o Resetting passwords
▪ These audit records include the name of related user account.
● Specifically defined auditable events listed in Table 7.
FAU_STG_EXT.1
Audit logs generated by the TSF are stored locally in the persistent Flash memory. The maximum size for
the file storing the local audit logs is configurable. When the file exceeds its size limit, it is trimmed to
remove the oldest audit logs until the size drops below the configured threshold. Locally stored audit
records are protected from unauthorized viewing, modification and deletion by the file system’s
read/write permissions and a restrictive CLI which only allows identified, authorized and authenticated
administrative users read/write access. The Security Administrative user can delete the locally stored
audit records. Modification of the audit records other than deleting them is not supported.
The logs can also be sent to configured remote audit server in syslog format as soon as they are generated.
To protect the audit records in transit from the TOE to the remote audit server in the Operational
Environment, the TOE establishes a Trusted Channel between itself and the external audit server using
the SSHv2 protocol. The Trusted Channel is created when the TOE establishes an SSH session between
itself and the remote audit server with TCP port forwarding enabled. After the SSH session is established,
the TOE is configured by the Security Administrative user to forward all messages received by the syslog
process to the listening TCP port created by the SSH connection. This ensures that all audit traffic is
encapsulated and hence protected by the SSH connection.
7.2 Cryptographic Support (FCS)
The TOE contains Arista EOS Crypto Module v2.0 which uses the underlying OpenSSL FIPS Object Module
2.0.16 library for all cryptographic operations. The TSFs utilize CAVP validated cryptographic algorithms
listed in Table 9.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 37 of 52
Table 9: Cryptographic Algorithms
SFR Description Details Cert. #
FCS_CKM.1
Cryptographic Key
Generation
RSA schemes using
cryptographic key sizes of
2048-bit or greater that
meet the following: FIPS
PUB 186-4, “Digital
Signature Standard (DSS)”,
Appendix B.3
ECDSA schemes using
curve P-384 that meet the
following: FIPS PUB 186-4,
“Digital Signature Standard
(DSS)”, Appendix B.4
FFC Scheme using safe
primes that
meet the following:
RFC
3526, RFC 7919
Key Generation:
Public Key Exponent:
Random
Probable Primes with
Conditions:
Mod lengths: 2048
Primality Tests: C.2 or C.3
Curve: P-384
Secret Generation Mode:
Extra Bits, Testing
Candidates
Safe Primes Key
Generation
Safe Prime Groups:
ffdhe2048, ffdhe3072,
MODP-2048, MODP-3072,
#A2946
FCS_CKM.2
Cryptographic
Key
Establishment
RSA-based key
establishment schemes
RSA-based key
establishment schemes
that meet the
following: RSAES-
PKCS1-v1_5 as specified
in Section 7.2 of RFC
3447, “Public-Key
Cryptography
Standards (PKCS) #1: RSA
Cryptography
Specifications Version
2.1”;
Vendor Affirmed
FFC Schemes using “safe
prime” groups.
FFC Schemes using “safe-
prime” groups that meet
the following: ‘NIST
Special Publication 800-
56A Revision 3,
“Recommendation for
Pair-Wise Key
Establishment Schemes
Using Discrete Logarithm
KAS-FFC-SSC
#A2946
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 38 of 52
SFR Description Details Cert. #
Cryptography” and [RFC
3526, RFC 7919
FCS_COP.1/
DataEncryption
AES-CBC as specified in ISO
10116,
AES-GCM as specified in
ISO 19772
AES, Mode: CBC, GCM,
Direction: Decrypt and
Encrypt, Key Length: 128,
256
#A2946
FCS_COP.1/SigGen RSA schemes using
cryptographic key sizes of
2048-bit or greater that
meet the following: FIPS
PUB 186-4, “Digital
Signature Standard (DSS)”,
Section 5.5, using PKCS #1
v2.1 Signature Schemes
RSASSA-PSS
and/or
RSASSAPKCS1v1_5;
ISO/IEC 9796-2, Digital
signature scheme 2
or
Digital Signature scheme 3
ECDSA schemes using
curve P-384 that meet the
following: FIPS PUB 186-4,
“Digital Signature Standard
(DSS)”, Section 6 and
Appendix D,
Implementing “NIST
curves”
P-256, P-384, ISO/IEC
14888-3, Section 6.4
RSA Signature Generation
and signature verification
Type: PKCS1.5:
Modulo: 2048
SHA: SHA-1 or SHA-256 or
SHA-384 or SHA-512
ECDSA signature
generation and signature
verification.
Capabilities:
• Curve: P-384
• Hash Algorithm:
SHA2-256, SHA2-
384, SHA2-512
#A2946
FCS_COP.1/Hash SHS that meets ISO/IEC
10118-3:2004.
SHA
Bit-oriented Mode
Byte-oriented Mode
SHA-1 or
SHA-256 or
SHA-384 or
SHA-512
#A2946
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 39 of 52
SFR Description Details Cert. #
FCS_COP.1/
KeyedHash
HMAC that meets: ISO/IEC
9797-2:2011, Section 7
“MAC Algorithm 2”
HMAC-SHA2-256
HMAC-SHA2-384
HMAC-SHA2-512
Key Sizes < Block Size
Key Sizes > Block Size
Key Sizes = Block Size
#A2946
FCS_RBG_EXT.1
Random Bit
Generation
in accordance with ISO/IEC
18031:2011 using
CTR_DRBG (AES).
Counter DRBG, Mode:
AES-256 #A2946
FCS_CKM.1
The TSF supports generation of 2048-bit RSA asymmetric keys for eAPI TLS server authentication and for
the SSH client and the SSH server authentication. Additionally, ECDSA host keys may be used for the SSH
client and the SSH server authentication. The supported RSA scheme meets the FIPS PUB 186-4, Digital
Signature Standard (DSS), Appendix B.3 standard. The supported ECDSA scheme meets the FIPS PUB
186-4, Digital Signature Standard (DSS), Appendix B.4. The TSF generates the Diffie-Hellman asymmetric
keys for the session key establishment in accordance with SP 800-56a Rev3 for SSH and TLS sessions
according to RFC 3526 and RFC 7919.
FCS_CKM.2
The session keys for both SSH and TLS are generated with Diffie Hellman (DH) key exchange. The OpenSSL
library is used to perform DH operations of key pair generation and common secret computation using
values of DH prime and DH generator are as specified in SP 800-56a Rev3 and RFC 3526 and RFC 7919.
Depending on the TLS cipher suite used during a TLS communication, session keys for TLS are also
generated using RSA key establishment schemes that adhere to RSAES-PKCS1-v1_5, as specified in Section
7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version
2.1”.
FCS_CKM.4
The TOE destroys Critical Security Parameters (CSPs) when no longer required. The zeroization procedures
for different CSPs in the TOE are described in Table 10.
The private keys of RSA used during the SSH, and the TLS authentication are persisted in flash memory. If
a persistent key is removed or replaced by the Security Administrator, the old persistent key is zeroized
by a single direct overwrite consisting of zeroes.
The programmatic destruction of keys is carried out by using a specialized algorithm that overwrites the
file location with a successive random and all-zero patterns and then ensures that the key is destroyed by
reading it back. This is done before writing the new key to the file. This ensures that any updates to the
cryptographic key files (creation, modification, deletion) result in all previous key files being destroyed
prior to the new values being written. As such, there is no delay in the destruction of keys. At the physical
layer, non-volatile memory is implemented on the TOE by either eUSB, eMMC, or SSD devices. These non-
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 40 of 52
volatile memory devices have written endurance of at least 17 TB, which under normal usage are expected
to last the lifetime of the device. In the unlikely event that there is a write-failure the issue will be reported
in the logging system. In such circumstances it is recommended to replace the media and physically
destroy the faulty non-volatile memory device.
The DH keys and the session keys of TLS and SSH are ephemeral keys, and they are stored in the TOE’s
RAM device. They are zeroized by a single direct overwrite consisting of zeroes, by the time the
corresponding TLS or SSH session terminates.
Table 10: CSPs
CSP Purpose Generation
Clearing
Method
When cleared
Storage
Location
TLS Server:
RSA Private
Key
“eAPI” server
authentication
Generated
internally when
TLS server is first
started or when
new key pair is
requested by
Security
Administrator
Single direct
overwrite
consisting of
zeroes
When replaced
by the Security
Administrator
Flash
TLS Server:
DH Private
Key
Establish
session keys for
TLS session
Generated
internally at the
start of TLS
session
Single direct
overwrite
consisting of
zeroes
When TLS
session keys
are derived
RAM
TLS Server:
Session Keys
Message
authentication
and encryption
in TLS session
Generated
internally at the
start of TLS
session
Single direct
overwrite
consisting of
zeroes
When TLS
session
terminates
RAM
SSH Server:
RSA Private
Key
SSH host
authentication
for remote
administrative
session
Generated
internally when
SSH service on
the TOE is first
started or when
new key pair is
requested by
Security
Administrator.
Single direct
overwrite
consisting of
zeroes
When replaced
by the Security
Administrator
Flash
SSH Server:
DH Private
Key
Establish
session keys for
SSH session
Generated
internally at the
start of SSH
session
Single direct
overwrite
consisting of
zeroes
When SSH
session keys
are derived
RAM
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 41 of 52
CSP Purpose Generation
Clearing
Method
When cleared
Storage
Location
SSH Server:
Session Keys
Message
authentication
and encryption
in SSH session
Generated
internally at the
start of SSH
session
Single direct
overwrite
consisting of
zeroes
When SSH
session
terminates
RAM
SSH Client:
RSA Private
Key
SSH client
authentication
to audit server
Generated
internally when
SSH service on
the TOE is first
started or when
new key pair is
requested by
Security
Administrator.
Single direct
overwrite
consisting of
zeroes
When replaced
by the Security
Administrator
Flash
SSH Client:
ECDSA
Private Key
SSH client
authentication
to audit server
Generated
internally when
SSH service on
the TOE is first
started or when
new key pair is
requested by
Security
Administrator.
Single direct
overwrite
consisting of
zeroes
When replaced
by the Security
Administrator
Flash
SSH Client:
DH Private
Key
Establish
session keys for
SSH session
Generated
internally at the
start of SSH
session
Single direct
overwrite
consisting of
zeroes
When SSH
session keys
are derived
RAM
SSH Client:
Session Keys
Message
authentication
and encryption
in SSH session
Generated
internally at the
start of SSH
session
Single direct
overwrite
consisting of
zeroes
When SSH
session
terminates
RAM
FCS_RBG_EXT.1
The TOE uses a platform-based CTR_DRBG (AES-256) random bit generator (DRBG) that complies with
NIST SP 800-90 for all cryptographic operations. Each DRBG instance is seeded with full 384 bits of entropy
(256 bits for AES key and 128 bits for nonce) sourced from Linux Random Number Generator (LRNG)
operating in a blocking mode (/dev/random). The LRNG accumulates entropy from the Infineon SLB9670
Trusted Platform Module. The detailed entropy justification is provided in [ENT].
FCS_SSHC_EXT.1
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 42 of 52
The TOE utilizes SSHv2 to support Trusted Channel to external audit server. The SSH implementation
conforms to the following RFCs:
● 4251 - The Secure Shell (SSH) Protocol Architecture
● 4252 - The Secure Shell (SSH) Authentication Protocol
● 4253 - The Secure Shell (SSH) Transport Layer Protocol
● 4254 - The Secure Shell (SSH) Connection Protocol
● 5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
● 6668 - SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
● 8332 - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
The TOE performs the role of SSH client in Trusted Channel. The TSF ensures that the SSH client
authenticates the identity of the audit server using the /etc/ssh/known_hosts file which associates each
server host name with its corresponding public key as described in RFC 4251. For this, the TSF compares
the received host key from the audit server during the SSH handshake and compares it to the keys
configured in the known_hosts file. If there is a match, the connection establishment process proceeds. If
there is no match found, the session is terminated. SSH client authenticates to the audit server using
public key.
The following public key scheme is supported: rsa-sha2-256 that uses 2048-bit RSA key and SHA-256
digital signature or ecdsa-sha2-nistp384.
The SSH client session keys are established using DH key exchange. The scheme supported is: diffie-
hellman-group14-sha1. It supports 2048-bit asymmetric keys (DH Group 14). It uses SHA-1 for exchange
hash. Exchange hash is the hashing method used to generate session keys hierarchy from the shared
secret derived from DH key establishment.
The encryption/decryption cipher supported is AES-CBC with 128 and 256 key lengths. The Message
authentication code supported are hmac-sha2-256 and hmac-sha2-512.
The TOE utilizes OpenSSH as the software for SSH client capabilities. OpenSSH employs a default maximum
packet size of 256 KB for SSH connections. Throughout the SSH connection establishment process,
OpenSSH actively monitors and validates the size of incoming packets. If a packet is found to exceed the
allowed size, OpenSSH will terminate the connection. This ensures compliance with the specified behavior
outlined in RFC 4253.
The TOE’s SSH client performs rekeying when 1 GB of SSH data has been sent, or after 1 hour of that
session being open. A counter in the SSH code keeps track of the sent SSH data packets. If the data counter
reaches 1 GB, or if the time counter reaches 1 hour, the TSF sends a ‘Key Exchange Init’ message to the
peer to initiate a new key-exchange negotiation. If the new key-exchange fails to establish a new key for
the session, the session is terminated by the TSF.
FCS_SSHS_EXT.1
The TOE utilizes SSHv2 to support a Trusted Path for remote administration session. The SSH server
implementation conforms to the following RFCs:
● 4251 - The Secure Shell (SSH) Protocol Architecture
● 4252 - The Secure Shell (SSH) Authentication Protocol
● 4253 - The Secure Shell (SSH) Transport Layer Protocol
● 4254 - The Secure Shell (SSH) Connection Protocol
● 5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
● 6668 - SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 43 of 52
● 8332 - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
The TOE performs the role of SSH server in Trusted Path. The SSH server in the TOE authenticates remote
administrative user using public key or password. The following public key scheme is supported: rsa-sha2-
256 that uses 2048-bit RSA key and SHA-256 digital signature or ecdsa-sha2-nistp384.
In the case that the TOE’s SSH server authenticates the SSH client using the public key mechanism. The
TSF ensures that the SSH server verifies the identity of the SSH client by utilizing the
"/etc/ssh/known_hosts" file, which associates each client host name with its corresponding public key as
specified in RFC 4251. To accomplish this, the TSF compares the host key received from the SSH client
during the SSH handshake with the keys configured in the known_hosts file. If a match is found, the
connection establishment process continues. However, if no match is found, the session is terminated.
In password-based authentication, once a user initiates a connection to the administration interface, they
are prompted to provide username and password credentials. After a user provides a username and
password, the TOE invokes a PAM (Pluggable Authentication Modules) AAA plugin.
The SSH session keys are established using DH key exchange. The scheme supported is: diffie-hellman-
group14-sha1. It supports 2048-bit asymmetric keys (DH Group 14). It uses SHA-1 for exchange hash.
Exchange hash is the hashing method used to generate session keys hierarchy from the shared secret
derived from DH key establishment.
The encryption/decryption cipher supported is AES-CBC with 128 and 256 key lengths. The Message
authentication code supported are hmac-sha2-256 and hmac-sha2-512.
The TOE utilizes OpenSSH as the software for SSH server capabilities. OpenSSH employs a default
maximum packet size of 256 KB for SSH connections. Throughout the SSH connection establishment
process, OpenSSH actively monitors and validates the size of incoming packets. Should a packet be
identified as exceeding the specified maximum size, OpenSSH adheres to the requirements outlined in
RFC 4253 and terminates the connection.
The TOE’s SSH server performs rekeying when 1 GB of SSH data has been sent, or after 1 hour of that
session being open. A counter in the SSH code keeps track of the sent SSH data packets. If the data counter
reaches 1 GB, or if the time counter reaches 1 hour, the TSF sends a ‘Key Exchange Init’ message to the
peer to initiate a new key-exchange negotiation. If the new key-exchange fails to establish a new key for
the session, the session is terminated by the TSF.
FCS_TLSS_EXT.1 and FCS_TLSS_EXT.2
The TOE allows for automated remote management of the TSF via the eAPI JSON-RPC (“eAPI”) interface.
The communication channel is protected by TLS TLSv1.2 with mutual authentication. The TOE
incorporates the nginx server to handle TLS connections. When configured to utilize the TLS version 1.2
option, the nginx server is explicitly set to exclusively accept TLS 1.2 protocols from the list of permitted
protocols. As a result, any attempts to establish a session using other TLS or SSL versions, including SSL
1.0, SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1, are categorically denied by the TSF. The following TLS ciphersuites
are supported:
● TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
● TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
● TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 44 of 52
The TOE acts as a TLS server to the eAPI TLS client in the operational environment. To support the TLS
server authentication to the eAPI client, the TSF needs to be configured with an RSA 2048-bit public-key
in the x.509v3 certificate format.
When the TSF is establishing a TLS session utilizing a ciphersuite with RSA key establishment (key
transport), the TSF only acts as the receiver of the encrypted pre-master secret. When the TSF is
establishing a TLS session utilizing a ciphersuite with DHE key establishment, the TSF supports ffdhe2048,
ffdhe3072, and ffdhe4096 safe primes per RFC 7919. The TSF sends public key from the pair to the peer
to facilitate pre-master secret establishment.
The TLS server supports authentication of the eAPI TLS client. The Security Administrator configures TLS
server with trusted CA certificate used to validate the eAPI TLS client certificate. The trusted CA certificate
is then associated to a Security Administrative user account. This particular administrative account is only
to be used by the eAPI. This is to ensure that there is no ambiguity when viewing the audit records as to
whether a human user’s action or the eAPI’s action generated the audit record. When eAPI TLS client
attempts to establish a session with the TSF, the TSF responds to the client by sending a
Certificate_Request message immediately after the ServerKeyExchange message is sent during the TLS
handshake. The client must send a Client_Certificate message containing an RSA 2048-bit public-key in
the x.509v3 certificate to authenticate the client to the TSF. The TSF validates the client certificate
according to FIA_X509_EXT.1.1, checks that it is signed by the trusted CA, checks the local CRL for the
revocation status of the client certificate. The TSF does not support an administrator override function,
if any of these x509 certificate validity checks fail, the session is terminated.
If the client certificate validity checks passes, the TSF checks to see if the CN value matches the username
of the account specifically configured for the eAPI client. If no match is found, TSF will terminate the
attempted session establishment. If a match is found, TSF allows the authentication process to complete
and the session to successfully establish. The TSF does not process SAN value in the client certificate.
The TLS server implements session resumption using session IDs according to RFC 5246 (TLS 1.2) without
any context.
The TOE provides support for password-based authentication as a fallback option. The availability of
fallback authentication depends on the configuration of the “secret” parameter in the “username”
command. If the “secret” parameter is configured with a password, fallback authentication is enabled. In
this case, the client can authenticate by providing their password instead of a client certificate. However,
if the “secret” parameter is configured with the “*” (asterisk) character, the fallback authentication is
disabled. In this scenario, the client will not be able to authenticate using their password.
7.3 Identification and Authentication (FIA)
FIA_AFL.1
Consecutive authentication failures result into temporary account lockout for remote administrative
user. The threshold number of failures between 1 and 255 and subsequent lockout period are
configured by Security Administrator when initializing the TOE. The RS-232/VT-100 local administrative
interface is never locked out.
FIA_PMG_EXT.1
The Security Administrator passwords are able to be composed of any combination of upper- and lower-
case letters, numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 45 of 52
Minimum length of the password is configurable by the Security Administrator between 1 and 32. It is
recommended to configure minimum length as at least 8.
FIA_UIA_EXT.1, FIA_UAU_EXT.2
The TSF provides a local administrative CLI interface over RS-232/VT-100 that supports password-based
authentication. It also provides remote administrative CLI interface over SSH that supports password-
based and public key-based authentication.
In password-based authentication, once a user initiates a connection to the administration interface, they
are prompted to provide username and password credentials. After a user provides a username and
password, the TOE invokes a PAM (Pluggable Authentication Modules) AAA plugin. This plugin is
configured to use the RBAC (Role Based Access Control) module. The AAA plugin passes the authentication
credentials to the RBAC module. The RBAC module checks the credentials against its database and then
responds with a SUCCESS or DENIED message. Based on the response from the RBAC module, the AAA
plugin then returns a SUCCESS or DENIED message to the requesting program. If the requesting program
receives a DENIED message, it prints an error message to the user and denies the login attempt. If the
requesting program receives a SUCCESS message, it makes an EXEC authorization request to the RBAC
module, which responds with the additional permissions for the CLI. At this point, authentication is
successful, and the user is presented with the CLI.
When RSA public key authentication is used with a remote SSH session, the SSH daemon performs the
initial authentication verification locally by comparing public key supplied by the client with
/home/<account>/.ssh/authorized_keys. Once the public key matches, the daemon performs an EXEC
authorization request to the RBAC module as detailed above.
The TSF also provides “eAPI” interface over TLS for remote automated configuration. The details of eAPI
authentication process are provided above in FCS_TLSS_EXT.2. After the authentication is successful, EXEC
authorization request is made to the RBAC module.
The TSF displays a warning banner (in accordance with FTA_TAB.1) on CLI prior to requiring identification
and authentication. This banner is not required to be, nor is it, presented to the eAPI JSON-RPC client prior
to it authenticating to the TSF.
FIA_UAU.7
The TSF does not echo back the characters that are entered when users attempt to authenticate to the
local console when using a password credential.
FIA_X509_EXT.1/Rev, FIA_X509_EXT.2, FIA_X509_EXT.3
The TOE performs the role of TLS server in eAPI trusted channel communication. Security Administrator
installs x.509v3 certificate in the TLS server. To facilitate this, Security Administrator first generates
certificate signing request (CSR). CSR causes generation of 2048-bit RSA private and public key pair in the
TOE. It encapsulates the public key, along with Common Name, Organization, Organizational Unit, and
Country information, in a format that can be submitted to certificate authority (CA) for creating signed
x.509v3 certificate. The security Administrator obtains the signed certificate from the CA and imports in
the TOE. Following conditions are checked at the time of import and the import is rejected if any of the
following conditions do not check:
● That the entire chain of certificates is imported. That is, the leaf TLS server certificate, any
intermediate certificates leading from the leaf up to the root and the root certificate are imported.
● That the current date and time lies between the “Valid from” and “Valid to” for each certificate.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 46 of 52
● That the basicConstraints extension is included with CA flag is set to TRUE for all CA certificates in
the chain
● That the extendedKeyUsage field in the leaf certificate has the Server Authentication purpose (id-
kp 1 with OID 1.3.6.1.5.5.7.3.1)
● That the digital signatures are correct in all certificates
● That none of the certificates from the leaf up to the root is revoked.
The above certificate chain is presented to the eAPI client at the beginning of TLS connection. This
facilitates the eAPI client to validate identity of the server.
At the time of establishing TLS connection, the eAPI client presents its x.509v3 certificate to the TLS server
in the TOE. This certificate is used by the TOE to authenticate the eAPI client. The TOE performs following
checks on the certificate presented by the eAPI client:
● That the certificate chain presented by the eAPI client can be traced to the CA certificate that is
lowest in the hierarchy of certificates imported into the TOE as described above. That is, this
lowest CA certificate acts as the trust anchor. Note that the trust anchor can be an intermediate
CA certificate or the root CA certificate.
● That the current date and time lies between the “Valid from” and “Valid to” for each certificate
from the leaf certificate in the chain presented by eAPI client up to and including the trust anchor.
● That the basicConstraints extension is included with CA flag is set to TRUE for all CA certificates in
the chain.
● That the extendedKeyUsage field in the leaf certificate in the chain presented by eAPI client has
the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2).
● That the digital signatures are correct in all certificates.
● That none of the certificates from the leaf up to the trust anchor is revoked. It is not necessary to
check revocation status of the trust anchor and other CA certificates upstream of the trust anchor.
● The x509 certificate must have the username as the CN attribute in the Subject field. This is to tie
the username to the allowed role in the TOE.
If any of the checks mentioned above fails, then the TLS connection is rejected.
The TOE does not provide support for code signing and OCSP signing attributes in the extendedKeyUsage
field of the leaf certificate when presented by the e-API client or when included in an x509 certificate
imported into its trusted store.
The TOE verifies the client identity of eAPI by inspecting the CN field in the presented x509 certificate
during the eAPI client connection. The connection of the eAPI client will be successful only if the CN field
matches a username configured in the TOE. Otherwise, the connection will be rejected.
In order to facilitate revocation checking on the eAPI client certificate chain as described above, Security
Administrator specifies Certificate Distribution Points (CDPs) during initial configuration of the TOE.
Security Administrator is required to specify CDPs for the CRLs published by the trust anchor and every
CA certificate between the trust anchor and the leaf certificate of the eAPI client. The TOE downloads
CRLs from the specified CDPs every configurable time period and stores the most recently fetched CRLs
locally. Digital signatures on downloaded CRLs are validated and in case of failure of signature verification,
CRL is not added to the local copy. The local copies of the CRLs are used for certificate revocation checking.
At the time of revocation checking, the TOE ensures that the current time lies within the validity period
of the CRL, that is between the effective date and the next update date mentioned in the CRL. The
certification revocation checking can fail either because the certificate is revoked as per the CRL or
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 47 of 52
because the recent CRL for the CA that issued the certificate is not present in the local copy to perform
the revocation checking.
7.4 Security Management (FMT)
FMT_MOF.1/Functions
See description under FAU_STG_EXT.1.
FMT_MOF.1/ManualUpdate
See description under FPT_TUD_EXT.1.
FMT_MTD.1, FMT_SMF.1, FMT_SMR.2
The TSF maintains the ‘Security Administrator’ role and allows that role to be associated to users of the
TOE. The Security Administrator role is enforced via the permission features of the base Linux kernel of
the EOS operating system. Users are associated with credentials for identification and role for
authorization to the TOE. In addition, users’ permissions are assigned and enforced by the base Linux
kernel filesystem of EOS via read/write/execute permissions and group policies that ensure that only
Security Administrative users can manage the TSF data. The TSF restricts the ability to manage (i.e. create,
view, initialize, modify/append, delete/clear, and change the default setting) of the TSF data to only
identified, authenticated and authorized Security Administrators.
The local console and remote management interfaces allow the Security Administrator to perform the
following TSF management functions:
● Administer the TOE locally and remotely
● Create the TOE access banner
● Set the session inactivity timeout values
● Verify and manually install firmware updates (verification using published hash)
● Configure failed login threshold and lockout period
● Generate, import, delete and configure cryptographic keys required by SSH and TLS
● Specify ciphersuites for SSH and TLS
● Configure syslog forwarding
● Set system time
● Import x.509v3 certificates in trust store
7.5 Protection of the TSF (FPT)
FPT_SKP_EXT.1
Refer to Table 10 for a list of private keys and symmetric keys. The TOE stores these keys in plaintext is
locations described for them in Table 10. The administrative interface does not provide a documented
command for any user to view any of the private or session keys. There are no pre-shared keys.
FPT_APW_EXT.1
The TSF does not store passwords in plaintext. The TSF uses SHA-512 hash (with a salt) protection to
ensure that any users’ password is not stored in plaintext. When a user authenticates to the TSF (local or
remote), the system generates a hash of the entered password and compares it against the stored hash
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 48 of 52
value of the password associated to the username provided to ensure that the plaintext password is not
disclosed.
FPT_TST_EXT.1
These following paragraphs describe the different types of self-tests in the context of a cryptographic
library and the verification process for the EOS image:
Software Integrity Test:
The software integrity test is designed to verify the integrity of the cryptographic library's software
components. By calculating the HMAC-SHA-1 value of the core binaries and comparing it against the
compile-time value, this test ensures that the software has not been tampered with or modified. The
result of this test provides an assurance of the software's integrity, indicating whether it remains
unchanged from its original state. A successful result confirms that the cryptographic library's software is
trustworthy and free from unauthorized alterations.
Cryptographic Self-Tests:
These self-tests are automatically initiated whenever programs utilizing the cryptographic libraries are
loaded. This includes scenarios such as starting the SSH server, SSH client, TLS server, or enabling 'FIPS
mode' on the TOE. The purpose of cryptographic self-tests is to assess the functionality and security of
the cryptographic algorithms used in SSH and TLS implementations within the TSF. These self-tests involve
conducting Known Answer Tests (KAT) for various cryptographic algorithms, such as RSA, AES, HMAC, SHA,
and the DRBG. The results of these tests ensure that the cryptographic algorithms operate correctly,
providing expected and secure outputs.
Pairwise Consistency Test:
The pairwise consistency test is executed upon the generation of an RSA key pair. The purpose of the
pairwise consistency test is to validate the consistency of the RSA key pair. This test ensures that the
generated public and private keys align correctly, maintaining their cryptographic properties. A successful
test result signifies that the RSA key pair generation process has produced a reliable and internally
consistent key pair. In the event of a test failure, where the generated keys do not match as expected, the
cryptographic functionality relying on those keys within the TSF may become unavailable. Additionally, an
audit record is generated to capture the failed test result, providing a record for further investigation and
analysis.
Continuous Test (CRNGT):
The continuous test, known as CRNGT (Continuous Random Number Generator Test), is conducted on the
DRBG. The CRNGT involves continuous testing of the DRBG to identify any stuck faults that may impact its
randomness generation. The purpose of the continuous test is to maintain the quality and reliability of
the DRBG, which is crucial for generating secure and unpredictable random numbers. Detecting stuck
faults helps prevent biased or predictable outputs from the DRBG, ensuring the cryptographic operations
relying on random numbers remain secure.
These four distinct tests provide ample evidence to conclude that the TSF operates correctly. They
comprehensively assess all the cryptographic functions performed by the TSF through cryptographic self-
tests, pairwise consistency tests, and CRNGT. Additionally, the software integrity test safeguards against
any modifications to the tests themselves.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 49 of 52
By continuously covering all the cryptographic functions within the TSF and ensuring their integrity, these
tests effectively fulfill the requirements for evaluating the TSF's correct operation. Therefore, it can be
confidently asserted that no additional tests are necessary.
FPT_TUD_EXT.1
The software updates are verified using SHA-512 published hash values. The update is performed by
Security Administrator and only on the SSH remote management console. The candidate update package
is downloaded from the Arista’s customer portal. Arista customers require a valid credential to login to
this portal to obtain the candidate updates. The candidate updates are provided with a separate download
of the SHA-512 hashed value of the update package. The Security Administrator is required to transfer the
downloaded candidate package from a trusted terminal to the TOE using secure means; typically, SCP
(secure copy) is utilized. The SHA-512 checksum of the candidate file is to be generated on the candidate
update package that was securely copied to the TOE. This is done by issuing the following command:
sha512sum <update-package>. The Security Administrator must verify that the on-screen output of the
checksum of the candidate update package matches the published hash of the candidate update package
before initiating the installation of the candidate update package. The Security Administrator
accomplishes this by visually comparing the published checksum to the checksum of the candidate update
package that was generated by the Security Administrator. If the hash generated does not match the
published hash for the candidate update, the Security Administrator is instructed not to proceed further.
Upon verifying the integrity of the TOE's new installation file, the administrator of the TOE modifies the
boot-config file to indicate the location of the new image in the flash folder. The configuration is then
saved to the startup-config file, and the TOE is rebooted to apply the new installation file. During this
process, there will be a short period of disruption affecting all functions and features until the switch is
successfully reinitialized with the updated image. After the reboot process is completed, all functions
and features will be restored to their normal operational state. The security Administrator can verify the
version of currently running EOS with “show version” CLI command.
FPT_STM_EXT.1
The following TSFs make use of the system time:
● Time stamping of TSF generated audit records
● Refetching of the new CRL at the end of validity period of the previous CRL and to check that the
time when the certificate is presented to the TOE lies within the validity period of the CRL
● Time keeping of interactive sessions between the Security Administrator and the TSF
(local console, remote SSH console interfaces) for the purpose of TSF termination of the
interactive sessions due to inactivity.
The initial system time is manually configured by the Security Administrator using the CLI interface. After
that, two components are responsible to keep the system time, namely, the Real Time Clock (RTC) and
the “system clock”. The RTC is battery powered and keeps track of time even when the TOE is not provided
with power from an A/C source. The system clock is a software counter based on the timer interrupt. The
system clock is reset after power cycle and gets initialized by the RTC during boot-up. The RTC is
maintained by an oscillator with an accuracy of 20 PPM.
The system clock and RTC can be expected to drift over time since both lack access to a reference source.
Over the course of one month, this drift will be linear and has small upper bounds. For the RTC the
absolute value of the drift is expected to be 1 minute or less per 30 days. For the system clock the absolute
value of the drift is expected to be 3.9 seconds or less per 30 days. In order to limit the amount of drift,
Security Administrator will be expected to set the clock on the TOE using a CLI command, once every 30
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 50 of 52
days. This new time must come from legitimate time source, meeting Common Criteria requirements.
Upon setting the time via the CLI command, both the system clock and the RTC will be set and the amount
of drift from the real time will be reduced to 0.
7.6 TOE Access (FTA)
FTA_SSL_EXT.1, FTA_SSL.3
The security Administrator can configure a time period to be used to automatically terminate
administrative session after inactivity. For local and remote administrative session, the TSF terminates the
session after this period of inactivity. To facilitate this, a timer is started for the session after successful
authentication of Security Administrator. The timer is reset each time the Security Administrator provides
input. If the Security Administrator does not provide input for a duration of configured inactivity period,
the TSF terminates the administrative session.
FTA_SSL.4
The TSF provides the means for the Security Administrator to manually terminate their own interactive
sessions with the TOE for both the local and remote administrative sessions. For this, the Security
Administrator can issue the “quit”, “logout” or “exit” command to terminate their own session.
FTA_TAB.1
Before establishing an administrative user session to the TSF, the TSF displays a Security Administrator-
specified advisory notice and consent warning message (banner). The banner is presented prior to human
user authentication on each of the TOE’s administrative interfaces. This banner is not required to be, nor
is it, presented to the eAPI JSON-RPC client prior to it authenticating to the TSF. The banner can be
configured via any one of the following administrative interfaces: Local console (serial port), remote
console (SSH), remote management (eAPI JSON-RPC client).
7.7 Trusted Path/Channels (FTP)
FTP_ITC.1
The trusted Channel connection is created between TSF and audit server. It is protected by SSH. The TOE
acts as SSH Client in the Trusted Channel connection to audit server. The operation of SSH is described
above in FCS_SSHC_EXT.1.
The trusted Channel connection is created between TSF and eAPI JSON-RPC Client. It is protected by TLS.
The TOE acts as TLS Server in the Trusted Channel connection to eAPI JSON-RPC Client. The operation of
TLS is described above in FCS_TLSS_EXT.2.
FTP_TRP.1
The trusted Path connection protects communication between TSF and a human user (Security
Administrator) performing management of the TSF. It is protected by SSH. The TOE acts as SSH Server in
the Trusted Path connection. Operation of SSH is described above in FCS_SSHS_EXT.1.
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 51 of 52
8. Terms and Definitions
Table 11: TOE Abbreviations and Acronyms
Abbreviations/
Acronyms
Description
AAA Authentication Authorization and Accounting
CLI Command Line Interface
CPU Central Processing Unit
CSP Critical Security Parameter
JSON JavaScript Object Notation
KAT Known Answer Tests
OSI Open Systems Interconnection
PAM Pluggable Authentication Modules
RBAC Role Based Access Control
RPC Remote Procedure Call
SSH Secure Shell
TLS Transport Layer Security
Table 12: CC Abbreviations and Acronyms
Abbreviations/ Acronyms Description
CC Common Criteria
PP Protection Profile
SAR Security Assurance Requirement
SFR Security Functional Requirement
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functionality
Arista Networks 7280 Series Switches Running EOS 4.28 Security Target
Page 52 of 52
9. References
Table 13: TOE Guidance Documentation
Reference Description Date
[T1] User Manual - Arista EOS version 4.28.0F 2023
[T1] Common Criteria Guidance Supplement July 18, 2023
Table 14: Common Criteria v3.1 References
Reference Description Version Date
[C1] Common Criteria for Information Technology Security
Evaluation, Part 1: Introduction and general model
CCMB-2009-07-001
V3.1 R5 April 2017
[C2] Common Criteria for Information Technology Security
Evaluation, Part 2: Security functional components
CCMB-2009-07-002
V3.1 R5 April 2017
[C3] Common Criteria for Information Technology Security
Evaluation, Part 3: Security assurance components
CCMB-2009-07-003
V3.1 R5 April 2017
[C4] Common Criteria for Information Technology Security
Evaluation. Evaluation Methodology CCMB-2009-07-
004
V3.1 R5 April 2017
Table 15: Supporting Documentation
Reference Description Versio
n
Date
[S1] Collaborative Protection Profile for Network Devices 2.2e March 23, 2020
[ENT] Annex D: Entropy Documentation for SLB9670 2.1 December 27, 2022