MAGNUM-SC-CC2 Security Target Document Version: 1.0 2400 Research Blvd Suite 395 Rockville, MD 20850 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 2 Revision History Version Date Changes Version 0.1 Sept 10, 2024 Initial Release Version 0.2 October 01, 2024 Updates based on responses from the Vendor Version 0.3 October 08, 2024 More updates based on responses from the Vendor Version 0.4 December 12, 2024 Updated based on review comments Version 0.5 February 12, 2025 Updates based on CAVP cert Version 0.6 March 26, 2025 Updated based on review comments Version 0.7 June 05, 2025 Check-in ready Version 0.8 Sept 22, 2025 Check-out ready Version 0.9 Nov 26, 2025 Updates based on ECR comments Version 1.0 December 12, 2025 Final release Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 3 Contents 1 Introduction ..........................................................................................................................................5 1.1 Security Target and TOE Reference.............................................................................................5 1.2 TOE Overview ..............................................................................................................................5 1.3 TOE Description...........................................................................................................................7 1.3.1 Physical Boundaries.................................................................................................................7 1.3.2 Security Functions Provided by the TOE .................................................................................8 1.3.3 TOE Documentation..............................................................................................................10 1.3.4 References.............................................................................................................................10 1.4 TOE Environment.......................................................................................................................10 1.5 Product Functionality Not Included in the Scope of the Evaluation .........................................11 2 Conformance Claims...........................................................................................................................13 2.1 CC Conformance Claims ............................................................................................................13 2.2 Protection Profile Conformance................................................................................................13 2.3 Conformance Rationale.............................................................................................................13 2.3.1 Technical Decisions ...............................................................................................................13 3 Security Problem Definition................................................................................................................15 3.1 Threats.......................................................................................................................................15 3.2 Assumptions ..............................................................................................................................16 3.3 Organizational Security Policies.................................................................................................18 4 Security Objectives..............................................................................................................................19 4.1 Security Objectives for the Operational Environment ..............................................................19 5 Security Requirements........................................................................................................................20 5.1 Conventions...............................................................................................................................21 5.2 Security Functional Requirements ............................................................................................21 5.2.1 Security Audit (FAU)..............................................................................................................21 5.2.2 Cryptographic Support (FCS).................................................................................................25 5.2.3 Identification and Authentication (FIA).................................................................................31 5.2.4 Security Management (FMT).................................................................................................33 5.2.5 Protection of the TSF (FPT)....................................................................................................34 5.2.6 TOE Access (FTA)...................................................................................................................35 5.2.7 Trusted Path/Channels (FTP).................................................................................................36 5.3 TOE SFR Dependencies Rationale for SFRs................................................................................36 5.4 Security Assurance Requirements.............................................................................................36 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 4 5.5 Assurance Measures..................................................................................................................37 6 TOE Summary Specification................................................................................................................38 6.1 CAVP Algorithm Certificate Details............................................................................................51 6.2 Cryptographic Key Destruction..................................................................................................53 7 Acronym Table ....................................................................................................................................55 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 5 1 Introduction The Security Target (ST) serves as the basis for the Common Criteria (CC) evaluation and identifies the Target of Evaluation (TOE), the scope of the evaluation, and the assumptions made throughout. This document will also describe the intended operational environment of the TOE, and the functional and assurance requirements that the TOE meets. 1.1 Security Target and TOE Reference This section provides the information needed to identify and control the TOE and the ST. Table 1 – TOE/ST Identification Category Identifier ST Title MAGNUM-SC-CC2 Security Target ST Version 1.0 ST Date December 12, 2025 ST Author Acumen Security, LLC. TOE Identifier MAGNUM-SC-CC2 TOE Version 24.11.8 TOE Developer Evertz Microsystems Ltd. 5292 John Lucas Drive Burlington, Ontario CANADA Key Words Network Device 1.2 TOE Overview The TOE is classified as a network device (a generic infrastructure device that can be connected to a network). The TOE hardware device is the Evertz MAGNUM-SC-CC2 which includes the MAGNUM-SC- CC2 (1 RU) with an AMD EPYC 7313P (16C/32T) in a Gigabyte E152-ZE1, running MAGNUM-OS firmware v24.11.8. The MAGNUM-OS firmware is based on Ubuntu version 24.04 LTS (Noble). The MAGNUM-OS serves as the primary user and network interface device for the MAGNUM control application. Evertz MAGNUM software (v24.11.8) is a custom-developed application written primarily in python. MAGNUM-SC-CC2 operates as a combination of an application layer and as part of the integrated Linux platform stack, using a customized Ubuntu operating system. The TOE version of MAGNUM (MAGNUM- SC-CC2) is only operable on Evertz provided platforms and hardware. The TOE is an infrastructure network device that provides secure remote management, auditing, and updating capabilities. The TOE provides secure remote management using an HTTPS/TLS web interface and an SSH command line interface. The TOE generates audit logs and transmits the audit logs to a remote syslog server over a mutually authenticated Syslog over TLS channel. The TOE verifies the authenticity of software updates by verifying the digital signature prior to installing any update. The scope of the evaluated functionality includes the following, • Secure remote administration of the TOE via TLS and SSH • Secure Local administration of the TOE Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 6 • Secure connectivity with remote audit servers • Secure access to the management functionality of the TOE • Identification and authentication of the administrator of the TOE The IT Testing Environment Components used to test the TOE are shown in Table 2. No other functionality is included within the scope of this evaluation. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 7 1.3 TOE Description This section provides an overview of the TOE architecture, including physical boundaries, security functions, and relevant TOE documentation and references. Figure 1 – Representative TOE Deployment 1.3.1 Physical Boundaries The physical boundaries of the TOE are outlined in section 1.2. The media and video components of the IT environment are NOT part of the TOE physical boundary. The TOE is shipped to the customer via commercial courier. The IT Testing Environment Components used to test the TOE are shown in Table 2 below: Table 2 – IT Testing Environment Components Component Required Purpose/Description Syslog server Yes • Conformant with RFC 5424 (Syslog Protocol) • Supporting Syslog over TLS (RFC 5425) • Acting as a TLSv1.2 server • Supporting Client Certificate authentication • Supporting at least one of the following cipher suites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 8 Component Required Purpose/Description o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 IPX Video Switch Yes • Provides switching of video signals • Acting as a TLSv1.2 server • Supporting Client Certificate authentication • Supporting at least one of the following cipher suites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Management workstation with web browser Yes • Supported browser: Chrome or Safari • Supporting TLSv1.2 • Supporting at least one of the following ciphersuites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Management workstation with remote CLI Yes • Supported SSH version: SSHv2 • Conformant with RFCs 4251-4254, 5647, 5656, 8308 and 8332 Local Management Workstation Yes • Computer with terminal emulation software to access the console interface (CLI) CRL Server Yes • Conformant with RFC 5280 • Provides a list of revoked certificates. • TOE uses the CRL server to check the revocation status of a server’s presented certificate. • Communication between the TOE and the CRL server occurs over HTTP. DNS Server Yes • Conformant with RFC 1035 • Communication between the TOE and the DNS server occurs over TCP. 1.3.2 Security Functions Provided by the TOE The TOE provides the security functions required by the Collaborative Protection Profile for Network Devices, hereafter referred to as NDcPP v3.0e or NDcPP and Functional Package for SSH, Version 1.0, hereafter referred to as PKG_SSH_v1.0. 1.3.2.1 Security Audit The TOE generates audit records for security relevant events. Audit data are stored internally and are only accessible to privileged administrators. The TOE supports access to TSF using administrator accounts for authentication and authorization to management and security functions. The TOE also supports sending audit records to a remote Syslog server. Audit records sent to the remote server are protected by a TLS connection. Each audit record includes identity (username, IP address, or process), date and time of the event, type of event, and the outcome of the event. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 9 1.3.2.2 Cryptographic Support The TOE includes an OpenSSL library (openssl version 3.0.13-0ubuntu3.5, openssl_fips version 3.0.9et2 and linux-image-generic_6.8.0.71) that implements CAVP validated cryptographic algorithms for random bit generation, encryption/decryption, authentication, and integrity protection/verification. These algorithms are used to provide security for the TLS, HTTPs, and SSH connections for secure management and secure connections to a syslog and authentication servers. TLS and HTTPs are also used to verify firmware updates. The cryptographic services provided by the TOE are described below: Table 3 – TOE Cryptographic Protocols Cryptographic Protocol Use within the TOE TLS (client) Secure connection to syslog and IPX video switches FCS_TLSC_EXT.1, FCS_TLSC_EXT.2 HTTPS/TLS (server) Remote management FCS_HTTPS_EXT.1, FCS_TLSS_EXT.1 SSH (server) Remote management FCS_SSHS_EXT.1 AES Provides encryption/decryption in support of the TLS and SSH protocol. FCS_COP.1.1/DataEncryption, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 DRBG Deterministic random bit generation use to generate keys. FCS_TLSS_EXT.1, FCS_RBG_EXT.1, FCS_SSHS_EXT.1 Secure hash Used as part of digital signatures and firmware integrity checks. FCS_COP.1/Hash, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 HMAC Provides keyed hashing services in support of TLS. FCS_COP.1/KeyedHash, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 EC-DH Provides key establishment for TLS. FCS_CKM.2, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 ECDSA Used to generate EC-DH components for key establishment for TLS. FCS_CKM.1, FCS_CKM.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 RSA Provide key generation and signature generation and verification (PKCS1_V1.5) in support of TLS. FCS_CKM.1, FCS_COP.1/SigGen, FCS_COP.1/SigVer, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1, FCS_SSHS_EXT.1 Each of these cryptographic algorithms have been validated for conformance to the requirements specified in their respective standards (refer to Table 15). 1.3.2.3 Identification and Authentication The TOE authenticates administrative users using a username/password combination. The TOE does not allow access to any administrative functions prior to successful authentication. The TOE validates and authenticates X.509 certificates for all certificate uses. The TOE supports passwords consisting of alphanumeric and special characters and enforces minimum password lengths. The TSF supports certificates using RSA signature algorithms. Certificates are used to authenticate trusted channels, not administrators. The TOE only allows users to view the login warning banner prior to authentication. Remote administrators are locked out after a configurable number of unsuccessful authentication attempts. 1.3.2.4 Security Management The TOE allows users with the Security Administrator role to administer the TOE over a remote web UI, remote CLI, or a local CLI. These interfaces do not allow the Security Administrator to execute arbitrary Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 10 commands or executables on the TOE. Security Administrators can manage connections to an external Syslog server, as well as determine the size of local audit storage. 1.3.2.5 Protection of the TSF The TOE implements several self-protection mechanisms. This protection includes self-tests to ensure the correct operations of cryptographic functions. The TOE provides protection of TSF data (authentication data and cryptographic keys). Firmware upgrades, performed by a Security Administrator, are from a reliable source. The TOE does not provide an interface for the reading of secret or private keys. The TOE ensures timestamps, timeouts, and certificate checks are accurate by maintaining a real-time clock. 1.3.2.6 TOE Access The TOE can be configured to display a warning and consent banner when an administrator attempts to establish an interactive session over the CLI (local or remote) or remote web UI. The TOE also enforces a configurable inactivity timeout for remote administrative sessions. 1.3.2.7 Trusted Path/Channels The TOE uses Syslog over TLS to provide a trusted communication channel between itself and remote audit server and IPX Video Switch. The trusted channels utilize X.509 certificates to perform mutual authentication. The TOE initiates the Syslog over TLS trusted channel with the remote audit server. The TOE uses HTTPS/TLS and SSH to provide a trusted path between itself and remote administrative users. The TOE does not implement any additional methods of remote administration. The remote administrative users are responsible for initiating the trusted path when they wish to communicate with the TOE. 1.3.3 TOE Documentation The following documents are essential to understanding and controlling the TOE in the evaluated configuration: • MAGNUM-SC-CC2 Supplemental Administrative Guidance for Common Criteria, Version 0.7 [AGD] • MAGNUM-SC-CC2 Security Target, Version 1.0 [ST] 1.3.4 References In addition, TOE documentation, the following reference may also be valuable when understanding and controlling the TOE: • Collaborative Protection Profile for Network Devices, Version 3.0e [NDcPP v3.0e or NDcPP] • Functional Package for SSH, Version 1.0, [PKG_SSH_v1.0] 1.4 TOE Environment The following environmental components are required to operate the TOE in the evaluated configuration: Table 4 – Required Environmental Components Component Purpose/Description Syslog server • Conformant with RFC 5424 (Syslog Protocol) Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 11 Component Purpose/Description • Supporting Syslog over TLS (RFC 5425) • Acting as a TLSv1.2 server • Supporting Client Certificate authentication • Supporting at least one of the following cipher suites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 IPX Video Switch • Provides switching of video signals • Acting as a TLSv1.2 server • Supporting Client Certificate authentication • Supporting at least one of the following cipher suites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Management workstation with web browser • Supported browser: Chrome or Safari • Supporting TLSv1.2 • Supporting at least one of the following ciphersuites: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Management workstation with remote CLI • Supported SSH version: SSHv2 • Conformant with RFCs 4251-4254, 5647, 5656, 8308 and 8332. Local Management Workstation • Computer with terminal emulation software to access the console interface (CLI) CRL Server • Conformant with RFC 5280 • Provides a list of revoked certificates. • TOE uses the CRL server to check the revocation status of a server’s presented certificate. • Communication between the TOE and the CRL server occurs over HTTP. DNS Server • Conformant with RFC 1035 • Communication between the TOE and the DNS server occurs over TCP. 1.5 Product Functionality Not Included in the Scope of the Evaluation The following product functionality is not included in the CC evaluation: • External Authentication Servers for administrator authentication • SNMP traps • Media streaming systems and devices controller feature Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 12 The MAGNUM is a software module that unifies control and interfacing to Evertz and 3rd party media streaming devices. As a unified controller, the MAGNUM supports the following functionalities that are outside of the scope of this evaluation: • MAGNUM serves as the control interface for Evertz’s proprietary IPX media streaming switch fabric that allows the general user to establish, change, and tear down multicast IP video streams. MAGNUM may also serve as a general control interface for similar Evertz and third- party systems and devices. • Equipment to prepare video for IP transport, or to convert it into other video formats, is outside the scope of this TOE. Such equipment includes, but is not limited to, cameras, KVMs, codes, video servers and video displays. Equipment to perform functions such as embedding audio and/or other information within the video stream is also outside the scope of this TOE. • MAGNUM issues command (via dedicated internal API) to Evertz’s proprietary IPX switching fabric and other production endpoints for the purpose of initiating, maintaining, and tearing down virtual routing paths. The MAGNUM-SC-CC2 device serves as the primary operational and administrative management interface to the closed multicast switching environment. • MAGNUM provides Out-of-Band Management (OOBM) of Evertz IPX, EXE, and other 3rd party devices. To perform primary operational and administrative management functions on the closed multicast switching environment, Security Administrators may access MAGNUM software via direct connection using a terminal session. Security Administrators may also access MAGNUM via a dedicated management workstation operating over an OOBM network to perform these OOB management functions. In addition to Security Administrators, general users may also access the MAGNUM software via a dedicated management workstation over an OOBM network. Note: Sites may close this OOBM network or may operate MAGNUM within an existing OOBM, if the topology is compliant with the security parameters listed below. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 13 2 Conformance Claims This section identifies the TOE conformance claims, conformance rationale, and relevant Technical Decisions (TDs). 2.1 CC Conformance Claims The TOE is conformant to the following: • Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 5, April 2017 • Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5, April 2017 (Extended) • Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5, April 2017 (Conformant) 2.2 Protection Profile Conformance This ST claims exact conformance to the following: • collaborative Protection Profile for Network Devices, Version 3.0e, 06 December 2023 [CPP_ND_V3.0E] • Functional Package for SSH, Version 1.0, 14 May 2021 [PKG_SSH_v1.0] 2.3 Conformance Rationale This ST provides exact conformance to the items listed in the previous section. The security problem definition, security objectives, and security requirements in this ST are all taken from the Protection Profile (PP) and Package, performing only the operations defined there. 2.3.1 Technical Decisions All NIAP TDs issued to date and applicable to NDcPP v3.0e and PKG_SSH_v1.0 have been considered. Table 5 identifies all applicable TDs. Table 5 – Relevant Technical Decisions Technical Decision Applicable (Y/N) Exclusion Rationale (if applicable) TD0923 - NIT Technical Decision: Auditable event for FAU_STG_EXT.1 in FAU_GEN.1.2 Yes TD0921 - NIT Technical Decision: Addition of FIPS PUB 186-5 and Correction of Assignment Yes TD0900 - NIT Technical Decision: Clarification to Local Administrator Access in FIA_UIA_EXT.1.3 Yes TD0899 - NIT Technical Decision: Correction of Renegotiation Test for TLS 1.2 Yes TD0886 - Clarification to FAU_STG_EXT.1 Test 6 Yes Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 14 Technical Decision Applicable (Y/N) Exclusion Rationale (if applicable) TD0880 - NIT Decision: Removal of Duplicate Selection in FMT_SMF.1.1 Yes TD0879 - NIT Decision: Correction of Chapter Headings in CPP_ND_V3.0E Yes TD0868 - NIT Technical Decision: Clarification of time frames in FCS_IPSEC_EXT.1.7 and FCS_IPSEC_EXT.1.8 No Not claimed in ST. TD0836 - NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1 Yes Technical Decision Applicable (Y/N) Exclusion Rationale (if applicable) TD0909 - Updates to FCS_SSH_EXT.1.1 App Note in SSH FP 1.0 Yes TD0777 - Clarification to Selections for Auditable Events for FCS_SSH_EXT.1 Yes TD0732 - FCS_SSHS_EXT.1.3 Test 2 Update Yes TD0695 - Choice of 128- or 256-bit size in AES-CTR in SSH Functional Package Yes TD0682 – Addressing Ambiguity in FCS_SSHS_EXT.1 Tests Yes Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 15 3 Security Problem Definition The security problem definition has been taken directly from the claimed PP and any relevant Packages specified in Section 2.2 and is reproduced here for the convenience of the reader. The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any Organizational Security Policies (OSPs) that the TOE is expected to enforce. 3.1 Threats The threats included in Table 6 are drawn directly from the PP and any Packages specified in Section 2.2. Table 6 – Threats ID Threat T.UNAUTHORIZED_ADMINISTRATOR_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 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_COMMUNICATION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling 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_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints, e.g. a 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. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 16 ID Threat 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_FUNCTIONALITY_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. Threat agents may also be able to take advantage of weak administrative passwords to gain privileged access to the device. T.SECURITY_FUNCTIONALITY_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 Assumptions The assumptions included in Table 7 are drawn directly from PP and any relevant Packages. Table 7 – Assumptions ID Assumption 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 or cPP_ND_v3.0e, 06-Dec-2023 41 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 does not include any requirements on physical tamper protection or other physical attack mitigations. The cPP does not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. For vNDs, this assumption applies to the physical platform on which the VM runs. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 17 ID Assumption 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 a 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. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 18 3.3 Organizational Security Policies The OSPs included in Table 8 are drawn directly from the PP and any relevant Packages. Table 8 – OSPs ID OSP P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which Administrators consent by accessing the TOE. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 19 4 Security Objectives The security objectives have been taken directly from the claimed PP and any relevant Packages and are reproduced here for the convenience of the reader. 4.1 Security Objectives for the Operational Environment Security objectives for the operational environment assist the TOE in correctly providing its security functionality. These objectives, which are found in the table below, track with the assumptions about the TOE operational environment. Table 9 – Security Objectives for the Operational Environment ID Objectives for the Operational Environment 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. Note: For vNDs the TOE includes only the contents of the its own VM, and does not include other VMs or the VS. 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 vNDs, this includes the VS Administrator responsible for configuring the VMs that implement ND functionality. 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 information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vNDs, this applies when the physical platform on which the VM runs is removed from its operational environment. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 20 5 Security Requirements This section identifies the Security Functional Requirements (SFRs) for the TOE. The SFRs included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revisions 5, April 2017, and all international interpretations. Table 10 – SFRs Requirement 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 FCS_CKM.2 Cryptographic Key Establishment 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_HTTPS_EXT.1 HTTPS Protocol FCS_RBG_EXT.1 Random Bit Generation FCS_SSH_EXT.1 SSH Protocol FCS_SSHS_EXT.1 SSH Server Protocol FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication FCS_TLSS_EXT.1 TLS Server Protocol FIA_AFL.1 Authentication Failure Handling FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication 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 FMT_MOF.1/Functions Management of Security Functions Behaviour FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour 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 of all pre-shared, symmetric and private keys) FPT_APW_EXT.1 Protection of Administrator Passwords Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 21 Requirement Description FPT_TST_EXT.1 TSF Testing FPT_STM_EXT.1 Reliable Time Stamps FPT_TUD_EXT.1 Trusted Update FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_TAB.1 Default TOE Access Banner FTP_ITC.1 Inter-TSF Trusted Channel FTP_TRP.1/Admin Trusted Path 5.1 Conventions The CC allows the following types of operations to be performed on the functional requirements: assignments, selections, refinements, and iterations. The following font conventions are used within this document to identify operations defined by CC: • Assignment: Indicated with italicized text; • Refinement: Indicated with bold text; • Selection: Indicated with underlined text; • Iteration: Indicated by appending the iteration identifier after a slash, e.g., /SigGen. • Where operations were completed in the PP and relevant EPs/Modules/Packages, the formatting used in the PP has been retained. Extended SFRs are identified by the addition of “EXT” after the requirement name. 5.2 Security Functional Requirements This section includes the security functional requirements for this ST. 5.2.1 Security Audit (FAU) 5.2.1.1 FAU_GEN.1 Audit Data Generation (Refinement) 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) 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). • 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 Administrator account shall be logged)]; Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 22 d) Specifically defined auditable events listed in Table 11. 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 (if applicable), 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 11. Table 11 – Security Functional Requirements and Auditable Events Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None. None. FAU_GEN.2 None. None. FAU_STG_EXT.1 Configuration of local audit settings. Identity of account making changes to the audit configuration. 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_HTTPS_EXT.1 Failure to establish a HTTPS Session Reason for failure FCS_RBG_EXT.1 None. None. FCS_SSH_EXT.1 [TD0777] [Failure to establish SSH connection] [Reason for failure and Non-TOE endpoint of attempted connection (IP Address)]. FCS_SSH_EXT.1 [Establishment of SSH connection]. [Non-TOE endpoint of connection (IP Address)]. FCS_SSH_EXT.1 [Termination of SSH connection session] [Non-TOE endpoint of connection (IP Address)] FCS_SSH_EXT.1 [Dropping of packet(s) outside defined size limits]. [Packet size]. FCS_SSHS_EXT.1 No events specified FCS_TLSC_EXT.1 Failure to establish a TLS Session Reason for failure FCS_TLSC_EXT.2 None. None. FCS_TLSS_EXT.1 Failure to establish a TLS Session 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. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 23 Requirement Auditable Events Additional Audit Record Contents FIA_UIA_EXT.1 All use of identification and authentication mechanisms. 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 inthe TOE's trust store • Reason for failure of certificate validation • Identification of certificates added, replaced or removed as trust anchor inthe 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_APW_EXT.1 None. None. FPT_SKP_EXT.1 None. None. FPT_TST_EXT.1 None. 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). FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure) 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_SSL_EXT.1 (if “terminate the session” is selected) The termination of a local session by the session lock None. FTA_TAB.1 None. None. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 24 Requirement Auditable Events Additional Audit Record Contents FTP_ITC.1 • Initiation of the trusted channel. • Termination of the trusted channel. • Failure of the trusted channel functions. • None • None • Reason for failure FTP_TRP.1/Admin • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. • None • None • Reason for failure Application Note: This SFR has been updated as per TD0777. 5.2.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. 5.2.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 to 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, ]. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 25 FAU_STG_EXT.1.3 The TSF shall maintain a [log file] of audit records in the event that an interruption of communication with the remote audit server occurs. FAU_STG_EXT.1.4 The TSF shall be able to store [persistent] audit records locally with a minimum storage size of [20GB]. FAU_STG_EXT.1.5 The TSF shall [drop new audit data] when the local storage space for audit data is full. FAU_STG_EXT.1.6 The TSF shall provide the following mechanisms for administrative access to locally stored audit records [ability to view locally, manual export]. 5.2.2 Cryptographic Support (FCS) 5.2.2.1 FCS_CKM.1 Cryptographic Key Generation (Refinement) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic key in accordance with a specified cryptographic key generation algorithm: [ • RSA schemes using cryptographic key sizes of [4096 bits] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1; • ECC schemes using ‘NIST curves’ [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4, or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3, “IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms”, Section 6.6.; ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Application Note: This SFR has been updated as per TD0921. 5.2.2.2 FCS_CKM.2 Cryptographic Key Establishment (Refinement) FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ • Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”; ] that meets the following: [assignment: list of standards]. 5.2.2.3 FCS_CKM.4 Cryptographic Key Destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 26 • 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] overwrite consisting of [zeroes,[random data (from openssl) before writing zeros]]]; that meets the following: No Standard 5.2.2.4 FCS_COP.1/DataEncryption Cryptographic Operations (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 [CTR, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3, [CTR as specified in ISO 10116, GCM as specified in ISO 19772]. 5.2.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, • Elliptic Curve Digital Signature Algorithm ] and cryptographic key sizes [ • For RSA: [modulus 4096 bits], • For ECDSA: [256, 384, and 521 bits] ] that meets the following: [ • For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 v2.2 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 implementing [P-256, P-384, P-521] curves that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST Recommended” curves ; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6, ]. Application Note: This SFR has been updated as per TD0921 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 27 5.2.2.6 FCS_COP.1/Hash Cryptographic Operations (Hash Algorithm) FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-256, SHA-384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004. 5.2.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] and cryptographic key sizes [ 256 bits, and 384 bits used in HMAC] and message digest sizes [256, 384] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. 5.2.2.8 FCS_HTTPS_EXT.1 HTTPS Protocol FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS protocol using TLS. 5.2.2.9 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] software-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. 5.2.2.10 FCS_SSH_EXT.1 SSH Protocol FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a [server] in accordance with that complies with RFCs 4251, 4252, 4253, 4254, [5647, 5656, 8308, 8332] and [no other standard]. FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods: [ • “password” (RFC 4252), • “publickey” (RFC 4252): [ o rsa-sha2-256 (RFC 8332), o rsa-sha2-512 (RFC 8332), o ecdsa-sha2-nistp256 (RFC 5656)] Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 28 ] and no other methods. FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [262148 bytes] in an SSH transport connection are dropped. FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the following mechanisms: [ • aes128-gcm@openssh.com (RFC 5647), • aes256-gcm@openssh.com (RFC 5647) ] and no other mechanisms. FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion using: [ • implicit ] and no other mechanisms. FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using: [ • ecdh-sha2-nistp256 (RFC 5656), • ecdh-sha2-nistp384 (RFC 5656), • ecdh-sha2-nistp521 (RFC 5656), ] and no other mechanisms. FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [ • RFC 5656 (Section 4) ] to derive the following cryptographic keys from a shared secret: session keys. FCS_SSH_EXT.1.8 The TSF shall ensure that [ • a rekey of the session keys, ] occurs when any of the following thresholds are met: • one hour connection time • no more than one gigabyte of transmitted data, or • no more than one gigabyte of received data. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 29 5.2.2.11 FCS_SSHS_EXT.1 SSH Protocol - Server FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using: [ • rsa-sha2-256 (RFC 8332), • rsa-sha2-512 (RFC 8332), • ecdsa-sha2-nistp256 (RFC 5656), ]. 5.2.2.12 FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] supporting the following ciphersuites: [ • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and no other ciphersuites. FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the reference identifier per RFC 6125 Section 6, IPv4 address in the SAN] and no other attribute types]. FCS_TLSC_EXT.1.3 The TSF shall not establish a trusted channel if the server certificate is invalid [ • without any administrator override mechanism. ]. FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Groups Extension with the following curves/groups: [secp256r1, secp384r1, secp521r1] and no other curves/groups] inthe Client Hello. FCS_TLSC_EXT.1.5 The TSF shall [ • present the signature_algorithms extension with support for the following algorithms: [ o rsa_pkcs1 with sha256(0x0401), o rsa_pkcs1with sha384(0x0501), o rsa_pkcs1 with sha512(0x0601), o rsa_pss_rsae with sha256(0x0804), o rsa_pss_rsae with sha384(0x0805), o rsa_pss_rsae with sha512(0x0806), ] and no other algorithms; ]. FCS_TLSC_EXT.1.6 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 30 The TSF [does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_TLSC_EXT.1.1. FCS_TLSC_EXT.1.7 The TSF shall prohibit the use of the following extensions: • Early data extension • Post-handshake client authentication according to RFC 8446, Section 4.2.6. FCS_TLSC_EXT.1.8 The TSF shall [not use PSKs]. FCS_TLSC_EXT.1.9 The TSF shall [support TLS 1.2 secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746] 5.2.2.13 FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication FCS_TLSC_EXT.2.1 The TSF shall support TLS communication with mutual authentication using X.509v3 certificates. 5.2.2.14 FCS_TLSS_EXT.1 TLS Sever Protocol 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 willsupport the followingciphersuites: [ • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ] and no other ciphersuites. FCS_TLSS_EXT.1.2 The TSF shall authenticate itself using X.509 certificate(s) using [RSA with key size [4096] bits]. FCS_TLSS_EXT.1.3 The TSF shall perform key exchange using: [ • EC Diffie-Hellman key agreement over NIST curves [secp256r1, secp384r1, secp521r1] and no other curves; ]. FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session IDs according to RFC 5246 (TLS 1.2), session resumption based on session tickets according to RFC 5077 (TLS 1.2)]. FCS_TLSS_EXT.1.5 The TSF [does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_TLSS_EXT.1.1. FCS_TLSS_EXT.1.6 The TSF shall prohibit the use of the following extensions: • Early data extension Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 31 FCS_TLSS_EXT.1.7 The TSF shall [not use PSKs]. FCS_TLSS_EXT.1.8 The TSF shall [reject [TLS 1.2] renegotiation attempts]. 5.2.3 Identification and Authentication (FIA) 5.2.3.1 FIA_AFL.1 Authentication Failure Handling (Refinement) FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [3 to 10] 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 [unlocks the user] is taken by an Administrator; 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]. 5.2.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: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [“~”, ”`”, ”_”, ”-“, ”+”, “=”, “{“, “[“, “}”, “]”, “|”, “\”, “:”, “;”, (”), (’), “<”, “,”, “>”, “.”, “?”, “/”, (space)]]; b) Minimum password length shall be configurable to between [8] and [16] characters. 5.2.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. FIA_UIA_EXT.1.3 The TSF shall provide the following remote authentication mechanisms [Web GUI password, SSH password, SSH public key] and [no other mechanism]. The TSF shall provide the following local authentication mechanisms [password-based]. Application Note: This SFR has been updated as per TD0900. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 32 FIA_UIA_EXT.1.4 The TSF shall authenticate any administrative user’s claimed identity according to each authentication mechanism specified in FIA_UIA_EXT.1.3. 5.2.3.4 FIA_UAU.7.1 Protected Authentication Feedback (Refinement) 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. 5.2.3.5 FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules: • RFC 5280 certificate validationand certification path validationsupporting a minimum path length of three certificates . • The certification 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 inthe 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: o Certificates used for trusted updatesand 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 theextendedKeyUsage field. o Server certificates presented for DTLS/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 DTLS/TLS shall have the Client Authentication purpose (id- kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsagefield. 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. 5.2.3.6 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 [HTTPS, TLS] and [no additional uses]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validityof a certificate, the TSF shall [not accept the certificate]. 5.2.3.7 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 ]. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 33 FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. 5.2.4 Security Management (FMT) 5.2.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. 5.2.4.2 FMT_MOF.1/ManualUpdate Management of Security Functions Behavior FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual updates to Security Administrators. 5.2.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. 5.2.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. 5.2.4.5 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: • Ability to administer the TOE remotely; • Ability to configure the access banner; • Ability to configure the remote session inactivity time before session termination; • Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates; • [ ▪ Ability to modify the behaviour of the transmission of audit data to an external IT entity; ▪ Ability to manage the cryptographic keys; ▪ Ability to re-enable an Administrator account; ▪ Ability to set the time which is used for time-stamps; ▪ Ability to manage the TOE’s trust store and designate X509.v3 certificates as trust anchors; ▪ Ability to generate Certificate Signing Request (CSR) and process CA certificate response; ▪ Ability to configure the authentication failure parameters for FIA_AFL.1; ▪ Ability to administer the TOE locally; ▪ Ability to configure the local session inactivity time before session termination or locking; Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 34 ▪ Ability to manage the trusted public keys database; ]. Application Note: This SFR has been updated as per TD0880 5.2.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 remotely; are satisfied. 5.2.5 Protection of the TSF (FPT) 5.2.5.1 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. 5.2.5.2 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 5.2.5.3 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 The TSF shall [allow the Security Administrator to set the time]. 5.2.5.4 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) to verify the integrity of the TOE firmware and software; • Prior to providing any cryptographic service and [[system reboot]] to verify correct operation of cryptographic implementation necessary to fulfil the TSF • [no other] self-tests [none]to demonstrate the correct operation of the TSF. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 35 Application Note: This SFR has been updated as per TD0836 FPT_TST_EXT.1.2 The TSF shall respond to [all failures] by [[ preventing bootup and reboot ]]. 5.2.5.5 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 [digital signature] prior to installing those updates. 5.2.6 TOE Access (FTA) 5.2.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 5.2.6.2 FTA_SSL.3 TSF-initiated Termination (Refinement) FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity. 5.2.6.3 FTA_SSL.4 User-initiated Termination (Refinement) FTA_SSL.4.1 The TSF shall allow user Administrator-initiated termination of the user’s Administrator’s own interactive session. 5.2.6.4 FTA_TAB.1 Default TOE Access Banners (Refinement) FTA_TAB.1.1 Before establishing a an administrative user session the TSF shall display a Security Administrator- specified advisory notice and consent warning message regarding unauthorised use of the TOE. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 36 5.2.7 Trusted Path/Channels (FTP) 5.2.7.1 FTP_ITC.1 Inter-TSF Trusted Channel (Refinement) FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel between itself and another trusted IT product authorized IT entities supporting the following capabilities: audit server, [ [video switches]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure and detection of modification of the channel data. FTP_ITC.1.2 The TSF shall permit [the TSF] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [auditing services and video switch control]. 5.2.7.2 FTP_TRP.1/Admin Trusted Path (Refinement) FTP_TRP.1.1/Admin The TSF shall be capable of using [TLS, HTTPS, SSH] to provide a communication path between itself and authorized remote Administrators users that is logically distinct from other communication paths and provides assured 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 users 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. 5.3 TOE SFR Dependencies Rationale for SFRs The PP and any relevant EPs/Packages contain(s) all the requirements claimed in this ST. As such, the dependencies are not applicable since the PP has been approved. 5.4 Security Assurance Requirements The TOE assurance requirements for this ST are taken directly from the PP and any relevant Packages, which are derived from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in Table 12. Table 12 – Security Assurance Requirements Assurance Class Assurance Components Component Description Security Target ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_SPD.1 Security problem definition Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 37 Assurance Class Assurance Components Component Description ASE_TSS.1 TOE Summary Specification Development ADV_FSP.1 Basic functionality specification Guidance Documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative Procedures Life Cycle Support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage Tests ATE_IND.1 Independent testing – conformance Vulnerability Assessment AVA_VAN.1 Vulnerability survey 5.5 Assurance Measures The TOE satisfied the identified assurance requirements. This section identifies the Assurance Measures applied by Evertz Microsystems Ltd. to satisfy the assurance requirements. The following table lists the details. Table 13 – TOE Security Assurance Measures SAR Component How the SAR will be met ASE_TSS.1.1C Refinement The TOE summary specification shall describe how the TOE meets each SFR. In the case of entropy analysis, the TSS is used in conjunction with required supplementary information on Entropy. ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the means for a user to invoke a service and the corresponding response of those services. The description includes the interface(s) that enforces a security functional requirement, the interface(s) that supports the enforcement of a security functional requirement, and the interface(s) that does not enforce any security functional requirements. The interfaces are described in terms of their purpose (general goal of the interface), method of use (how the interface is to be used), parameters (explicit inputs to and outputs from an interface that control the behavior of that interface), parameter descriptions (tells what the parameter is in some meaningful way), and error messages (identifies the condition that generated it, what the message is, and the meaning of any error codes). AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of how the administrative users of the TOE can securely administer the TOE using the interfaces that provide the features and functions detailed in the guidance. AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so that the users of the TOE can put the components of the TOE in the evaluated configuration. ALC_CMC.1 The Configuration Management (CM) documents describe how the consumer identifies the evaluated TOE. The CM documents identify the configuration items, how those configuration items are uniquely identified, and the adequacy of the procedures that are used to control and track changes that are made to the TOE. This includes details on what changes are tracked and how potential changes are incorporated. ALC_CMS.1 ATE_IND.1 Vendor will provide the TOE for testing. AVA_VAN.1 Vendor will provide the TOE for testing. Vendor will provide a document identifying the list of software and hardware components. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 38 6 TOE Summary Specification This chapter identifies and describes how the Security Functional Requirements identified above are met by the TOE. Table 14 – TOE Summary Specification SFR Description Requirement TSS Description FAU_GEN.1 FAU_GEN.2 Audit records are created when an auditable event that belongs to a set of predefined events had occurred. The set of auditable events can be sub-categorized into functional events and access events. Audit records are stored in plaintext in /var/log for each application. Each entry contains a timestamp of when the event had occurred as well as a message body with description of the event. Log entries are sorted based on chronological order. TSF generates audit records for the following events: • Startup and shutdown of the audit function • Administrative login and logout events • Changes to TSF data related to configuration changes • Generation of a CSR and associated keypair • Installation of a certificate • Resetting passwords • Failure to establish a HTTPS/TLS session • Failure to establish a TLS session • All uses of the identification and authentication mechanism (local and remote connections to the TSF) • Unsuccessful attempts to validate a certificate • Initiation of a software update • Result of a software update • Changes to the time • Modification of the behavior of the TSF • Failure of self-tests • Initiation and termination of the trusted channel • Initiation and termination of the trusted path • Attempts to unlock an interactive session • Termination of a session by the session locking mechanism • Configuration of local audit settings Each audit record includes the date and time, type, subject identity (IP address, hostname, and/or username), the outcome (success or failure), and any additional information specified in column three of Table 11. The TOE includes 2 different keys. When a key is destroyed or generated a log message is created and the keys are referred to as follows: • TLS keys – ‘ssl/private/evertz-server.key’ • SSH private keys – ‘ssh_host_rsa_key’ • SSH public keys – ‘ssh/ ssh_host_rsa_key.pub’ The TOE only stores one of each type of key and therefore these names uniquely identify the keys stored on the TOE. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 39 Requirement TSS Description FAU_STG_EXT.1 The TOE is a standalone TOE. Audit data is sent to external syslog server through secured, mutually authenticated TLS v1.2 sessions. The log data that is transmitted to the external syslog server and to the local audit store in real-time, simultaneously. A Security Administrator must configure an external syslog server (IP address/TCP Port 6514) on the TOE. A trusted certificate chain that is used to sign syslog server’s certificate must be also uploaded to MAGNUM. The trusted channel with the Syslog server is described in greater detail in the FCS_TLSC_EXT.2 description. Audit logs are persistently stored in a log file. MAGNUM stores all audit data locally on SSD in a 20 GB non-executable partition, protected by Linux permissions and non-configurable. Only authorized administrators can access (view and export) the stored audit data via local console or SSH or web GUI. To keep the local audit disk partition from overflowing old audit records on the local SSD are transmitted to the audit server once a connection is available. In the unlikely event that the disk partition fills up before enough records can be rotated away new entries are dropped. The TSF protects audit data from unauthorized modification and deletion through the restrictive administrative interfaces. The filesystem of the TSF is not exposed to the administrative user over the HTTPs GUI or the local CLI. The administrative user must be positively identified and authenticated prior to being allowed to change audit settings. There is no method of clearing the audit files. All log files are stored under /var/log/. The log file that stores audit records in case of an interruption of connection with audit server is saved by the name ‘stunnel-out-verify-cert-and-crl-and-san.log’. FCS_CKM.1 The TSF supports 4096-bit RSA keys for generation of keys for TLS and SSH session signatures and ECDSA with NIST curves P-256, P-384, and P-521 to generate ECDH components for TLS and SSH key establishment. The TSF supports generation of 4096-bit RSA keys for digital signatures in support for system updates. FCS_CKM.2 The TOE acts as both sender and recipient for elliptic curve-based key establishment schemes that meet the following: • NIST Special Publication (SP) 800-56A Revision 2, “Recommendation for Pair Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” – for FCS_TLSC_EXT.1 connections to the audit server, FCS_TLSC_EXT.2 connections to video switches, and FCS_TLSS_EXT.1 connections to the remote administrators managing the TOE over web-GUI. The TOE also supports key exchange for SSH using ecdh-sha2-nistp256, ecdh-sha2-nistp521, or ecdh-sha2-nistp384 for FCS_SSHS_EXT.1. In the case of a decryption error, the TOE response is dependent on the stage of the connection process. If the connection has not been established, the TOE prevents a connection from occurring. If the connection has already been established, the TOE drops the packet(s) in question and logs the error internally. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 40 Requirement TSS Description To address the issue of side-channel attacks, the TOE does not reveal the particular error that occurred through other channels, either through message content or timing variations. FCS_CKM.4 The TSF overwrites keys with random data followed by overwriting the contents with zeros. A sudden, unexpected power could disrupt zeroization and cause keys to not be zeroized. There are no other known circumstances where the TOE would not conform to these requirements. Keys are stored on a separate disk partition that uses Linux file permission to ensure that no user or administrator access is allowed. The TOE does not provide full shell access and file permissions cannot be changed. No user has access to this partition. Keys are cleared when entering secure mode during device setup, and whenever the administrator selects this operation from the console. The keys mentioned in Table 16 are stored in the partition. The keys/CSPs used by the TOE, their storage location and format, and their associated zeroization method are listed in the Table 16 – Key Storage and Zeroization. No direct interface/access is provided to view or modify the contents of these files. The TLS Session keys are zeroized from RAM when the associated TLS session is terminated. The DRBG state is zeroized using a single overwrite of zeros when the TSF is shutdown or restarted. FCS_COP.1/DataEncryption The TOE provides AES encryption/decryption in CTR and GCM modes with 128- and 256-bit keys. FCS_COP.1/Hash Cryptographic hashing services are performed using Evertz’s cryptographic module. Hashing is used for firmware integrity checks, password verification and security mode verification. The TOE implements hashing in byte-oriented mode. The TOE uses hashing for the following security functions: • TLS connection establishment using SHA-256/384 • Verifying executable file checksums SHA-512 • Linux Passwords using salted SHA-512 • Digital Signature Verification of TOE software update using SHA- 256 Key generation using SHA-256 as specified in NIST SP 800-90 DRBG FCS_COP.1/KeyedHash MAGNUM compiles OpenSSL FIPS provider (source unmodified) and permanently enables FIPS mode via the main OpenSSL configuration file, which cannot be modified. When these are set, the TSF will not allow ephemerally generated hashes and keys to be created that do not comply with these standards. The keyed-hash message authentication is performed internally by OpenSSL when it is used to perform message authentication. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 41 Requirement TSS Description For HMAC-SHA-256: • Key length: 256 - 512 bits • Hash function used: SHA-256 • Block size: 512 bits • Output MAC (message digest size): 256 bits For HMAC-SHA-384: • Key length: 384 bits • Hash function used: SHA-384 • Block size: 1024 • Output MAC (message digest size): 384 bits HMACs are used for encrypted password files during bootup. FCS_COP.1/SigGen The TOE supports signature generation and verification with RSA 4096- bits in accordance with FIPS PUB 186-4, Section 5.5, using PKCS #1 v2.1 and ECDSA with NIST curves P-256, P-384 and P-521. These signatures support TLS and SSH authentication and firmware verification. FCS_HTTPS_EXT.1 FCS_TLSS_EXT.1 FCS_TLSC_EXT.1 FCS_TLSC_EXT.2 The TSF implements the server side of the HTTPs protocol according to RFC 2818 by using a TLS session in place of a TCP connection. The TSF only supports TLSv1.2 for HTTPS/TLS. Connection requests that include SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.3 are denied. If the TSF receives a ClientHello message that requests TLSv1.1 or earlier, the TSF sends a fatal handshake_failure message and terminates the connection. When the TSF is configured with a server certificate with an RSA key, the TSF supports following restrictive TLS ciphersuites are supported: • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 These ciphersuites cannot be configured or changed by an Administrator. MAGNUM supports cipher suites that use ECDHE NIST curves P-256, P- 384 and P-521 for key exchange and RSA 4096-bits for authentication. These keys are generated by the OpenSSL implementation internally with OpenSSL’s RSA command line utility. When acting as a TLS server or client, the TOE Key Exchange message parameter is ECDSA over NIST curve secp256r1, secp384r1 and secp512r1. MAGNUM uses CRL (certification revocation list) to check for invalid certificates. CRL files which are signed by trusted CA certificated can be imported to MAGNUM. This CRL file will be used by MAGNUM during certificate validation process to check for revocation status of the peer certificates. MAGNUM allows configuration of reference identifier from peer it expects to connect with before connection is made. The verification against SAN-IPv4 peer certificate is implemented within OpenSSL. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 42 Requirement TSS Description For browser-based management, MAGNUM must respond to the request presented by the user/operator browser. Administrators do not have the ability to modify the available ciphersuites, as these are hard- coded at the application layer. The [AGD] describes configuration procedures for the allowed SANs. When establishing a TLS connection, the MAGNUM client establishes the following reference identifiers: • Domain Name Service (DNS) in SAN-DNS • IPv4 Address in SAN-IP The TOE enforces canonical format for IPv4 as defined in RFC 3986 for IPv4. The SAN field is mandatory when using SAN-IP or SAN-DNS and ignores CN when SAN is present. When establishing reference identifiers, wildcards are supported for DNS only. MAGNUM supports wildcards in certificates. The wildcard must be in the left-most label of the presented identifier. And the wildcard only covers one level of subdomain. For the reference identifier without a left-most label as in the certificate, the connection will fail, i.e., awesome.com doesn’t match *.awesome.com. Certificate pinning is not used. MAGNUM does not use out-of-band provisioning of pre-shared keys (PSKs). MAGNUM supports the following signature_algorithms extension for TLS connections: o rsa_pkcs1 with sha256(0x0401), o rsa_pkcs1with sha384(0x0501), o rsa_pkcs1 with sha512(0x0601), o rsa_pss_rsae with sha256(0x0804), o rsa_pss_rsae with sha384(0x0805), o rsa_pss_rsae with sha512(0x0806), If the claimed signature_algorithm is present in the ‘CLIENT HELLO’, then the connection is accepted otherwise denies the connection. By default, the signature_algorithms extension is supported on the TOE. By default, the TOE presents the supported Elliptic Curve Extension secp256r1, secp384r1 and secp512r1 in the Client Hello. The TSF supports session resumption based on session IDs and session tickets. Session tickets adhere to the structural format provided in section 4 of RFC 5077 and session IDs adhere to the structural format provided in RFC 5246. Session tickets are encrypted according to the TLS negotiated symmetric encryption algorithm AES in Galois/Counter Mode (AES-GCM). When TOE is acting as a TLS Server, session tickets are protected with an AES-GCM algorithm with a key length of 128 or 256 bits. In TLS session resumption, the server verifies the authenticity of presented session tickets. If validation is unsuccessful, it prompts the server to initiate a full handshake process. A distinct context is Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 43 Requirement TSS Description established for every session, ensuring there is no interaction between them even if they are created for the same user. When the Syslog server or video switch sends the Certificate Request message, the TSF replies with a Client Certificate message. The Client Certificate message includes the certificate that the Security Administrator configured to authenticate to the Syslog server and video switch. MAGNUM functions as an HTTPS server only. HTTPS is used implementation to provide a secure interactive webpage interface for remote administrative functions, and to support secure exchange of user authentication parameters during login. The internal application is “nginx” (which uses openssl). Certificates (MAGNUM’s own certificate or a trusted CA certificate) can be uploaded onto MAGNUM prior to establishing connection with peers. These certificates are used in the TLS handshaking process and are taken care of by TLS protocol implementation. The TSF will not establish the connection if the peer certificate does not successfully authenticate the peer according to X.509 authentication. There are no fallback authentication functions for failed certificate authentication. When acting as a server, the TSF listens on port 443 for HTTPS Connections. The TSF uses HTML over HTTPs to present the administrative users with a secure management interface. The TSF uses TLS to provide a secure connection between the TSF and remote Security Administrators. When acting as a client, the TSF uses HTTPs/TLS to establish a trusted channel with a syslog server or video switch. The syslog server connects over the TCP port 6514. For trusted channels with the Evertz video switch (IPX), the TOE requires TLS with mutual authentication using X.509v3 certificates. The TLS client with mutual authentication connects over the TCP port 9672. FCS_RBG_EXT.1 The TOE implements a DRBG in accordance with ISO/IEC 18031:2011 using a CTR DRBG with AES. The TSF seeds the CTR_DRBG using 384- bits of data that contains at least 256 bits of entropy. The TSF gathers and pools entropy from one software-based noise source: jitter entropy. FCS_SSH_EXT.1 FCS_SSHS_EXT.1 The TSF implements SSH as a trusted channel for remote administrative connections to the CLI. The TOE implements SSH acting as a server in accordance RFCs 4251, 4252, 4253, 4254, 5647, 5656, 8308 and 8332. Public key or password-based authentication is allowed. rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256 are the public key algorithms accepted for SSH connections. All connections using other public key algorithms are rejected. If an SSH client attempts a session with public key authentication and does not provide the proper key, the TOE will reject the authentication attempt and revert to password-based authentication. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 44 Requirement TSS Description For SSH peer authentication, the following public key algorithms are supported: rsa-sha2-256 and rsa-sha2-512, ecdsa-sha2-nistp256 (RFC 5656). During an SSH session, the TOE reads the packet payload size from the TCP header to determine packets size. As packets are reassembled, the payloads are added. Any packets larger than 262148 are rejected. SSH transport is encrypted using aes128-gcm@openssh.com and aes256-gcm@openssh.com. Data integrity is verified implicitly. All other MAC algorithms are rejected. Keys are exchanged using elliptic curve Diffie Hellman with NIST curves P-256, P-384 or P-521. The TSF will rekey the SSH if the session lasts longer than 60 minutes or if more than 1GB of data has been transferred. The TOE establishes a user identity by verifying that the SSH client's present public key matches the one that is stored within the SSH server's authorized keys file. FIA_AFL.1 An administrator can configure the number of unsuccessful attempts a remote administrator can make before a lock-out and can configure the length of time that the remote administrator is locked out. The attempts can range between 3 and 10, with a default of 10. The length of time can be configured between 1 and 60 minutes, with a default of 15. Additionally, a different Administrator can log in and unlock the user, prior to the timeout period if needed. The TOE maintains a counter for incorrect authentication attempts for each username. If the user enters an incorrect password the configured number of times, the username is changed to a locked state. Any attempt to authenticate from a remote interface using that username is denied and an error message is shown to the user. When the lockout time has expired or an administrator unlocks the user, the administrator is allowed to authenticate to the TOE again. Lockouts are not enforced on the TOE’s console interface. This ensures that authentication failures cannot lead to a situation where no administrator access is available. FIA_PMG_EXT.1 MAGNUM enforces that passwords must meet minimum requirements (length, mix of number of lower/upper case letters, numbers as well as special characters). The special characters the TSF supports include : ”~”, “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “””, “'”, “+”, ”-”, ”,”, ”.”, ”/”, ”\”, ”:”, ”;”, ”<”, ”=”, ”>”, ”?”, ”[“, ”]”, ”_”, ”`”, ”{“, ”|”, ”}”, [space]. Administrators can configure a minimum password length between 8 and 16 characters. FIA_UIA_EXT.1 The TSF displays a warning banner after the user enters their username, but before the password prompt it will accept login credentials from a user. This applies to direct console users as well as web users. There are Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 45 Requirement TSS Description no other activities allowed prior to the identity and authentication of the administrators. Authentication is based on username/password for the web interface and local console. Remote access of SSH can use password or SSH public key-based authentication. The TOE does not expose any interface, through any access method prior to successful login. Console user’s passwords are verified through the PAM module provided by Linux. Web user’s passwords are verified against a PostgreSQL database that stores (hashed) values. If a password does not match, the user is not granted access. If the password matches, the user is granted access according to their role. SSH users with public key-based authentication must first have their public key uploaded to the TOE. The user can then start an SSH session with the TSF using the public key. The key is verified against the stored key. If the keys match, access is granted. If the key does not match, access is not granted, and the user is presented with a username and password prompt. When the user is entering their password over the local console, the TSF shows only asterisks (“*”). Prior to successful identification and authentication on all interfaces, the TSF displays the TOE access banner specified in FTA_TAB.1. Users must acknowledge the warning banner before they can login to the system. FIA_UAU.7 None FIA_X509_EXT.1/Rev MAGNUM uses CRLs to validate certificates. When the TOE acts as a TLS client, the video switch or syslog server’s certificates are validated during the TLS session connection handshake. Certificates are checked for validation when loaded into the TOE. MAGNUM first checks Certificate Authorities (CAs), then CRLs, then SANs. The TOE verifies that the certificates presented by a TLS server must contain the TLS server extended key usage, TLS client certificates must have the TLS client extended key usage. The TOE does not support certificates for trusted updates or OCSP. This validation includes revocation checking for the full certificate chain regardless of whether the full chain or only a leaf certificate is presented. As a TLS Client, the TOE uses CRL to determine whether the certificate is revoked or not. If the certificate fails a validity check, the connection attempt will fail, and the trusted channel is not established. MAGNUM only supports certificates that have been loaded by an authorized system administrator within the local Evertz network environment. As a purpose-built ecosystem, MAGNUM will not operate non-Evertz hardware. Administrators should ensure that the CRL reflects the certificates loaded onto the TOE and other Evertz hardware which the system is intended to manage. For an expired certificate, MAGNUM will deny the connection. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 46 Requirement TSS Description During session establishment with MAGNUM, any byte modification in the certificate will lead to the failure of connection. The TSF additionally verifies: • Each certificate (other than the first certificate) in the certificate chain has the Subject Type=CA flag set. • Each certificate is signed by: o a certificate in the certificate chain, or o a trusted root CA that has been installed in the TSF The TOE uses CRLs to verify whether the certificate or intermediate CA certificate has been revoked when a leaf certificate is presented to the TOE as part of the certificate chain during authentication. The following trusted channels are supported: • MAGNUM-SC-CC2 to a remote syslog server • MAGNUM-SC-CC2 to an Evertz video switch compatible with Common Criteria. As for this writing these include: o MMA10G-IPX-16 o MMA10G-IPX-32 o MMA10G-IPX-64 MAGNUM may also control 3rd-party devices as long as such devices support TLS v1.2. In such cases, MAGNUM can support a trusted channel to such devices. The configuration and deployment of 3rd- party devices lies outside the scope of the TOE and this ST. FIA_X509_EXT.2 Instructions for configuring MAGNUM to operate with X.509 certificates are found in the [AGD] document. As a TLS Client, the TOE uses CRL to determine whether the certificate is revoked or not. If the certificate fails a validity check, the connection attempt will fail, and the trusted channel is not established. The CRLs are obtained from a CRL distribution point over HTTP for every connection. If the TOE is unable to reach the CRL DP it will not accept the certificate and the session associated with the certificate will be denied. FIA_X509_EXT.3 MAGNUM uses its OpenSSL based cryptographic module to generate a Certificate Request Message. This requires the specification of the public key, Common Name, Organization, Organizational Unit, and Country. This information is configurable via the console admin interface. MAGNUM uses the following key usage and extended key usage parameters: • keyUsage = critical, nonRepudiation,digitalSignature,keyEncipherment • ExtendedKeyUsage = clientAuth,serverAuth MAGNUM uses its OpenSSL based cryptographic module to verify certificates when the TOE is configured in a security mode to verify certificates by a Certificate Authority (CA). MAGNUM requires all certificates in the chain to be presented by the peer during connection attempts. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 47 Requirement TSS Description FMT_MOF.1/Functions FMT_MOF.1/ManualUpdate FMT_MTD.1/CoreData FMT_MTD.1/CryptoKeys FMT_SMF.1 FMT_SMR.2 The TSF gives the Security Administrator the ability to manage the security functions: auditing operations, administrative user accounts, password and session policies, advisory banners, software updates, as well as cryptographic functions. The TSF ensures that only secure values are accepted for security attributes. A Security Administrator can change passwords, and can add, edit and/or delete Security Administrator accounts. The TOE restricts the ability to modify the behaviour of transmission of audit data to an audit server to Security Administrators. The Security Administrator has the ability to configure and modify the IP address of the designated audit server, as well as to configure and modify the port associated with the audit server connection. Instructions for configuring MAGNUM to the external syslog server are found in the [AGD] document under the ‘Secure Audit server’ section. The TSF displays a warning banner prior to user authentication. There are no administrative functions available for unauthorized users. All administrators must be authenticated and authorized to perform any activity that can alter TSF data. The TSF implements the Security Administrator role to authorized administrators of the TOE. The TSF allows the Security Administrators to administer the TSF via the CLI (local and remote) and a web UI. The TSF permissions restrict access to these management functions to users that have been identified, authenticated, and authorized with the Security Administrator role. The web UI and CLI (local and remote) allow the Security Administrator to perform the following TSF management functions: • Ability to administer the TOE remotely; • Ability to configure the access banner; • Ability to configure the remote session inactivity time before session termination; • Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates; • Ability to modify the behaviour of the transmission of audit data to an external IT entity; • Ability to manage the cryptographic keys; • Ability to re-enable an Administrator account; • Ability to set the time which is used for time-stamps; • Ability to manage the TOE’s trust store and designate X509.v3 certificates as trust anchors; • Ability to generate Certificate Signing Request (CSR) and process CA certificate response; • Ability to configure the authentication failure parameters for FIA_AFL.1; • Ability to administer the TOE locally; • Ability to configure the local session inactivity time before session termination or locking; • Ability to manage the trusted public keys database; The TOE is configured with specific user groups that can perform specific tasks. Only those in the admin group are able to access and Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 48 Requirement TSS Description perform updates. The filesystem ownership under Linux only allows certain users and groups to access the filesystem. Only authorized administrators can access the TOE’s trust store and modify or delete certificates within the trust store. So, non-privileged users are not able to update the system files. Command line access is restricted such that regular users do not have access to command line scripts used to manage MAGNUM. The web admin user named as “admin”, CLI user named as “etservice” and console admin user named as “configshell” are statically created on the system. These users cannot be removed from the system. Administrator roles are statically assigned. The users admin (configshell), and the web admin are all in the Administrator role. Users created by the web interface (i.e. web users) are implicitly, automatically assigned into the (“regular”) User role. Administrators can use console admin interface to administer the system locally via local console port. The web administrator and CLI can be used to administer MAGNUM over HTTPS and SSH respectively. The SSH is UI based for user configshell and CLI based for user- etservice. The Security Administrator has the ability to import, modify and delete the keys for SSH. For TLS, the Security Administrator can configure the parameters used for TLS operation, initiate the generation of new session keys during handshake operations, and terminate (delete) active sessions, which results in the secure destruction of the associated session keys. For X.509 certificates, the Security Administrator can configure certificates for use by the TOE, generate new certificate signing requests (CSRs) and associated key pairs, import externally generated certificates and keys, and delete certificates and associated keys from the TOE’s storage. The TOE restricts the ability to manage SSH (session keys), TLS (session keys), and any configured X.509 certificates (public and private key pairs) to security administrators via command line. FPT_APW_EXT.1 Passwords are the authentication data stored by the TOE. The TSF does not store plaintext password. The salted SHA-512 hash of the password is saved to disk (using the Linux PAM Unix module). Passwords for users of the web interface are stored in a PostgreSQL database and obfuscated using a salted Argon2 hash. Both the password file and the database reside on the filesystem, which is access controlled through Linux file permissions. Passwords are unable to be viewed through an interface specifically designed for that purpose. MAGNUM also uses Linux permissions to prevent accessing the obscured forms of the passwords. FPT_SKP_EXT.1 The TOE stores all session keys or public keys in secure storage that is not accessible through an interface to any user or administrators. Plaintext CSPs are stored either in volatile RAM (for session and ephemeral keys) or in plaintext files on disk partition (non-volatile) protected by Linux file permissions (for host keys and the firmware update public key), while non-plaintext CSPs include the salted SHA-512 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 49 Requirement TSS Description password hashes and the firmware update private key, which is not stored on the device at all. When the TOE is rebooted, all keys stored in volatile memory are subject to the clearing methods present in FCS_CKM.4. MAGNUM uses Linux file permissions to only allow the appropriate services programmatic access to protect private keys from being read. The TOE’s keys associated with its certificate for TLS are stored in a disk partition with file permissions that do not allow any user or administrator. None of these services have methods to expose the key beyond their immediate use. The method of protection of keys is described in the FCS_CKM.4 section of this table. FPT_STM_EXT.1 The TSF provides a reliable timestamp from the hardware clock on the TOE. Magnum provides accurate timestamps that can be updated via manual configuration by the administrator. System time is used to provide accurate time/date stamps on audit records, to track administrator inactivity and for the validation of X.509 certificates used in TLS communications. Administrators can, as needed, set the system time clock through serial port console menu after each card reboot. The new system time is also used to set the hardware clock, which is a clock that runs independently of any control program running in the CPU and even when MAGNUM is powered off. During MAGNUM system startup, system time is initialized to the time from the hardware clock. FPT_TST_EXT.1 The firmware is validated in the following two ways on startup: • MAGNUM invokes OpenSSL to display its version, which will trigger the built-in self-tests. This ensures that the crypto module has not been tampered with. These self-tests include: o SHA-256/384/512 KAT o HMAC-SHA-256/384/512 KAT o AES 128 GCM Encrypt and Decrypt KAT o AES 256 GCM Encrypt and Decrypt KAT o AES 128 CTR Encrypt and Decrypt KAT o AES 256 CTR Encrypt and Decrypt KAT o RSA 4096 SHA-256 Sign and Verify KAT o DRBG AES-CTR-256 KAT (invoking the instantiate, reseed, and generate functions) • MAGNUM verifies SHA-512 checksum of the kernel image along with all non-configuration files, including executable and shared object files. These tests verify that TOE firmware has not been modified, and all cryptographic functions are working correctly. If any of the self-tests fail, TOE prevents bootup, waits for 15 minutes, and then reboots. The reboot will continue until self-tests pass. The security administrator should report the issue to Evertz Technical Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 50 Requirement TSS Description Support by contacting service@evertz.com and should be immediately corrected. FPT_TUD_EXT.1 The MAGNUM server is typically deployed in a closed network without direct access to the internet. In these instances, Administrators are required to contact Evertz to receive notification of production updates directly or via email blast. Operators may verify the current version using the CLI menu ‘Version’ or on the web interface Config Management->Current System Info. The TOE supports delayed activation. Customers requiring secure delivery for the site policy can request secure courier delivery of software updates. Digital delivery of the updated firmware may be provided via SFTP digitally signed using RSA key size of 4096 bits and a hash algorithm SHA256. Instructions for SFTP transfer are found in [AGD] under the sections “Transfer Files using SFTP” and “Transfer Files using USB Drive”. Firmware updates are only done from the local CLI interface. When the administrator selects the update file the TSF will ask if the file should be installed. When the administrator selects [yes] the TSF automatically verifies the digital signature prior to installing the update. The result file (signature) is included in the firmware package together with the actual firmware binary. During upgrade, the signature file is first decrypted using the public key stored on MAGNUM, then the hashed value is re-calculated from the uploaded image binary file and then compared with the decrypted hash value. If the hashes match, MAGNUM proceeds to verify the firmware binary header against an Evertz-defined proprietary format. If there are no mismatches, the new firmware overwrites the existing version. If the digital signature fails verification the update is rejected, and an appropriate audit record is generated. If the digital signature succeeds, the upgrade proceeds and the firmware is installed onto the TOE. FTA_SSL.3 FTA_SSL_EXT.1 MAGNUM has a configurable timeout that can be modified using the console admin interface. The timeout is 60 minutes by default in secure mode, adjustable to anywhere between 1 and 60 minutes. When a timeout occurs, the user's session is terminated, and the user is logged out of the system. This applies to console, SSH, and web interactive sessions. FTA_SSL.4 On a local terminal, select "Logout" from the console admin interface to manually terminate an interactive session. On the command line interface, type ‘exit’ to manually terminate a remote interactive session via SSH, and on the WebGUI, select ‘Logout’ to manually exit a session FTA_TAB.1 MAGNUM is managed locally through the local console and remotely over SSH and the HTTPS web interface. Administrators access the console through directly connected USB keyboard and VGA monitor. The TSF presents the access banner prior to authentication when a user connects to the remote web UI and SSH or local console CLI described in the FIA_UIA_EXT.1, FIA_UAU_EXT.2 description. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 51 Requirement TSS Description The access banner can be modified from the console admin interface, under the Security menu, select “Edit Login Banner”. When modifications are complete, press Ctrl+X to save and exit the editor. FTP_ITC.1 Trusted channels are established between the TOE and a remote audit server and video switches. The TOE initiates the connection for remote audit servers and video switches. The TOE establishes a secure connection with IPX video switches using the stunnel application (built on OpenSSL), communicating over TLS with mutual X.509 certificate authentication. A separate trusted channel is used for the remote audit server, which communicates via Syslog over TLS and also employs mutual X.509 certificate authentication. The protocols listed are consistent with those specified in the requirement. FTP_TRP.1/Admin MAGNUM only communicates with Administrative Users via Trusted Paths. For remote administration this is restricted to a GUI over HTTPS/TLS or the command line over SSH. MAGNUM uses encryption and restricts the choices of ciphers, hashes, and key-exchange algorithms to those allowed by the NDcPP. 6.1 CAVP Algorithm Certificate Details Each of these cryptographic algorithms have been validated as identified in the table below. Table 15 – CAVP Algorithm Certificate References SFRs Algorithm in ST Implementation Name CAVP Algorithm CAVP Cert FCS_CKM.1 RSA schemes using cryptographic key sizes of [4096 bits] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1. MAGNUM Cryptographic Module, version 24.11.0 RSA KeyGen (FIPS186-4) (Modulo 4096) A6538 ECC schemes using ‘NIST curves’ [P-256, P-384, P- 521] that meet the following: FIPS PUB 186- 4, “Digital Signature Standard (DSS)”, Appendix B.4, or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3, “IT Security techniques - Digital signatures with ECDSA KeyGen (FIPS186-4) (Curve P-256,P-384, P-521) ECDSA KeyVer (FIPS186-4) (Curve P-256,P-384, P-521) A6538 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 52 appendix - Part 3: Discrete logarithm based mechanisms”, Section 6.6. FCS_CKM.2 Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” MAGNUM Cryptographic Module, version 24.11.0 KAS-ECC-SSC Sp800- 56Ar3 (Domain Parameter Generation Methods: P-256, P- 384, P-521) A6538 FCS_COP.1/ DataEncryption GCM mode and cryptographic key sizes 128 bits, 256 bits that meet: AES as specified in ISO 18033-3 and GCM as specified in ISO 19772 MAGNUM Cryptographic Module, version 24.11.0 AES-GCM (Key length 128,256) A6538 CTR mode and cryptographic key sizes 128 bits, 256 bits that meet: AES as specified in ISO 18033-3, and CTR as specified in ISO 10116. AES-CTR (Key length 128,256) FCS_COP.1/SigGen RSA Digital Signature Algorithm using key sizes of 4096 bits that meets FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 v2.2 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3 MAGNUM Cryptographic Module, version 24.11.0 RSA SigGen (FIPS186- 4) (Modulo 4096) RSA SigVer (FIPS186- 4) (Modulo 4096) A6538 Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 53 ECDSA schemes implementing [P-256, P- 384, P-521] curves that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST Recommended" curves ; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6. ECDSA SigGen (FIPS186-4) (Curve P-256, P- 384,P-521) ECDSA SigVer (FIPS186-4) (Curve P-256, P-384, P-521) A6538 FCS_COP.1/Hash SHA-256, SHA-384 and SHA-512 and message digest sizes 256, 384 and 512 bits MAGNUM Cryptographic Module, version 24.11.0 SHA-256 SHA-384 SHA-512 A6538 FCS_COP.1/ KeyedHash HMAC-SHA-256, HMAC- SHA-384 with key sizes 256 bits, 384 bits and message digest 256, 384 bits that meet the following: ISO/IEC 9797- 2:2011, Section 7 “MAC Algorithm 2” MAGNUM Cryptographic Module, version 24.11.0 HMAC-SHA-256 HMAC-SHA-384 A6538 FCS_RBG_EXT.1 CTR_DRBG (AES) in accordance with ISO/IEC 18031:2011 with a minimum of 256- bits MAGNUM Cryptographic Module, version 24.11.0 Counter DRBG (AES- 256) A6538 6.2 Cryptographic Key Destruction The table below describes the key zeroization provided by the TOE and as referenced in FCS_CKM.4. Table 16 – Key Storage and Zeroization Keys/CSPs Purpose Storage Location Method of Zeroization EC Diffie-Hellman Keys Key agreement and key establishment Plaintext in RAM Overwritten with zeroes when no longer needed Firmware Update Key Verification of firmware integrity when updating Public key is stored in plaintext in a separate Linux ‘cp’ command replaces the public key Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 54 Keys/CSPs Purpose Storage Location Method of Zeroization to new firmware versions using a SHA-256 hashed RSA signature. disk partition that uses Linux file permission. Private key is not stored or used on the TOE. file when importing a new file, instructing a part of the code to destroy the abstraction that represents the key file. HTTPS/TLS Server/Host Key RSA and EC private key used in the HTTPS/TLS protocols Plaintext in a separate disk partition that uses Linux file permission A single overwrite consisting of a pseudorandom pattern using the TSF’s RBG, then overwritten again with zeroes. Copy in RAM is overwritten with zeroes when no longer needed. HTTPS/TLS session authentication key HMAC -256, or HMAC - 384 key used for HTTPS/TLS session authentication. Plaintext in RAM Overwritten with zeroes when no longer needed. HTTPS/TLS Session Encryption Key AES (128, 256) key used for HTTPS/TLS session encryption Plaintext in RAM Overwritten with zeroes when no longer needed. SSH Server/Host key RSA private key used in the SSH protocol (key establishment, 4096- bits) Plaintext in a separate disk partition that uses Linux file permission A single overwrite consisting of a pseudorandom pattern using the TSF’s RBG, then overwritten again with zeroes. Copy in RAM is overwritten with zeroes when no longer needed. SSH Session Authentication Key GCM used for SSH session authentication Plaintext in RAM Overwritten with zeroes when no longer needed. SSH Session Encryption Key AES (128-bit, 256-bit) key used for SSH session encryption Plaintext in RAM Overwritten with zeroes when no longer needed. Locally Stored Passwords User Authentication Salted using SHA-512 in configuration file Overwritten with pseudorandom pattern using the TSF’s RBG/ zeros. Configuration Encryption Key Configuration Encryption Plaintext in a separate disk partition that uses Linux file permission Instructing a part of the code to destroy the abstraction that represents the key. Evertz Microsystems Ltd. MAGNUM-SC-CC2 Security Target 55 7 Acronym Table Acronyms should be included as an Appendix in each document Table 17 – Acronyms Acronym Definition AES Advanced Encryption Standard CA Certificate Authority CC Common Criteria CRL Certificate Revocation List CSR Certificate Signing Request DTLS Datagram Transport Layer Security EP Extended Package GUI Graphical User Interface IP Internet Protocol NDcPP Network Device Collaborative Protection Profile NIAP Nation Information Assurance Partnership OCSP Online Certificate Status Protocol PP Protection Profile RSA Rivest, Shamir & Adleman SFR Security Functional Requirement SSH Secure Shell ST Security Target TD Technical Decision TOE Target of Evaluation TLS Transport Layer Security TSS TOE Summary Specification AGD Administrative Guidance Document