Guardtime Black Lantern Common Criteria Assurance Activities Report

Transcription

1 Guardtime Black Lantern Common Criteria Assurance Activities Report Version December 2017 Prepared by: Accredited Testing & Evaluation Labs 6841 Benjamin Franklin Drive Columbia, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme

2 The Developer of the TOE: Guardtime 5151 California Avenue, Suite 210 Irvine, CA The TOE Evaluation was Sponsored by: Guardtime 5151 California Avenue, Suite 210 Irvine, CA Evaluation Personnel: Anthony Apted Greg Beaver Cody Cummins Heather Hazelhoff Common Criteria Versions Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, Revision 4, dated: September Common Evaluation Methodology Versions Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, dated: September Protection Profiles collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 Page i of iv

3 Table of Contents 1 Introduction Evidence Security Functional Requirement Assurance Activities Security Audit (FAU) Audit Data Generation (FAU_GEN.1) User Identity Association (FAU_GEN.2) Protected Audit Trail Storage (FAU_STG.1) Protected Audit Event Storage (FAU_STG_EXT.1) Counting Lost Audit Data (FAU_STG_EXT.2) Display Warning for Local Storage Space (FAU_STG_EXT.3) 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(1) Cryptographic Operation (Signature Generation and Verification (FCS_COP.1(2)) Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) Random Bit Generation (FCS_RBG_EXT.1) HTTPS Protocol (FCS_HTTPS_EXT.1) TLS Client Protocol with Authentication (FCS_TLSC_EXT.2) TLS Server Protocol with Mutual Authentication (FCS_TLSS_EXT.2) Identification and Authentication (FIA) Password Management (FIA_PMG_EXT.1) User Identification and Authentication (FIA_UIA_EXT.1) Password-based Authentication Mechanism (FIA_UAU_EXT.2) Page ii of iv

4 2.3.4 Protected Authentication Feedback (FIA_UAU.7) X.509 Certificate Validation (FIA_X509_EXT.1) X.509 Certificate Authentication (FIA_X509_EXT.2) X.509 Certificate Requests (FIA_X509_EXT.3) Management of Security Functions Behavior (FMT_MOF.1(1)/TrustedUpdate) Management of Security Functions Behavior (FMT_MOF.1(2)/Audit) Management of Security Functions Behavior (FMT_MOF.1(2)/AdminAct) Management of TSF Data (FMT_MTD.1) Management of Security Functions Behavior (FMT_MTD.1/AdminAct) 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 symmetric keys) (FPT_SKP_EXT.1) TSF Testing (FPT_TST_EXT.1) Trusted Update (FPT_TUD_EXT.1) Reliable Time Stamps (FPT_STM.1) TOE Access (FTA) TSF-initiated Session Locking (FTA_SSL_EXT.1) TSF-initiated Termination (FTA_SSL.3) User-initiated Termination (FTA_SSL.4) Default TOE Access Banners (FTA_TAB.1) Trusted Path/Channels (FTP) Inter-TSF trusted channel (FTP_ITC.1) Trusted Path (FTP_TRP.1) Security Assurance Requirements Class ADV: Development ADV_FSP.1 Basic Functional Specification Class AGD: Guidance Documents Page iii of iv

5 3.2.1 AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures ATE_IND.1 Independent Testing Conformance ATE_IND.1 Assurance Activity Class AVA: Vulnerability Assessment AVA_VAN.1 Assurance Activity Class ALC: Life-Cycle Support ALC_CMC.1 Labeling of the TOE Assurance Activity ALC_CMS.1 TOE CM Coverage Assurance Activity Page iv of iv

6 1 INTRODUCTION This document presents results from performing assurance activities associated with the Guardtime Black Lantern evaluation. This report contains sections documenting the performance of assurance activities associated with each of the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) as specified in collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 and including the following optional SFRs: FAU_STG.1, FAU_STG_EXT.2, FAU_STG_EXT.3, FCS_HTTPS_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.2, FMT_MOF.1(2)/ Audit, FMT_MOF.1(2)/AdminAct, and FMT_MTD.1/AdminAct. Note that, in accordance with NIAP Policy Letter #5, all cryptography in the TOE for which NIST provides validation testing of FIPS-approved and NIST-recommended cryptographic algorithms and their individual components must be NIST validated. The CCTL will verify that the claimed NIST validation complies with the NIAP-approved PP requirements the TOE claims to satisfy. The CCTL verification of the NIST validation will constitute performance of the associated assurance activity. As such, Test assurance activities associated with functional requirements within the scope of Policy Letter #5 are performed by verification of the relevant CAVP certification and not through performance of any testing as specified in the PP or its supporting document. 1.1 Evidence [ST] Black Lantern Security Target, Version 1.2, December 5, 2017 [AGD] Guardtime Black Lantern Guidance Documentation, Version 1.2, December 5, Page 1 of 69

7 2 SECURITY FUNCTIONAL REQUIREMENT ASSURANCE ACTIVITIES This section describes the assurance activities associated with the SFRs defined in the ST and the results of those activities as performed by the evaluation team. The assurance activities are derived from the Evaluation Activities for Network Device cpp, Version 1.0, February 2015, as modified by the following relevant NIAP Technical Decisions: TD0090: NIT Technical Decision for FMT_SMF.1.1 Requirement in NDcPP TD0095: NIT Technical Interpretations regarding audit, random bit generation, and entropy in NDcPP TD0111: NIT Technical Decision for third party libraries and FCS_CKM.1 in NDcPP and FWcPP TD0112: NIT Technical Decision for TLS testing in the NDcPP v1.0 and FW cpp v1.0. TD0113: NIT Technical Decision for testing and trusted updates in the NDcPP v1.0 and FW cpp v1.0 TD0116: NIT Technical Decision for a Typo in reference to RSASSA-PKCS1v1_5 in NDcPP and FWcPP TD0117 (supercedes TD0093): NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP TD0125: NIT Technical Decision for Checking validity of peer certificates for HTTPS servers TD0126: NIT Technical Decision for TLS Mutual Authentication TD0130: NIT Technical Decision for Requirements for Destruction of Cryptographic Keys TD0151: NIT Technical Decision for FCS_TLSS_EXT Testing - Issue 1 in NDcPP v1.0. TD0152: NIT Technical Decision for Reference identifiers for TLS in the NDcPP v1.0 and FW cpp v1.0 TD0153: NIT Technical Decision for Auditing of NTP Time Changes in the NDcPP v1.0 and FW cpp v1.0 TD0154: NIT Technical Decision for Versions of TOE Software in the NDcPP v1.0 and FW cpp v1.0 TD0155: NIT Technical Decision for TLSS tests using ECDHE in the NDcPP v1.0. TD0156: NIT Technical Decision for SSL/TLS Version Testing in the NDcPP v1.0 and FW cpp v1.0 TD0168: NIT Technical Decision for Mandatory requirement for CSR generation TD0185: NIT Technical Decision for Channel for Secure Update TD0187: NIT Technical Decision for Clarifying FIA_X509_EXT.1 test 1 TD0188: NIT Technical Decision for Optional use of X.509 certificates for digital signatures TD0199: NIT Technical Decision for Elliptic Curves for Signatures TD0201: NIT Technical Decision for Use of intermediate CA certificates and certificate Page 2 of 69

8 hierarchy depth TD0226: NIT Technical Decision for TLS Encryption Algorithms TD0228: NIT Technical Decision for CA certificates - basicconstraints validation TD0235: NIT Technical Decision adding DH group 14 to the selection in FCS_CKM Security Audit (FAU) Audit Data Generation (FAU_GEN.1) This requirement was modified per TD0153: NIT Technical Decision for Auditing of NTP Time Changes in the NDcPP v1.0 and FW cpp v TSS Assurance Activities None Defined 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. [AGD] Section 7.4 Audit Functionality provides a table of auditable events that is consistent with the auditable events table in the NDcPP for the claimed SFRs. The types of events audited by the TOE include: Audit Start/Stop Logging Login/Logout Attempts (Successful/Unsuccessful) All Management Activities of Security Related Configurations and Security Data o Setting security configuration parameter o Setting the login banner Generating/Importing of, Changing, or Deleting of Cryptographic Keys o Generating public and private keys o Failure to import a certificate o Deleting a private key Resetting Passwords o Changing own password successfully o Changing other's password successfully o A password change forced on login Start/Stop of (applicable) Services o Starting KSI aggregator All Use of Identification and Authentication Mechanism o Failed login from serial console o Successful login from serial console Page 3 of 69

9 o Adding a new user o Adding a role to a user o Deleting a role from a user o Disabling a user o Deleting a user o Deleting a user via REST o Creating a user via REST o Add a bad role to a user (failed action) Certificate Validation Attempts o Generating a CSR successfully o Importing a bad certificate o Successful TLS connection o Failed TLS connection o Revoked certificate Initiation of Software Update o Result of Software Update Attempts Time (sync) Change Initialization/Termination of Trusted Channel, Failure of the Trusted Channel Functions (TLS) o Initialization of trusted channel o Failure of trusted channel functions Initialization/Termination of Trusted Path, Failure of the Trusted Path Functions (TLS) o Initialization of trusted path o Failed initialization of trusted path Low Local Storage Space Warning for Logging [AGD] Section 7 Audit Functionality describes each audit record format type along with a brief description of each field. The description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of audit events. The evaluator shall also make a determination of the administrative actions that are relevant in the context of the cpp. 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 security relevant with respect to the cpp. 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 evaluator examined the supplied guidance documentation, identifying all mechanisms available to the administrator for configuring and managing the capabilities of the TOE. Those mechanisms related to the SFRs specified in the ST were identified and mapped to the applicable SFRs. In addition, the evaluator sought to confirm that all SFRs that would be expected to have a management capability related to them had appropriate management capabilities identified in the guidance documentation. The administrative actions identified as auditable are: Changing audit settings Configuration of syslog export settings Setting length requirement for passwords Page 4 of 69

10 Generating/import of, changing, or deleting of cryptographic keys Resetting passwords Creating a new user Configuring users with specified roles Deleting a role from a user Disabling a user Deleting a user Initiation of a software update Changes to time Configuring the banner displayed prior to authentication Test 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 created a table of the required audit records and identified the events that caused the event. The audit records are identified in the Guardtime Black Lantern Common Criteria Test Report and Procedures. 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. The evaluator verified that the audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. Logging of all activities related to trusted update should be tested in detail and with utmost diligence. 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. The evaluator verified that the audit records are generated for initiation, success, and failures related to the trusted update. The evaluator verified that 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 User Identity Association (FAU_GEN.2) TSS Assurance Activities This activity should be accomplished in conjunction with the testing of FAU_GEN Guidance Assurance Activities This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1. Page 5 of 69

11 Test Activities This activity should be accomplished in conjunction with the testing of FAU_GEN Protected Audit Trail Storage (FAU_STG.1) TSS Assurance Activities The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally and how these records are protected against unauthorized modification or deletion. [ST] Section 6.1 identifies the local audit storage size as being administrator configurable from 500MB to 2GB. When the local storage is full, the TOE drops all new records and keeps a counter of the audit records dropped. A Security Administrator user is capable of viewing the dropped audit records counter, and clearing local storage. The local audit records are protected against unauthorized modification or deletion by restricting the Deleting Starting / Stopping Storage size setting Management functionality of the audit records to the Security Administrator. The TOE checks the permissions of the administrator before executing the command. Non-administrators are not allowed to perform any audit management functions. The evaluator shall ensure that the TSS describes the conditions that must be met for authorized deletion of audit records. [ST] Section 6.1 restricts the deletion of audit records to the Security Administrator. The TOE checks the permissions of the administrator before executing the command Guidance Assurance Activities The evaluator shall examine the guidance documentation to determine that it describes any configuration required for protection of the locally stored audit data against unauthorized modification or deletion. [AGD] Section Configuring Local Audit Storage states that the Black Lantern protects itself against unauthorized modification and deletion of local audit logs by only permitting administrator users with Security Administrator role to manage the logging functionalities, which includes the clearing of local logs Test Activities Test 1: The evaluator shall access the audit trail as an unauthorized administrator and attempt to modify and delete the audit records. The evaluator shall verify that these attempts fail. The evaluator assumed the role of an unauthorized administrator and attempted to modify or delete the audit records. The attempts were unsuccessful. Page 6 of 69

12 Test 2: The evaluator shall access the audit trail as an authorized administrator and attempt to delete the audit records. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records authorized for deletion are deleted. The evaluator assumed the role of an authorized administrator and attempted to modify or delete the audit records. The attempts were successful Protected Audit Event Storage (FAU_STG_EXT.1) TSS Assurance Activity 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. [ST] Section 6.1 states that the TOE is capable of sending audit records to a specified external audit server or store it locally. The TOE protects its transmission of audit records by using TLS with mutual authentication to establish a trusted communication channel between itself and the external audit server. 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. If the TOE complies with FAU_STG_EXT.2 the evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3. The evaluator shall examine the TSS to ensure that it details the behaviour 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. [ST] Section 6.1 identifies the local audit storage size as being administrator configurable from 500MB to 2GB. When the local storage is full, the TOE drops all new records and keeps a counter of the audit records dropped. The audit records are protected against unauthorized access by limiting the access to the Security Administrator. A Security Administrator is capable of viewing the dropped audit records counter, and clearing local storage 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. [AGD] Section Trusted Communication Channel with an Audit Server describes how to establish the trusted channel to the audit server. Black Lantern uses the TLS protocol to establish a trusted Page 7 of 69

13 communication channel with a remote audit server. In this trusted communication channel, the Black Lantern acts a TLS client while the remote audit server acts as a TLS server. As part of establishing a TLS channel between the Black Lantern and the Audit Server, a handshake is required. During this handshake, the Black Lantern requests the Audit Server s certificate and certificate chain. Once received, the Black Lantern validates the certificate and certificate chain to the certificate of a trusted known Root Certificate Authority (CA). Therefore, the Black Lantern must have the Root CA s certificate that the Audit Server s certificate is linked to. Black Lantern is designed to use the certificate's Subject Alternative Name (SAN) as the key for certificate lookup when the SAN field is present. If the SAN field is not present, the Black Lantern uses the Common Name (CN) as the key for certificate lookup. In this particular use case, the SAN (or CN) is the hostname of the remote machine where it hosts the audit server. The Black Lantern associates each remote machine with a hostname. If the Audit Server hostname does not appear in the list when executing the getcert command, the Security Administrator can import the server s Root CA s certificate into the Black Lantern with the import command. [AGD] Section Management Interfaces identifies TCP Port 1610 (Syslog over TLS) as the audit server protocol. 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. [AGD] Section 7 Audit Functionality states that local and remote logging are independent capabilities and do not have behavioral impact on one another. When both capabilities are enabled, audit data is logged locally and then remotely. Log data is buffered in memory and flushed into file whenever the buffer is exceeded or when the user issues the " flush" option with the viewlog command on the Serial Console Interface (SCI). The content of remote and local audit data is identical. When local logging is enabled, audit data will be logged and stored locally on filesystem. When remote logging is enabled, audit data will be sent externally to a remote entity, as configured. Remote logging is performed using TLS over a TCP channel. 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. [AGD] Section Configuring Local Audit Storage states the Black Lantern warns the Security Administrator once there is 25% local storage space remaining by issuing local log storage warning audit records. Additional warnings are issued when the remaining capacity reaches 15%, 10%, 5%, 4%, 3%, 2%, and 1%. Once 0% storage is remaining for local logging, new local log data is dropped and a counter of all dropped log entries will begin incrementing to track these dropped entries. This dropped counter value will be available as a warning whenever the viewlog command is invoked. The description of possible configuration options and resulting behaviour correspond to those described in the TSS. Page 8 of 69

14 Test 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: 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 ran a Wireshark capture to capture traffic between the TOE and the audit server while logging out of the TOE to produce an audit. The evaluator verified that the traffic between the audit server and TOE is not visible in plaintext. The audit server uses Rsyslog 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 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 a) 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). b) 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) c) The TOE behaves as specified (for the option other action in FAU_STG_EXT.1.3). The evaluator queried the TOE and verified that it displayed how much storage space in MB was allocated for saving log files and then ran a script which performed actions repeatedly over the course of 24 hours in order to produce enough audits to reach the log storage size threshold. The evaluator viewed the logs to see that audit storage size warnings were produced. Viewing the log also described how many audits had been dropped since the storage size threshold was met Counting Lost Audit Data (FAU_STG_EXT.2) TSS Assurance Activities The evaluator shall examine the TSS to ensure that it details the possible options the TOE supports for information about the number of audit records that have been dropped, overwritten, etc. if the local storage for audit data is full. [ST] Section 6.1 states that when the local storage is full, the TOE drops all new records and keeps a counter of the audit records dropped. A Security Administrator user is capable of viewing the dropped audit records counter, and clearing local storage. There are two methods to clear the local storage, by removing the entire local storage data or by removing a subset of the local log data. Page 9 of 69

15 Guidance Assurance Activities The evaluator shall also ensure that the guidance documentation describes all possible configuration options and the meaning of the result returned by the TOE for each possible configuration. The description of possible configuration options and explanation of the result shall correspond to those described in the TSS. [AGD] Section Configuring Local Audit Storage states the Black Lantern warns the Security Administrator once there is 25% local storage space remaining by issuing local log storage warning audit records. Additional warnings are issued when the remaining capacity reaches 15%, 10%, 5%, 4%, 3%, 2%, and 1%. Once 0% storage is remaining for local logging, new local log data is dropped and a counter of all dropped log entries will begin incrementing to track these dropped entries. This dropped counter value will be available as a warning whenever the viewlog command is invoked. The description of possible configuration options and resulting behaviour correspond to those described in the TSS. The evaluator shall verify that the guidance documentation contains a warning for the administrator about the loss of audit data when he clears the local storage for audit records. [AGD] Section Clearing Local Log Data states that the entire local storage can be cleared by using the rm command. A warning states that this operation cannot be reversed and that all locally stored audit data will be permanently removed from the TOE. A subset of the local log data may also be cleared. Local log data is stored in individual files and can be deleted on a file-by-file basis. To remove log data, perform the ls command to display the list of log filenames, followed by the rm command to remove individual log files or the entire log directory. Wildcards are also permitted Test Activities This activity should be accomplished in conjunction with the testing of FAU_STG_EXT.1.2 and FAU_STG_EXT.1.3. The evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3. This activity was accomplished in conjunction with the testing of FAU_STG_EXT.1.2 and FAU_STG_EXT Display Warning for Local Storage Space (FAU_STG_EXT.3) TSS Assurance Activities The evaluator shall examine the TSS to ensure that it details how the user is warned before the local storage for audit data is full. [ST] Section 6.1 states that the TOE reports warning messages when the local storage capacity is at 25%, 15%, 10%, 5%, 4%, 3%, 2%, and 1% of available storage space. The warning messages are stored (local storage, external storage, or both) and managed in accordance with the TOE s audit log configuration. Page 10 of 69

16 Guidance Assurance Activities The evaluator shall also ensure that the guidance documentation describes how the user is warned before the local storage for audit data is full and how this warning is displayed or stored (since there is no guarantee that an administrator session is running at the time the warning is issued, it is probably stored in the log files). The description in the guidance documentation shall correspond to the description in the TSS. [AGD] Section Low Local Storage Space Warnings states the Black Lantern warns the Security Administrator once there is 25% local storage space remaining by issuing local log storage warning audit records. Additional warnings are issued when the remaining capacity reaches 15%, 10%, 5%, 4%, 3%, 2%, and 1%. The description in the guidance documentation corresponds to the description in the TSS Test Activities This activity should be accomplished in conjunction with the testing of FAU_STG_EXT.1.2 and FAU_STG_EXT.1.3. The evaluator shall verify that a warning is issued by the TOE before the local storage space for audit data is full. This activity was accomplished in conjunction with the testing of FAU_STG_EXT.1.2 and FAU_STG_EXT.1.3. The TOE displayed an x% storage remaining warning message before the local data storage was full. After the local storage space was exhausted, the TOE displayed the number of log entries that were dropped. 2.2 Cryptographic Support (FCS) Cryptographic Key Generation (FCS_CKM.1) TSS Assurance Activity 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. [ST] Section Cryptographic Key Management identifies the following key generation algorithms: RSA schemes using cryptographic key size of 2048 bits that meets FIPS PUB 186-4, Digital Signature Standard (DSS), Appendix B.3 The ST provides a footnote that states that RSA key size of 4096 is supported but it s not certified since there is no official NIST test to date. ECC schemes using NIST curves P-256, P-384, P-521 that meets FIPS PUB 186-4, Digital Signature Standard (DSS), Appendix B.4 Both schemes can be used to generate a Certificate Signing Request (CSR). Page 11 of 69

17 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 uses defined in this PP. [AGD] Section Key Generation provides the guidance for the Security Administrator to generate RSA and ECC key pairs using the genkey command. The TOE supports the following key types and lengths: RSA o 2048 bits o 4096 bits ECDSA o 256 bits o 384 bits o 521 bits Test Activities Performed in accordance with NIAP Policy Letter #5 Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying validation for RSA and ECC key generation, as follows. Algorithm Tested Capabilities Certificates RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, Digital Signature Standard (DSS), Appendix B.3 ECC schemes using NIST curves [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, Digital Signature Standard (DSS), Appendix B.4; FIPS 186-4: Key Generation: Provable Primes with Conditions: Modulus lengths: 2048, 3072 Primality Tests: C.3 Prerequisites: SHS, DRBG 186-4: Key Pair Generation: Curves: P-256, P-384, P-521 Public Key Validation: Curves: P-256, P-384, P-521 Prerequisites: SHS, DRBG RSA #2456 SHS #3697 DRBG #1472 ECDSA #1095 SHS #3697 DRBG #1472 Page 12 of 69

18 2.2.2 Cryptographic Key Establishment (FCS_CKM.2) TSS Assurance Activity 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. [ST] Section Cryptographic Key Management identifies the following cryptographic key establishment methods: Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography The supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. SP800-56B Key Establishment Schemes The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes. The TOE does not provide RSA-based key establishment schemes 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). [AGD] Section Key Establishment provides the guidance to configure the TOE to use Elliptic Curve-based key establishment schemes Test Activities Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying ECDSA-based key establishment, as follows. Algorithm Tested Capabilities Certificates Elliptic curve-based key establishment schemes] that meets the following: [NIST Special Publication A, Recommendation for Pair- Wise Key Establishment KAS ECC: Functions: Domain Parameter Generation, Domain Parameter Validation, Key Pair Generation Schemes: Ephemeral Unified: ECDSA #1488 SHS #3697 DRBG #1472 ECDSA #1095 Page 13 of 69

19 Schemes Using Discrete Logarithm Cryptography Key Agreement Roles: Initiator, Responder Parameter Sets: EC: Curve: P-256 SHA: SHA-256 ED: Curve: P-384 SHA: SHA-384 EE: Curve: P-521 SHA: SHA-512 Prerequisites: SHS, DRBG, ECDSA TLS: Supports TLS 1.2: SHA Functions: SHA-256, SHA-384, SHA-512 Prerequisites: SHS, HMAC CVL #1489 HMAC # Cryptographic Key Destruction (FCS_CKM.4) TSS Assurance Activity The evaluator shall check to ensure the TSS lists each type of plaintext key material and its origin and storage location. Modified by TD0130: Cryptographic Keys NIT Technical Decision for Requirements for Destruction of The TSS describes all relevant keys used in the implementation of SFRs, including cases where the keys are stored in a non-plaintext form. In the case of non-plaintext storage, the encryption method and relevant key-encrypting-key are identified in the TSS. [ST] Section Cryptographic Key Management states that the TOE does not store any keys in plaintext; all keys are encrypted at rest. For keys decrypted into volatile memory, once the keys are no longer needed, the TOE deallocates the memory back to the kernel. The memory gets zeroized when power is removed from the TOE. All keys are encrypted at rest with AES 256. The root or top-level key-encrypting key is also an AES 256 key derived from a special hardware-based secret value called the OTPMK (one time programmable Page 14 of 69

20 master key). The OTPMK is implemented in specially-designed circuitry by the chip manufacturer. Guardtime uses this key value to protect long-term keys stored on the TOE at rest. Section 6.2.1, Table 6 lists all of the relevant TOE keys and CSPs. The table lists all of the keys and provides a description of their intended usage. It also includes their method of generation, where they are stored, how they are destroyed, and how they are protected. The keys stored in SSD storage are destroyed by zeroizing the memory location, and then performing a read after write verify. The keys stored in RAM are destroyed by deallocating memory to kernel. The memory gets zeroized when power is removed. The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, etc.). [ST] Section Cryptographic Key Management states that for the keys decrypted into volatile memory, once the keys are no longer needed, the TOE deallocates the keys back to the kernel. The memory gets zeroized when power is removed from the TOE. The TOE does not store any keys in plaintext; all keys are encrypted at rest. The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write"). [ST] Section Cryptographic Key Management states that for the keys decrypted into volatile memory, once the keys are no longer needed, the TOE deallocates the keys back to the kernel. The memory gets zeroized when power is removed from the TOE Guidance Assurance Activities None defined Test Activities None defined Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1(1) TSS Assurance Activity None defined Guidance Assurance Activities None defined. Page 15 of 69

21 Test Activities Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying AES Data Encryption/Decryption, as follows. Algorithm Tested Capabilities Certificates AES-CBC (as defined in NIST SP A) AES-GCM (as defined in NIST SP D) AES-CBC: Modes: Decrypt, Encrypt Key Lengths: 128, 256 (bits) AES #4508 AES-GCM: Modes: Decrypt, Encrypt IV Generation: external Key Lengths: 128, 256 (bits) Cryptographic Operation (Signature Generation and Verification (FCS_COP.1(2)) TSS Assurance Activity None defined Guidance Assurance Activities None defined Test Activities Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications Signature Generation and Verification, as follows. Algorithm Tested Capabilities Certificates RSA schemes using cryptographic key sizes [of 2048-bit or greater] that meet the 186-4: Signature Generation PKCS1.5: AES #2456 SHS #3697 Page 16 of 69

22 following: [FIPS PUB 186-4, Digital Signature Standard (DSS), Section 4 For ECDSA schemes: FIPS PUB 186-4, Digital Signature Standard (DSS), Section 6 and Appendix D, Implementing NIST curves [P-256, P-384, P- 521]; ISO/IEC , Section 6.4 Mod 2048 SHA: SHA-256, SHA-384, SHA-512 Mod 3072 SHA: SHA-256, SHA-384, SHA-512 Signature Verification PKCS1.5: Mod 2048 SHA: SHA-256, SHA-384, SHA-512 Mod 3072 SHA: SHA-256, SHA-384, SHA-512 Prerequisite: SHS, DRBG ECDSA: 186-4: Key Pair Generation: Curves: P-256, P-384, P-521 Generation Methods: Testing Candidates Public Key Validation: Curves: P-256, P-384, P-521 Signature Generation: P-256 SHA: SHA-256, SHA-384, SHA- 512 P-384 SHA: SHA-256, SHA-384, SHA- 512 P-521 SHA: SHA-256, SHA-384, SHA- 512 Signature Verification: P-256 SHA: SHA-256, SHA-384, SHA- 512 P-384 SHA: SHA-256, SHA-384, SHA- 512 P-521 SHA: SHA-256, SHA-384, SHA- 512 Prerequisite: SHS, DRBG DRBG #1472 ECDSA #1095 SHS #3697, DRBG #1472 Page 17 of 69

23 2.2.6 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) TSS Assurance Activity The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. [ST] Section Cryptographic Operations states that the TOE performs cryptographic hashing services using SHA 1, SHA 256, SHA 384, and SHA 512 in accordance with ISO/IEC :2004.FIPS PUB Secure Hash Standard. Hashing is used as part of RSA and ECDSA key generation and verification Guidance Assurance Activities The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. [AGD] Section Hash Algorithms states that no configuration is available for hashing services. To establish a TLS communication channel, the hashing function is specified by cryptographic criteria, such as SHA-256, SHA-384, or SHA-512 of the given certificate Test Activities The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented testmacs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP. Byte-oriented Mode Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying Cryptographic Hashing, as follows. Algorithm Tested Capabilities Certificates SHS that meets: FIPS Pub or ISO/IEC :2004. SHA-1 SHA-256 SHA-384 SHA-512 SHS #3697 Page 18 of 69

24 2.2.7 Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) TSS Assurance Activity The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. [ST] Section Cryptographic Operations, Table 7 specifies the key length, hash function used, block size, and output MAC length used by the HMAC function Guidance Assurance Activities None defined Test Activities Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying Keyed Hash Algorithm, as follows. Algorithm Tested Capabilities Certificates HMAC that meets FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPS Pub 180-4, Secure Hash Standard or ISO/IEC :2011, Section 7 MAC Algorithm 2. HMAC-SHA-1 HMAC-SHA-256 HMAC-SHA-384 HMAC-SHA-512 Prerequisite: SHS HMAC #2979 SHS # Random Bit Generation (FCS_RBG_EXT.1) Assurance Activity Documentation shall be produced and the evaluator shall perform the activities in accordance with Appendix D of [NDcPP]. [ST] Section states that the TOE utilizes the Guardtime Crypto Support Library (CSL) Direct v1.0.0, to comply with the random bit generation SFRs. The TOE implements a NIST-approved AES-CTR Deterministic Random Bit Generator (DRBG), as specified in ISO/IEC 18031:2011 Table C.1 Security Strength Table for Hash Functions. The implementation uses one entropy source, which accumulates entropy from one hardware-based noise source, which has a minimum 256-bits of entropy. Page 19 of 69

25 TSS Assurance Activity None defined Guidance Assurance Activities None defined Test Activities Performed in accordance with NIAP Policy Letter #5. Section of [ST] ( Cryptographic Support ), Table 2 ( Black Lantern CAVP Certified Cryptographic Algorithms ) identifies the CAVP certifications verifying Random Bit Generation, as follows. Algorithm Tested Capabilities Certificates CTR_DRBG (AES) with entropy accumulated from one hardware noise source and one independent software-based noise source, providing a minimum 256 bits of entropy. Modes: AES-256 Prerequisite: AES DRBG #1472 AES # HTTPS Protocol (FCS_HTTPS_EXT.1) TSS Assurance Activity Modified per TD0125: NIT Technical Decision for Checking validity of peer certificates for HTTPS servers The evaluator shall check that the TSS describes how peer authentication is implemented when HTTPS protocol is used. [ST] Section HTTPS Implementation states that the TOE s HTTPS protocol complies with RFC 2818 and is implemented using TLS 1.2 (RFC 5246). The TOE performs mutual authentication and it expects the peer to present a valid certificate before establishing the connection Guidance Assurance Activities None defined Test Activities The evaluator shall perform the following tests: Page 20 of 69

26 a) Test 1: The evaluator shall attempt to establish an HTTPS connection with a web server, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. The evaluator imported the CA certificate and configured the TOE for remote administration. The traffic was captured and observed using Wireshark. The evaluator verified that communication between the TOE and the authentication server was encrypted via TLS. The evaluator physically disrupted the connection between the TOE and the authentication server. After 17 seconds the evaluator physically reconnected the syslog server and viewed that the communication was still encrypted. Other tests are performed in conjunction with the TLS evaluation activities. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test: Modified per TD0125: NIT Technical Decision for Checking validity of peer certificates for HTTPS servers If the peer presents a valid certificate during handshake is selected in FCS_HTTPS_EXT.1.3, then certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1 if HTTPS is used for FTP_TRP.1 or FTP_ITC.1. b) Test 2: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a valid certificate and certification path, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the selection listed in the ST occurs. The evaluator sent a certificate from the TLS client without the CA certificate loaded onto the TOE. The evaluator viewed an unsuccessful connection. The evaluator loaded the CA certificate needed to validate the client certificate to be used in the function. The evaluator ran a Wireshark capture and attempted to connect to the server. The evaluator viewed a successful connection TLS Client Protocol with Authentication (FCS_TLSC_EXT.2) This requirement has been modified per TD0226: NIT Technical Decision for TLS Encryption Algorithms TSS Assurance Activity FCS_TLSC_EXT.2.1 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. [ST] Section TLS Client Protocol with Mutual Authentication identifies the TOE when acting as a client implements only TLS 1.2 protocol and supports the following ciphersuites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Page 21 of 69