Version /31/18

Transcription

1 Assurance Activity Report (NDcPP20E) for Aruba, a Hewlett Packard Enterprise Company 2930F, 2930M, 3810M, and 5400R Switch Series running ArubaOS version Version /31/18 Prepared by: Gossamer Security Solutions Accredited Security Testing Laboratory Common Criteria Testing Catonsville, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Document: AAR-VID Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version /27/2018 Compton Initial draft Version /17/2018 Compton Addressed ECR Comments Version /23/2018 Compton Addressed ECR Comments Version /31/2018 Compton Addressed ECR Comments The TOE Evaluation was Sponsored by: Hewlett Packard Enterprise Company 8000 Foothills Blvd. Roseville, CA Evaluation Personnel: Tammy Compton Khai Van Common Criteria Versions: Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012 Common Evaluation Methodology Versions: Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012 GSS CCT Assurance Activity Report Page 2 of Gossamer Security Solutions, Inc.

3 TABLE OF CONTENTS 1. Introduction CAVP Testing Test Equivalency Protection Profile SFR Assurance Activities Security audit (FAU) Audit Data Generation (FAU_GEN.1) User identity association (FAU_GEN.2) Protected Audit Event Storage (FAU_STG_EXT.1) Cryptographic support (FCS) Cryptographic Key Generation (FCS_CKM.1) Cryptographic Key Establishment (FCS_CKM.2) Cryptographic Key Destruction (FCS_CKM.4) Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1/DataEncryption) Cryptographic Operation (Signature Generation and Verification) (FCS_COP.1/SigGen) Cryptographic Operation (Hash Algorithm) (FCS_COP.1/Hash) Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1/KeyedHash) HTTPS Protocol (NDcPP20E:FCS_HTTPS_EXT.1) Random Bit Generation (FCS_RBG_EXT.1) SSH Server Protocol (FCS_SSHS_EXT.1) TLS Client Protocol (FCS_TLSC_EXT.1) TLS Server Protocol (FCS_TLSS_EXT.1) Identification and authentication (FIA) Authentication Failure Management (FIA_AFL.1) Password Management (FIA_PMG_EXT.1) Protected Authentication Feedback (FIA_UAU.7) Password-based Authentication Mechanism (FIA_UAU_EXT.2) User Identification and Authentication (FIA_UIA_EXT.1) X.509 Certificate Validation (Rev) (FIA_X509_EXT.1/Rev X.509 Certificate Authentication (FIA_X509_EXT.2) X.509 Certificate Requests (FIA_X509_EXT.3) GSS CCT Assurance Activity Report Page 3 of Gossamer Security Solutions, Inc.

4 2.4 Security management (FMT) Management of security functions behaviour (FMT_MOF.1/ManualUpdate) Management of TSF Data (FMT_MTD.1/CoreData) Specification of Management Functions (FMT_SMF.1) Restrictions on Security Roles (FMT_SMR.2) Protection of the TSF (FPT) Protection of Administrator Passwords (FPT_APW_EXT.1) Protection of TSF Data (for reading of all pre-shared, symmetric and private keys) (FPT_SKP_EXT.1) Reliable Time Stamps (FPT_STM_EXT.1) TSF testing (FPT_TST_EXT.1) Trusted update (FPT_TUD_EXT.1) TOE access (FTA) TSF-initiated Termination (FTA_SSL.3) User-initiated Termination (FTA_SSL.4) TSF-initiated Session Locking (FTA_SSL_EXT.1) Default TOE Access Banners (FTA_TAB.1) Trusted path/channels (FTP) Inter-TSF trusted channel (FTP_ITC.1) Trusted Path (FTP_TRP.1/Admin) Protection Profile SAR Assurance Activities Development (ADV) Basic Functional Specification (ADV_FSP.1) Guidance documents (AGD) Operational User Guidance (AGD_OPE.1) Preparative Procedures (AGD_PRE.1) Life-cycle support (ALC) Labelling of the TOE (ALC_CMC.1) TOE CM Coverage (ALC_CMS.1) Tests (ATE) Independent Testing - Conformance (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability Survey (AVA_VAN.1) GSS CCT Assurance Activity Report Page 4 of Gossamer Security Solutions, Inc.

5 GSS CCT Assurance Activity Report Page 5 of Gossamer Security Solutions, Inc.

6 1. INTRODUCTION This document presents evaluations results of the Aruba, a Hewlett Packard Enterprise Company 2930F, 2930M, 3810M, and 5400R Switch Series running ArubaOS version NDcPP20E evaluation. This document contains a description of the assurance activities and associated results as performed by the evaluators. 1.1 CAVP TESTING The TOE has been CAVP tested. The following functions have been CAVP tested to meet the associated SFRs. Each platform family is included in the CAVP certificates referenced so all models are addressed by the testing. Functions Requirement Certificates Encryption/Decryption AES CBC, GCM (128 or 256 bits) FCS_COP.1/DataEncryption 4853 Cryptographic signature services RSA Digital Signature Algorithm (rdsa) (modulus 2048) FCS_COP.1/SigGen 2665 Cryptographic hashing SHA-1, SHA-256, SHA-384, SHA-512 (digest sizes 160, 256, FCS_COP.1/Hash , 512) Keyed-hash message authentication HMAC-SHA-1 (digest size 160) FCS_COP.1/KeyedHash 3249 Random bit generation AES-256 CTR_DRBG with software based noise sources with a minimum of 256 bits of non-determinism FCS_RBG_EXT Key generation RSA Key Generation (2048 bits) FCS_CKM ECDSA Key Generation (P-256, P-384) FCS_CKM Key Establishment CVL ECC KAS FCS_CKM TEST EQUIVALENCY The evaluation includes the following TOE platforms, with the specified processors and software images. The evaluation includes two unique software images which are compiled for each specific model. Aruba HPE Model # Processor Software Image Name Aruba 3810M Switch Series 3810M 24G 1-slot Switch (JL071A) 3810M 48G 1-slot Switch (JL072A) 3810M 24G PoE+ 1-slot Switch (JL073A) 3810M 48G PoE+ 1-slot Switch (JL074A) 3810M 16SFP+ 2-slot Switch (JL075A) 3810M 40G 8 HPE Smart Rate PoE+ 1-slot Switch (JL076A) Freescale P2020 Dual Core KB_16_04_0014.swi Aruba 5400R Switch Series GSS CCT Assurance Activity Report Page 6 of Gossamer Security Solutions, Inc.

7 5406R zl2 Switch (J9821A) 5412R zl2 Switch (J9822A) 5406R/5412R-24-port 10/100/1000Base- T PoE+ MACsec (No PSU) v3 zl2 Card (J9986A) 5406R/5412R-24p 1000BASE-T (No PSU) v3 zl2 Card (J9987A) 5406R/5412R-24p SFP (No PSU) v3 zl2 Card (J9988A) 5406R/5412R-12p PoE+ / 12p 1GbE SFP (No PSU) v3 zl2 Card (J9989A) 5406R/5412R-20p PoE+ / 4p SFP+ (No PSU) v3 zl2 Card (J9990A) 5406R/5412R-20p PoE+ / 4p 1/25/5/XGT PoE+ (No PSU) v3 zl2 Card (J9991A) 5406R/5412R-20p PoE+ / 1p 40GbE QSPF+ (No PSU) v3 zl2 Card (J9992A) 5406R/5412R-8p 1G/10GbE SFP+ v3 (No PSU) v3 zl2 Card (J9993A) 5406R/5412R-2-port 40GbE QSFP+ (No PSU) v3 zl2 Card (J9996A) Aruba 2930F Switch Series 2930F 24G 4SFP+ Switch (JL253A) 2930F 48G 4SFP+ Switch (JL254A) 2930F 8G PoE+ 2SFP+ Switch (JL258A) 2930F 24G PoE+ 4SFP+ Switch (JL263A) 2930F 48G PoE+ 4SFP+ Switch (JL264A) Dual Core ARM Coretex WC_16_04_0014.swi Aruba 2930M Switch Series 2930M 24G 1-slot Switch (JL319A) 2930M 24G PoE+ 1-slot Switch (JL320A) 2930M 48G 1-slot Switch (JL321A) 2930M 48G PoE+ 1-slot Switch (JL322A) 2930M 40 Port 1G + 8 Port SmartRate PoE+ (JL323A) 2930M 24 Port SmartRate PoE+ (JL324A) The Aruba 2930F and 2930M series switches run the same software (WC_16_04_0014.swi) on the same processor (Dual Core ARM Coretex). The Aruba 3810M and 5400R series switches run the same software (KB_16_04_0014.swi) on the same processor (Freescale P2020 Dual Core). All of the models provide the same security services. The evaluation team fully tested each software image, which included testing of each processor. The evaluation team tested the Aruba-3810M-48G-1, Aruba-2930M-48G-PoEP, and the Aruba-2930F-48G-4SFPP. Although the 2930M could have been eliminated from testing, the device was already set up and configured to operate in CC mode with the appropriate configuration, so Gossamer decided to include the 2930M test results. Additionally, in terms of hardware, the 5400R is very close to the 3810M. The only major difference between the two is that the 5400R boasts more volatile memory than the 3810M (4 GB DDR3 SDRAM for the 5400R, 1 GB DDR3 SDRAM for the 3810M) which is not security relevant. GSS CCT Assurance Activity Report Page 7 of Gossamer Security Solutions, Inc.

8 The underlying architecture of each TOE appliance consists of hardware that supports physical network connections, memory, and processor and software that implements switching functions, configuration information and drivers. While hardware varies between different appliance models, the software code remains the same for the different switch families, and there are only two variations of the software. The software code contains all the security functions that are claimed in the security target. GSS CCT Assurance Activity Report Page 8 of Gossamer Security Solutions, Inc.

9 2. PROTECTION PROFILE SFR ASSURANCE ACTIVITIES This section of the AAR identifies each of the assurance activities included in the claimed Protection Profile and describes the findings in each case. 2.1 SECURITY AUDIT (FAU) AUDIT DATA GENERATION (FAU_GEN.1) FAU_GEN FAU_GEN.1.2 Component TSS Assurance Activities: For the administrative task of generating/import of, changing, or deleting of cryptographic keys as defined in FAU_GEN.1.1c, the TSS should identify what information is logged to identify the relevant key. For distributed TOEs the evaluator shall examine the TSS to ensure it describes which auditable events are generated and recorded by which TOE components. The evaluator shall confirm that all components defined as generating audit information for a particular SFR should also contribute to that SFR as defined in the mapping of SFRs to TOE components, and that the audit records generated by each component cover all the SFRs that it implements. Section 6.1 states that for cryptographic keys, the act of importing and deleting a key is audited and the associated administrator account that performed the action is recorded. There is no notion of changing a key it is either imported or deleted. Component Guidance Assurance Activities: The evaluator shall check the guidance documentation and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the cpp is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of audit events. GSS CCT Assurance Activity Report Page 9 of Gossamer Security Solutions, Inc.

10 The evaluator shall also make a determination of the administrative actions related to TSF data related to configuration changes. The evaluator shall examine the guidance documentation and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the cpp. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are related to TSF data related to configuration changes. The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it. The List of Auditable Events (CC Required) section of the Admin Guide contains a list of all the required audit events. Below is a mapping of audit events to the requirements. Requirement Auditable Events Additional Content FAU_GEN.1 None None Shutdown Audit Services I 10/02/17 14:07: mgr: syslog: Information logging stopped on the SYSLOG server over UDP protocol Startup Audit Services I 10/02/17 14:06: mgr: syslog: Information logging started on the SYSLOG server over UDP protocol FAU_GEN.2 None None FAU_STG_EXT.1 None None FCS_CKM.1 None None FCS_CKM.2 None None FCS_CKM.4 None None FCS_COP.1(1) None None FCS_COP.1(2) None None FCS_COP.1(3) None None FCS_COP.1(4) None None FCS_HTTPS_EXT.1 Failure to establish a HTTPS Session. Reason for failure. Oct 30 16:30: ssl: User :TLS connection failed for WEB-UI session from due to cipher mismatch. Oct 30 16:41: ssl: User :TLS connection failed for WEB-UI session from FCS_RBG_EXT.1 None None FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure Success: Oct 26 19:10: auth: User 'manager' logged in from to SSH session Failure: Oct 27 13:13: auth: Invalid user name/password on SSH session User 'user' is trying to login from Oct 25 20:46: ssh: User :Login failed for SSH session from due to cipher mismatch. Oct 25 18:32: ssh: User : SSH session aborted due to public-key authentication failure FCS_TLSS_EXT.1 Failure to establish a TLS Session. Reason for failure. GSS CCT Assurance Activity Report Page 10 of Gossamer Security Solutions, Inc.

11 Wrong Cipher Failure Oct 17 16:53: ssl: User :TLS connection failed for WEB-UI session from due to cipher mismatch. (5 times in 60 seconds) General Failures Feb 1 21:14:22 Aruba-2930M-48G ssl: User :TLS connection failed for WEB-UI session from FCS_TLSC_EXT.1 Failure to establish a TLS Session. Reason for failure. Jan 1 00:17: ssl: User syslogtask:tls connection failed for SYSLOG session from (1 times in 60 seconds) Oct 17 18:40: ssl: SSL Syslog TLS failed: no certificate present FIA_AFL.1 Unsuccessful login attempts limit is met or exceeded. Origin of the attempt (e.g., IP address). Oct 27 13:13: auth: User 'user' from is locked out for 120 seconds FIA_PMG_EXT.1 None None FIA_UAU.7 None None FIA_UAU_EXT.2 All use of identification and Origin of the attempt (e.g., IP address). authentication mechanism. Tested as part of FIA_UIA_EXT.1 FIA_UIA_EXT.1 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). HTTPS: Login: Oct 2 14:42: auth: User 'manager' logged in from to WEB_UI session Logout: Oct 2 14:42: auth: User 'manager' logged out of WEB_UI session from Failed Login: Oct 2 14:41: auth: Invalid user name/password on WEB-UI session User 'manager' is trying to login from SSH: Login: Oct 2 14:56: auth: User 'manager' logged in from to SSH session Logout: Oct 2 14:56: auth: User 'manager' logged out of SSH session from Failed Login: Oct 2 14:55: auth: Invalid user name/password on SSH session User 'manager' is trying to login from Public Key Login: Oct 25 14:20: ssh: User manager : SSH session established with public-key authentication GSS CCT Assurance Activity Report Page 11 of Gossamer Security Solutions, Inc.

12 FIA_X509_EXT.1 Publid Key Failed Login: Oct 25 14:30: ssh: User (null) : SSH session aborted due to public-key authentication failure Unsuccessful attempt to validate a Reason for failure. certificate. General Failures: Feb 16 17:46:39 Aruba-2930M-48G ssl: User syslogtask:tls connection failed for SYSLOG session from Revoked Certificate: Mar 1 11:23:36 Aruba-2930F-48G crypto: SSL connection failed as the server certificate with serial number "008E" is revoked from the OCSP response. FIA_X509_EXT.2 None None FIA_X509_EXT.3 None None FMT_MOF.1/ManualUpdate Any attempt to initiate a manual None update FMT_MTD.1/CoreData All management activities of TSF None data. FMT_SMF.1 None None FMT_SMR.2 None None FPT_APW_EXT.1 None None FPT_SKP_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). Sep 9 10:00: mgr: Updated time by seconds. Previous time was Fri Oct 20 19:50: Current time is Fri Sep 9 10:00: FPT_TST_EXT.1 None None FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure). None Oct 27 15:17: tftp: Transfer completed Oct 27 15:17: update: Firmware image contains valid signature. Oct 27 15:18: update: User 'manager' : Secondary Image updated via TFTP from completed.firmware version: #012 Before update: WC After update : WC FPT_TUD_EXT.2 Failure of update Reason for failure (including identifier of invalid certificate) Oct 27 16:25: update: Aborted. Firmware image signature is not valid. Oct 25 12:21: update: Aborted. Firmware image does not contain a signature. FTA_SSL.3 The termination of a remote session by the session locking mechanism. HTTPS None GSS CCT Assurance Activity Report Page 12 of Gossamer Security Solutions, Inc.

13 FTA_SSL.4 FTA_SSL_EXT.1 (if lock the session is selected) FTA_SSL_EXT.1 (if terminate the session is selected) Oct 20 12:11: auth: User 'manager' has been logged out from due to session timeout SSH Oct 20 18:36: auth: User 'manager' logged out of CONSOLE session from The termination of an interactive None session. Oct 20 18:36: auth: User 'manager' logged out of CONSOLE session from Any attempts at unlocking of an None interactive session. Oct 20 17:55: auth: User 'manager' logout from due to inactivity timer timeout for CONSOLE session The termination of a local None session by the session locking mechanism. N/A terminate the session was not selected. FTA_TAB.1 None None FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. Initiation Oct 17 18:40: mgr: syslog: Information logging started on the SYSLOG server over TLS protocol Termination Oct 18 12:12: ssl: User 'syslogtask': logged out of SSL session for SYSLOG from Oct 18 13:04: mgr: syslog: Information logging stopped on the SYSLOG server gss.example.com over TLS protocol FTP_TRP.1/Admin Failure Jan 1 00:17: ssl: User syslogtask:tls connection failed for SYSLOG session from (1 times in 60 seconds) Oct 17 18:40: ssl: SSL Syslog TLS failed: no certificate present Initiation of the trusted path. Termination of the trusted path. Failure of the trusted path functions. Identification of the claimed user identity. TLS: Initiation Oct 2 14:42: auth: User 'manager' logged in from to WEB_UI session Termination Feb 28 10:53:12 Aruba-3810M-48G auth: User 'manager' logged out of WEB_UI session from Failure Feb 1 21:14:22 Aruba-2930M-48G ssl: User :TLS connection failed for WEB-UI session from GSS CCT Assurance Activity Report Page 13 of Gossamer Security Solutions, Inc.

14 SSH: Initiation Oct 26 19:10: auth: User 'manager' logged in from to SSH session Termination Dec 1 09:07: auth: User 'manager' logged out of SSH session from Failure Oct 24 12:26: ssh: User :Login failed for SSH session from due to cipher mismatch. Tested as part of FCS_TLSC\S_EXT.1 From a review of the ST, the Admin Guide, and through testing, the evaluator also determined that the guidance contains all of the administrative actions and their associated audit events that are relevant to the PP and to use of the TOE. These administrative actions are consistent with the security requirements implemented in the TOE and were found to have appropriate management capabilities identified in the guidance documentation. Auditable Events Ability to administer the TOE locally and remotely Local console admin login Oct 20 13:53: auth: User 'manager' logged in from to CONSOLE session SSH admin login Oct 20 14:03: auth: User 'manager' logged in from to SSH session HTTPS login Oct 20 16:30: auth: User 'manager' logged in from to WEB_UI session Configure Access Banner Oct 20 10:49: system: Message of the day(motd) banner is modified. Oct 20 15:18: system: The post-login banner message is modified. Inactivity Timeout Setting HTTPS I 10/27/17 12:26: system: User:'manager':The command:'web-management idle-timeout 160' is executed. SSH/Console Oct 20 13:51: console: The console/telnet/ssh session idle timeout is set to 120 seconds. Oct 20 13:51: console: The console idle timeout is set to 120 seconds. Updating the TOE and to verify its digital signature before installing Oct 27 15:17: tftp: Transfer completed Oct 27 15:17: update: Firmware image contains valid signature. Oct 27 15:18: update: User 'manager' : Secondary Image updated via TFTP from completed.firmware version: #012 Before update: WC After update : GSS CCT Assurance Activity Report Page 14 of Gossamer Security Solutions, Inc.

15 WC Configure Secure Connection with Audit Server Tunnel Up Oct 17 18:40: mgr: syslog: Information logging started on the SYSLOG server over TLS protocol Tunnel Down Oct 18 12:12: ssl: User 'syslogtask': logged out of SSL session for SYSLOG from Oct 18 13:04: mgr: syslog: Information logging stopped on the SYSLOG server gss.example.com over TLS protocol Configuring the cryptographic functionality TLS Cipher Change Oct 18 12:12: tls: The 'strong' cipher suite 'ecdhe-rsa-aes256-sha' is configured for application 'syslog' with lowest TLS version tls1.2. Re-enabling an Administrator account Oct 18 14:11: auth: User manager : Manager mode password is set Setting the time used for time-stamps Sep 9 10:00: mgr: Updated time by seconds. Previous time was Fri Oct 20 19:50: Current time is Fri Sep 9 10:00: Configuring password complexity and length Oct 23 14:04: auth: The minimum password length is modified for user all to 15. Update the local passwords to comply with the modified password length. Oct 23 14:12: auth: The password composition for character type upper case is set to length of 3. Oct 23 14:12: auth: The password composition for character type lower case is set to length of 3. Oct 23 14:12: auth: The password composition for character type special character is set to length of 3. Oct 23 14:12: auth: The password composition for character type number is set to length of 3. Component Testing Assurance Activities: The evaluator shall test the TOE's ability to correctly generate audit records by having the TOE generate audit records for the events listed in the table of audit events and administrative actions listed above. This should include all instances of an event: for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries. For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of auditable events to TOE components in the Security Target. For all events involving more than one TOE component when an audit event is triggered, the evaluator has to check that the event has been audited on both sides (e.g. failure of building up a secure communication channel between the two components). This is not limited to error cases but GSS CCT Assurance Activity Report Page 15 of Gossamer Security Solutions, Inc.

16 includes also events about successful actions like successful build up/tear down of a secure communication channel between TOE components. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. The evaluator created a list of the required audit events. The evaluator then collected the audit events when running the other security functional tests described by the protection profiles. For example, the required event for FPT_STM.1 is Changes to Time. The evaluator collected these audit records when modifying the clock using administrative commands. The evaluator then recorded these audit events in the proprietary Detailed Test Report (DTR). The security management events are handled in a similar manner. When the administrator was required to set a value for testing, the audit record associated with the administrator action was collected and recorded in the DTR USER IDENTITY ASSOCIATION (FAU_GEN.2) FAU_GEN.2.1 Component Component Component Testing Assurance Activities: This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1. For distributed TOEs the evaluator shall verify that where auditable events are instigated by another component, the component that records the event associates the event with the identity of the instigator. The evaluator shall perform at least one test on one component where another component instigates an auditable event. The evaluator shall verify that the event is recorded by the component as expected and the event is associated with the instigating component. It is assumed that an event instigated by another component can at least be generated for building up a secure channel between two TOE components. If for some reason (could be e.g. TSS or Guidance Documentation) the evaluator would come to the conclusion that the overall TOE does not generate any events instigated by other components, then this requirement shall be omitted. Test - See FAU_GEN.1.1 for the audit record generation test PROTECTED AUDIT EVENT STORAGE (FAU_STG_EXT.1) FAU_STG_EXT.1.1 GSS CCT Assurance Activity Report Page 16 of Gossamer Security Solutions, Inc.

17 FAU_STG_EXT FAU_STG_EXT.1.3 Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. The evaluator shall examine the TSS to ensure that it details the behavior of the TOE when the storage space for audit data is full. When the option 'overwrite previous audit record' is selected this description should include an outline of the rule for overwriting audit data. If 'other actions' are chosen such as sending the new audit data to an external IT entity, then the related behaviour of the TOE shall also be detailed in the TSS. The evaluator shall examine the TSS to ensure that it details whether the transmission of audit information to an external IT entity can be done in real-time or periodically. In case the TOE does not perform transmission in real-time the evaluator needs to verify that the TSS provides details about what event stimulates the transmission to be made as well as the possible as well as acceptable frequency for the transfer of audit data. 33 For distributed TOEs the evaluator shall examine the TSS to ensure it describes to which TOE components this SFR applies and how audit data transfer to the external audit server is implemented among the different TOE components (e.g. every TOE components does its own transfer or the data is sent to another TOE component for central transfer of all audit events to the external audit server). 34 For distributed TOEs the evaluator shall examine the TSS to ensure it describes which TOE components are storing audit information locally and which components are buffering audit information and forwarding the information to another TOE component for local storage. For every component the TSS shall describe the behaviour when local storage space or buffer space is exhausted. GSS CCT Assurance Activity Report Page 17 of Gossamer Security Solutions, Inc.

18 Section 6.1 of the ST states that the TOE uses the TLS protocol to send generated audit records to an external syslog server. It further explains that by default, all event logs are sent to the set of configured syslog servers as well as the local store. The TOE supports up to 6400 log entries locally. The local audit log is a circular buffer and when the maximum number of entries is reached, the oldest log entries are overwritten and a warning audit event is created when the log reaches 80%. By default, all event logs are sent to the set of configured syslog servers as well as the local store with the exception of console commands. The console commands must be sent to the syslog server using a manual procedure described in the evaluated Guidance document (see Section 1.4.2). The Guidance recommends manually sending the audit logs when the warning message is received. Component Guidance Assurance Activities: The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and 'cleared' periodically by sending the data to the audit server. The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behaviour of the TOE for each possible configuration. The description of possible configuration options and resulting behaviour shall correspond to those described in the TSS. The Admin Guide contains a section Trust Anchors and Credentials for Syslog that explains how to generate a certificate signing request and install certificates on the TOE so the TOE can establish a TLS connection with a syslog server. The following section Creating a Trusted Channel with a Remote Syslog Server explains how to establish the connection and transfer audit data to the syslog server. The Audit Functionality section states that events are synchronized with remote log servers whenever new messages are received. Component Testing Assurance Activities: Testing of the trusted channel mechanism for audit will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following additional test for this requirement: a) Test 1: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator's choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing. The evaluator shall verify that the TOE is capable of transferring audit data to an external audit server automatically without administrator intervention. b) Test 2: The evaluator shall perform operations that generate audit data and verify that this data is stored locally. The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behaviour defined in FAU_STG_EXT.1.3. Depending on the configuration this means GSS CCT Assurance Activity Report Page 18 of Gossamer Security Solutions, Inc.

19 that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and then verifies that 1) The audit data remains unchanged with every new auditable event that should be tracked but that the audit data is recorded again after the local storage for audit data is cleared (for the option 'drop new audit data' in FAU_STG_EXT.1.3). 2) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option 'overwrite previous audit records' in FAU_STG_EXT.1.3) 3) The TOE behaves as specified (for the option 'other action' in FAU_STG_EXT.1.3). c) Test 3: If the TOE complies with FAU_STG_EXT.2/LocSpace the evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2/LocSpace are correct when performing the tests for FAU_STG_EXT.1.3. d) Test 4: For distributed TOEs, Test 1 defined above should be applicable to all TOE components that forward audit data to an external audit server. For the local storage according to FAU_STG_EXT.1.2 and FAU_STG_EXT.1.3 the Test 2 specified above shall be applied to all TOE components that store audit data locally. For all TOE components that store audit data locally and comply with FAU_STG_EXT.2/LocSpace Test 3 specified above shall be applied. The evaluator shall verify that the transfer of audit data to an external audit server is implemented. Test 1 - The evaluator configured the system (per guidance) to securely transfer audit data. The evaluator then captured network traffic between the TOE and the external audit server. The evaluator verified that the packet capture showed the audit data was not cleartext on the network. This was tested in conjunction with FPT_ITC_EXT.1, test 1. Test 2 - The evaluator also continued to generate audit data until the local storage space was exceeded. The evaluator verified that when the local audit storage was filled to the maximum, the existing audit data was overwritten based on the following rule: overwrite oldest records first. Tests 3 and 4 are not applicable. 2.2 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (FCS_CKM.1) FCS_CKM.1.1 GSS CCT Assurance Activity Report Page 19 of Gossamer Security Solutions, Inc.

20 Component TSS Assurance Activities: The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. Section 6.2 explains the ST indicates that the TOE generates RSA and ECDH asymmetric keys as part of TLS key establishment as part of TLS as described in the section above. The TOE acts as both a client and a server. The TOE supports Diffie-Hellman key generation for SSH key establishment where the TOE is acting as a server. The TOE also provides the administrator the ability to generate or import either an ECDSA (P-256 or P-384) or RSA (2048) key to use for TLS. This is consistent with the selection made by the FCS_CKM.1 SFR in ST. Component Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all cryptographic protocols defined in the Security Target. The Admin Guide explains how to set the selected algorithm and associated key sizes for SSH and for TLS. In the SSH section, it explains how to disable algorithms outside the evaluated configuration. In the TLS section, it provides a list of evaluated ciphers and a list of ciphers that must be disabled along with the instructions for disabling them. Component Testing Assurance Activities: Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. Key Generation for FIPS PUB RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: a) Random Primes: - Provable primes - Probable primes b) Primes with Conditions: - Primes p1, p2, q1, q2, p and q shall all be provable primes - Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes - Primes p1, p2, q1, q2, p and q shall all be probable primes GSS CCT Assurance Activity Report Page 20 of Gossamer Security Solutions, Inc.

21 To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Key Generation for Elliptic Curve Cryptography (ECC) FIPS ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. FIPS Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. Key Generation for Finite-Field Cryptography (FFC) The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: - Primes q and p shall both be provable primes - Primes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator g: - Generator g constructed through a verifiable process - Generator g constructed through an unverifiable process. The Key generation specifies 2 ways to generate the private key x: - len(q) bit output of RBG where 1 <=x <= q-1 GSS CCT Assurance Activity Report Page 21 of Gossamer Security Solutions, Inc.

22 - len(q) + 64 bit output of RBG, followed by a mod q-1 operation and a +1 operation, where 1<= x<=q-1. The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm - g!= 0,1 - q divides p-1 - g^q mod p = 1 - g^x mod p = y for each FFC parameter set and key pair. Testing for FFC Schemes using Diffie-Hellman group 14 is done as part of testing in CKM.2.1. (TD0291 applied) The TOE has been CAVP tested. The TOE has the following CAVP certificates for key generation: RSA #2665 ECDSA # CRYPTOGRAPHIC KEY ESTABLISHMENT (FCS_CKM.2) FCS_CKM.2.1 Component TSS Assurance Activities: The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme (including whether the TOE acts as a sender, a recipient, or both). If Diffie-Hellman group 14 is selected from FCS_CKM.2.1, the TSS shall describe how the implementation meets RFC 3526 Section 3. GSS CCT Assurance Activity Report Page 22 of Gossamer Security Solutions, Inc.

23 Section 6.2, Table 5 in the ST indicates that the TOE supports RSA 2048 bit and ECDSA curves P-256 andp-384 for key establishment. This is consistent with the FCS_CKM.1.1 requirement. The TOE also supports Diffie-Hellman-group- 14 meets RFC 3526, Section 3 by virtue of using a 2048-bit MODP group for key establishment. RSA and Diffie-Hellman-group-14are used to support the SSH protocol and RSA and ECDSA are used in support of TLS. The TOE is an SSH server and a TLS client and server as presented in the ST. Component Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). The Admin Guide explains how to set the selected algorithm and associated key sizes for SSH and for TLS. In the SSH section, it explains how to disable algorithms outside the evaluated configuration. In the TLS section, it provides a list of evaluated ciphers and a list of ciphers that must be disabled along with the instructions for disabling them. Component Testing Assurance Activities: Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE using the applicable tests below. SP800-56A Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the DKM, the corresponding TOE's public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields. If the TOE does not use a KDF defined in SP A, the evaluator shall obtain only the public keys and the hashed value of the shared secret. GSS CCT Assurance Activity Report Page 23 of Gossamer Security Solutions, Inc.

24 The evaluator shall verify the correctness of the TSF's implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another party's valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator's public keys, the TOE's public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties' static public keys, both parties' ephemeral public keys and the TOE's static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE's results with the results using a known good implementation verifying that the TOE detects these errors. SP800-56B Key Establishment Schemes If the TOE acts as a sender, the following assurance activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: a) To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector. If the TOE acts as a receiver, the following assurance activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: GSS CCT Assurance Activity Report Page 24 of Gossamer Security Solutions, Inc.