Guardtime Black Lantern Common Criteria Assurance ... · Page i of iv The Developer of the TOE:...

Guardtime

Black Lantern

Common Criteria

Assurance Activities Report

Version 1.0

7 December 2017

Prepared by:

Accredited Testing & Evaluation Labs

6841 Benjamin Franklin Drive

Columbia, MD 21046

Prepared for:

National Information Assurance Partnership

Common Criteria Evaluation and Validation Scheme

Page i of iv

The Developer of the TOE: Guardtime

5151 California Avenue, Suite 210

Irvine, CA 92617

The TOE Evaluation was Sponsored by: Guardtime

5151 California Avenue, Suite 210

Irvine, CA 92617

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 2012.

Common Criteria for Information Technology Security Evaluation Part 2: Security Functional

Components, Revision 4, dated: September 2012.

Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance

Components, Revision 4, dated: September 2012.

Common Evaluation Methodology Versions

Common Methodology for Information Technology Security Evaluation, Evaluation

Methodology, Version 3.1, Revision 4, dated: September 2012.

Protection Profiles

collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015

Page ii of iv

Table of Contents

1 Introduction ........................................................................................................................ 1

1.1 Evidence ......................................................................................................................................... 1

2 Security Functional Requirement Assurance Activities ................................................... 2

2.1 Security Audit (FAU) .................................................................................................................. 3

2.1.1 Audit Data Generation (FAU_GEN.1) ...................................................................... 3

2.1.2 User Identity Association (FAU_GEN.2) ................................................................. 5

2.1.3 Protected Audit Trail Storage (FAU_STG.1) ........................................................... 6

2.1.4 Protected Audit Event Storage (FAU_STG_EXT.1) .............................................. 7

2.1.5 Counting Lost Audit Data (FAU_STG_EXT.2) ...................................................... 9

2.1.6 Display Warning for Local Storage Space (FAU_STG_EXT.3) ......................... 10

2.2 Cryptographic Support (FCS) .................................................................................................... 11

2.2.1 Cryptographic Key Generation (FCS_CKM.1) ....................................................... 11

2.2.2 Cryptographic Key Establishment (FCS_CKM.2) .................................................. 13

2.2.3 Cryptographic Key Destruction (FCS_CKM.4) ...................................................... 14

2.2.4 Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1(1) 15

2.2.5 Cryptographic Operation (Signature Generation and Verification

(FCS_COP.1(2)) ............................................................................................................. 16

2.2.6 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) ............................. 18

2.2.7 Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) ................ 19

2.2.8 Random Bit Generation (FCS_RBG_EXT.1) .......................................................... 19

2.2.9 HTTPS Protocol (FCS_HTTPS_EXT.1) ................................................................... 20

2.2.10 TLS Client Protocol with Authentication (FCS_TLSC_EXT.2) .......................... 21

2.2.11 TLS Server Protocol with Mutual Authentication (FCS_TLSS_EXT.2) ........... 29

2.3 Identification and Authentication (FIA) .................................................................................. 36

2.3.1 Password Management (FIA_PMG_EXT.1) ............................................................ 36

2.3.2 User Identification and Authentication (FIA_UIA_EXT.1) .................................. 37

2.3.3 Password-based Authentication Mechanism (FIA_UAU_EXT.2) ...................... 39

Page iii of iv

2.3.4 Protected Authentication Feedback (FIA_UAU.7) ................................................. 39

2.3.5 X.509 Certificate Validation (FIA_X509_EXT.1) .................................................. 40

2.3.6 X.509 Certificate Authentication (FIA_X509_EXT.2) .......................................... 43

2.3.7 X.509 Certificate Requests (FIA_X509_EXT.3) ..................................................... 44

2.3.8 Management of Security Functions Behavior

(FMT_MOF.1(1)/TrustedUpdate) ............................................................................... 45

2.3.9 Management of Security Functions Behavior (FMT_MOF.1(2)/Audit) ............ 46

2.3.10 Management of Security Functions Behavior (FMT_MOF.1(2)/AdminAct) ... 46

2.3.11 Management of TSF Data (FMT_MTD.1) ............................................................... 47

2.3.12 Management of Security Functions Behavior (FMT_MTD.1/AdminAct) ........ 48

2.3.13 Specification of Management Functions (FMT_SMF.1) ....................................... 49

2.3.14 Restrictions on Security Roles (FMT_SMR.2) ........................................................ 49

2.4 Protection of the TSF (FPT) ...................................................................................................... 50

2.4.1 Protection of Administrator Passwords (FPT_APW_EXT.1) ............................... 50

2.4.2 Protection of TSF Data (for reading of all symmetric keys)

(FPT_SKP_EXT.1) ........................................................................................................ 50

2.4.3 TSF Testing (FPT_TST_EXT.1) ................................................................................. 51

2.4.4 Trusted Update (FPT_TUD_EXT.1) .......................................................................... 53

2.4.5 Reliable Time Stamps (FPT_STM.1) ......................................................................... 56

2.5 TOE Access (FTA) ...................................................................................................................... 57

2.5.1 TSF-initiated Session Locking (FTA_SSL_EXT.1) ............................................... 57

2.5.2 TSF-initiated Termination (FTA_SSL.3) .................................................................. 58

2.5.3 User-initiated Termination (FTA_SSL.4) ................................................................. 58

2.5.4 Default TOE Access Banners (FTA_TAB.1) ........................................................... 59

2.6 Trusted Path/Channels (FTP) .................................................................................................... 59

2.6.1 Inter-TSF trusted channel (FTP_ITC.1) .................................................................... 59

2.6.2 Trusted Path (FTP_TRP.1) ........................................................................................... 61

3 Security Assurance Requirements ..................................................................................... 62

3.1 Class ADV: Development .......................................................................................................... 62

3.1.1 ADV_FSP.1 Basic Functional Specification ............................................................ 62

3.2 Class AGD: Guidance Documents ........................................................................................... 63

Page iv of iv

3.2.1 AGD_OPE.1 Operational User Guidance ................................................................. 63

3.2.2 AGD_PRE.1 Preparative Procedures ......................................................................... 64

3.3 ATE_IND.1 Independent Testing Conformance ................................................................... 66

3.3.1 ATE_IND.1 Assurance Activity ................................................................................. 66

3.4 Class AVA: Vulnerability Assessment .................................................................................... 67

3.4.1 AVA_VAN.1 Assurance Activity ............................................................................... 67

3.5 Class ALC: Life-Cycle Support ................................................................................................ 67

3.5.1 ALC_CMC.1 Labeling of the TOE Assurance Activity ........................................ 67

3.5.2 ALC_CMS.1 TOE CM Coverage Assurance Activity ........................................... 68

of 69

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, 2017.

of 69

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

of 69

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.2

2.1 Security Audit (FAU)

2.1.1 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 v1.0.

2.1.1.1 TSS Assurance Activities

None Defined.

2.1.1.2 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

of 69

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

of 69

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

2.1.1.3 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.

2.1.2 User Identity Association (FAU_GEN.2)


This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.



of 69



2.1.3 Protected Audit Trail Storage (FAU_STG.1)


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.


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 7.2.2 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 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.

of 69

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.

2.1.4 Protected Audit Event Storage (FAU_STG_EXT.1)

2.1.4.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.


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 6.3.1.1 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

of 69

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 2.3.1 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 7.2.1 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.

of 69


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 8.27.

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

2.1.5 Counting Lost Audit Data (FAU_STG_EXT.2)


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.

of 69


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 7.2.1 Configuring Local Audit Storage states the Black Lantern warns the Security



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 7.2.2 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.


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.1.3.

2.1.6 Display Warning for Local Storage Space (FAU_STG_EXT.3)


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.

of 69


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 7.2.1 Low Local Storage Space Warnings states the Black Lantern warns the Security



2%, and 1%. The description in the guidance documentation corresponds to the description in the TSS.


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)

2.2.1 Cryptographic Key Generation (FCS_CKM.1)


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 6.2.1 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).

of 69


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 6.2.1 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


Performed in accordance with NIAP Policy Letter #5

Section 1.3.1.2.2 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

FIPS 186-4:

Key Generation:

Provable Primes with Conditions:

Modulus lengths: 2048, 3072

Primality Tests: C.3

Prerequisites: SHS, DRBG

RSA #2456

SHS #3697

DRBG #1472

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;

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

ECDSA #1095

SHS #3697

DRBG #1472

of 69

2.2.2 Cryptographic Key Establishment (FCS_CKM.2)


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 6.2.1 Cryptographic Key Management identifies the following cryptographic key

establishment methods:

Elliptic curve-based key establishment schemes that meets the following: NIST Special

Publication 800-56A, “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.


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 6.3.3.1 Key Establishment provides the guidance to configure the TOE to use Elliptic

Curve-based key establishment schemes.


Performed in accordance with NIAP Policy Letter #5.


Cryptographic Algorithms”) identifies the CAVP certifications verifying ECDSA-based key

establishment, as follows.


Elliptic curve-based key

establishment schemes] that

meets the following: [NIST

Special Publication 800-56A,

“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

of 69

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 #2979

2.2.3 Cryptographic Key Destruction (FCS_CKM.4)


The evaluator shall check to ensure the TSS lists each type of plaintext key material and its origin and

storage location.

Modified by TD0130: NIT Technical Decision for Requirements for Destruction of

Cryptographic Keys

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 6.2.1 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

of 69

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 6.2.1 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 6.2.1 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.


None defined.


None defined.

2.2.4 Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1(1)


None defined.


None defined.

of 69




Cryptographic Algorithms”) identifies the CAVP certifications verifying AES Data

Encryption/Decryption, as follows.


AES-CBC (as defined in NIST

SP 800-38A)

AES-GCM (as defined in NIST

SP 800-38D)

AES-CBC:

Modes: Decrypt, Encrypt

Key Lengths: 128, 256 (bits)

AES-GCM:

Modes: Decrypt, Encrypt

IV Generation: external

Key Lengths: 128, 256 (bits)

AES #4508

2.2.5 Cryptographic Operation (Signature Generation and Verification (FCS_COP.1(2))


None defined.


None defined.




Cryptographic Algorithms”) identifies the CAVP certifications Signature Generation and Verification,

as follows.


RSA schemes using

cryptographic key sizes [of

2048-bit or greater] that meet the

186-4:

Signature Generation PKCS1.5:

AES #2456

SHS #3697

of 69

following: [FIPS PUB 186-4,

“Digital Signature Standard

(DSS)”, Section 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

DRBG #1472

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 14888-3, Section

6.4

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

ECDSA #1095

SHS #3697,

DRBG #1472

of 69

2.2.6 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3))


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 6.2.2 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 10118-3:2004.FIPS PUB

180-4 “Secure Hash Standard”. Hashing is used as part of RSA and ECDSA key generation and

verification.


The evaluator checks the AGD documents to determine that any configuration that is required to

configure the required hash sizes is present.

[AGD] Section 6.3.3.2 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.


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



Cryptographic Algorithms”) identifies the CAVP certifications verifying Cryptographic Hashing, as

follows.


SHS that meets: FIPS Pub 180-4

or ISO/IEC 10118-3:2004.

SHA-1

SHA-256

SHA-384

SHA-512

SHS #3697

of 69

2.2.7 Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4))


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 6.2.2 Cryptographic Operations, Table 7 specifies the key length, hash function used, block

size, and output MAC length used by the HMAC function.


None defined.




Cryptographic Algorithms”) identifies the CAVP certifications verifying Keyed Hash Algorithm, as

follows.


HMAC that meets FIPS Pub

198-1, "The Keyed-Hash

Message Authentication Code,

and FIPS Pub 180-4, “Secure

Hash Standard or ISO/IEC 9797-

2:2011, Section 7 “MAC

Algorithm 2”.

HMAC-SHA-1

HMAC-SHA-256

HMAC-SHA-384

HMAC-SHA-512

Prerequisite: SHS

HMAC #2979

SHS #3697

2.2.8 Random Bit Generation (FCS_RBG_EXT.1)

2.2.8.1 Assurance Activity

Documentation shall be produced—and the evaluator shall perform the activities—in accordance with

Appendix D of [NDcPP].

[ST] Section 6.2.3 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.

of 69


None defined.


None defined.




Cryptographic Algorithms”) identifies the CAVP certifications verifying Random Bit Generation, as

follows.


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 #4508

2.2.9 HTTPS Protocol (FCS_HTTPS_EXT.1)


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 6.2.4 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.


None defined.


The evaluator shall perform the following tests:

of 69

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.

2.2.10 TLS Client Protocol with Authentication (FCS_TLSC_EXT.2)

This requirement has been modified per TD0226: NIT Technical Decision for TLS Encryption

Algorithms.


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 6.2.5.1 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

of 69

The TSS includes the cipher suites included in the SFR component.

FCS_TLSC_EXT.2.2

The evaluator shall ensure that the TSS describes the client’s method of establishing all reference

identifiers from the administrator/application-configured reference identifier, including which types of

reference identifiers are supported (e.g Common Name, DNS Name, URI Name, Service Name, or other

application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported.

The evaluator shall ensure that this description identifies whether and the manner in which certificate

pinning is supported or used by the TOE.

TD0152: NIT Technical Decision for Reference identifiers for TLS in the NDcPP v1.0 and FW cPP

v1.0

In the TSS requirements in SD v1.0 sections 2.2.13.1 & 2.2.14.1 the text “The evaluator shall ensure that

the TSS describes … whether … wildcards are supported” is interpreted as referring to the statement in

Application Notes 75 & 79 that “[T]he client should avoid constructing reference identifiers using

wildcards”.

[ST] Section 6.2.5.1 TLS Client Protocol with Mutual Authentication identifies the host name as a

reference identifier, and is capable of handling wildcards. The TOE does not support IP addresses. The

reference identifier is set manually by the Security Administrator by setting a Network Configuration

parameter, HostName. The TOE supports certificate pinning by allowing the Security Administrator to

import Intermediate and Root Certificate Authority (CA) certificate, and associate them with a predefined

host.

FCS_TLSC_EXT.2.4

The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the

required behaviour is performed by default or may be configured.

[ST] Section 6.2.5.1 TLS Client Protocol with Mutual Authentication describes the TOE as supporting the

secp256r1, secp384r1, and secp521r1 elliptic curves extensions by default when a TOE certificate,

containing any of those curves, is imported into the TOE.

FCS_TLSC_EXT.2.5

The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of

client-side certificates for TLS mutual authentication.

[ST] Section 6.2.5.1 TLS Client Protocol with Mutual Authentication states that the TOE supports mutual

authentication using X.509v3 certificates.


FCS_TLSC_EXT.2.1

The evaluator shall also check the guidance documentation to ensure that it contains instructions on

configuring the TOE so that TLS conforms to the description in the TSS.

[AGD] Section 6.2 X.509 Certificates provides the guidance on X.509 Certificates, Key Generation, CSR

Generation, and Certificate Loading. Section 6.3.1 Client Mode Configuration provides the guidance to

of 69

configure the Transport Security Layer (TLS) protocol, version 1.2, with mutual authentication for the

audit server and authentication server. Section 6.3.2 Server Mode Configuration provides the guidance

to configure the TOE as a server using the TLS protocol. The guidance documentation t contains

instructions on configuring the TOE so that TLS conforms to the description in the TSS.

FCS_TLSC_EXT.2.2

The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier

to be used for the purposes of certificate validation in TLS.

[AGD] Section 6.3.3.3 Reference Identifier provides the instructions for setting the reference identifier to

be used for the purposes of certificate validation in TLS.

FCS_TLSC_EXT.2.4

If the TSS indicates that the Supported Elliptic Curves Extension must be configured to meet the

requirement, the evaluator shall verify that AGD guidance includes configuration of the Supported Elliptic

Curves Extension.

[AGD] Section 6.3.3.4 Elliptic Curve Extension states when Black Lantern client sends a client hello

message to a server to initiate a TLS handshake, the client hello message will contain the Elliptic Curve

Extension section that identifies the following supported Elliptic Curves:

secp256r1

secp384r1

secp521r1

Since client hello message contains all supported Elliptic Curves, no configuration is needed.

FCS_TLSC_EXT.2.5

The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions

for configuring the client-side certificates for TLS mutual authentication.

[AGD] Section 6.3.1 Client Mode Configuration includes instructions for configuring the client-side

certificates for TLS mutual authentication. The TOE acts as a client for trusted communication between

itself and a remote audit server as well as an authentication server.


FCS_TLSC_EXT.2.1

TD0152: NIT Technical Decision for Reference identifiers for TLS in the NDcPP v1.0 and FW cPP

v1.0

The tests in sections 2.2.13.3 & 2.2.14.3 examine the way the client responds when presented with server

certificates that contain wildcards, which refers to the other part of the statement in Application Notes 75

& 79 that “if the presented identifiers include wildcards, the client must follow the best practices

regarding matching; these best practices are captured in the assurance activity”. The difference is thus

between use of wildcards in a reference identifier list that the TOE constructs (which is discouraged, but

optional), and support for the use of wildcards in a certificate that is presented to the TOE (which is

required).

of 69

Regarding IP addresses as identifiers in certificates: Application Notes 75 & 79 already state that

“support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as

against best practices but may be implemented

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the

requirement. This connection may be established as part of the establishment of a higher-level protocol,

e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to

satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an

attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit

AES and not 256-bit AES).

The TOE established a connection to the server using

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. A Wireshark capture verified that the TLS

connection was successful. The test was successfully repeated using the

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ciphersuite.

Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate

that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a

connection is established. The evaluator will then verify that the client rejects an otherwise valid server

certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection

is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

The server certificate was modified such that it did not contain the Server Authentication purpose in the

extendedKeyUsage field. The evaluator ran a Wireshark capture and attempted to connect to the server.

The evaluator reviewed the packet capture and verified that the TLS connection was not successful.

Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the

server-selected ciphersuite (for example, send a ECDSA certificate while using the

TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.) The evaluator shall verify that the TOE disconnects

after receiving the server’s Certificate handshake message.

The evaluator used to NIAP test tool to select an RSA ciphersuite but send an ECDSA certificate. The

evaluator ran a wireshark capture and attempted to connect to the server. The evaluator reviewed the

packet capture and verified that the TLS connection was not successful.

Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite

and verify that the client denies the connection. Test 2 in FCS_TLSS_EXT.1.1 or FCS_TLSS_EXT.2.1 can

be used as a substitute for this test.

The server was configured to select the TLS_NULL_WITH_NULL_NULL ciphersuite. The evaluator

ran a Wireshark capture and attempted to connect to the server. The packet capture verified that the TLS

connection was dropped after receiving the invalid ciphersuite.

This Test was modified per TD0165: NIT Technical Decision for Sending the ServerKeyExchange

message when using RSA

Test 5: The evaluator perform the following modifications to the traffic:

of 69

a) Change the TLS version selected by the server in the Server Hello to a non-supported TLS version

(for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the

connection.

b) Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify

that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE

ciphersuite) or that the server denies the client’s Finished handshake message.

c) Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite

not presented in the Client Hello handshake message. The evaluator shall verify that the client

rejects the connection after receiving the Server Hello.

d) Modify the signature block in the Server’s Key Exchange handshake message, and verify that the

client rejects the connection after receiving the Server Key Exchange message.

Modify the signature block in the Server’s Key Exchange handshake message, and verify that

the client rejects the connection after receiving the Server Key Exchange message. This test does

not apply to cipher suites using RSA key exchange. If a TOE only supports RSA key exchange in

conjunction with TLS then this test shall be omitted.

e) Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal

alert upon receipt and does not send any application data.


As part of completing negotiation of the TLS tunnel, a Finished message is sent (after

ChangeCipherSpec) which contains a hash of the previous messages exchanged. The

tunnel should be set up only if this hash is correctly verified. By sending a garbled message

(before Finished message is sent) it can be verified that the TLS implementation waits for

Finished message and verifies the hash before sending data. So for the purpose of this test

the garbled messaged shall be sent before the Finished message is sent.

f) Send a garbled message from the Server after the Server has issued the ChangeCipherSpec

message and verify that the client denies the connection.

Test 5a- The evaluator used the NIAP provided test tool to change the TLS version selected by the server

in the Server hello to a non-supported TLS version of 0x0304 (unknown). The evaluator ran a wireshark

capture and attempted to connect to the server. The evaluator reviewed the packet capture and verified

that the TLS connection was dropped after receiving the invalid unknown version attempt.

Test 5b-The evaluator used the NIAP provided test tool to configure the server to modify the last byte of

the server nonce in the Server Hello. The evaluator ran a Wireshark capture and attempted to connect to

the server. The evaluator reviewed the packet capture and verified that the TLS connection was terminated

by the server denying the client’s Finished handshake.

Test 5c - The evaluator used the NIAP provided test tool to modify the server’s selected ciphersuite in the

Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message.

The evaluator ran a wireshark capture and attempted to connect to the server. Review of the packet capture

verified that the TLS connection was denied after receiving the invalid ciphersuite.

of 69

Test 5d - The evaluator used a vendor provided debugger to set a break point in the TLS code when the

server sends its key exchange method. The evaluator ran Wireshark and attempted to connect to the

server with an ECDSA ciphersuite. The break point was hit in the code after the server sent the ECDSA

key exchange method. The evaluator modified the signature block of the key exchange before it was

processed by the TOE. The last byte of the signature block was modified from 43 to 40. The evaluator

ran the rest of the code, thus completing the handshake attempt. The Wireshark capture verified that the

connection was terminated by the TOE after receiving the server’s key exchange method. A log message

from the TOE is included below as additional evidence.

Test 5e- The evaluator used the NIAP provided test tool to configure the server to modify the 6th byte in

the Server Finished handshake message. The evaluator ran a Wireshark capture and attempted to connect

to the server through the TOE. The evaluator reviewed the packet capture and verified that an alert was

sent and the TLS connection attempt ended after the device received the modified Server Finished

handshake message.

Test 5f- The evaluator used the NIAP provided test tool to configure the server to send a garbled message

from the Server after the Server issued the ChangeCipherSpec message. The evaluator ran a wireshark

capture and attempted to connect to the server. The evaluator reviewed the packet capture and verified

that an alert was sent and the TLS connection failed after receiving the garbled message.

FCS_TLSC_EXT.2.2

The evaluator shall configure the reference identifier according to the AGD guidance and perform the

following tests during a TLS connection:

Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the

Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The

evaluator shall verify that the connection fails.

The evaluator configured the server to contain a server certificate that does not contain an identifier in

either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier.

The server’s identifier is configured to be test.gtlocal.net. The evaluator ran a wireshark capture and

attempted to connect to the server. The evaluator examined the packet capture and verified that the TLS

connection failed and no data had been sent by the TOE.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference

identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the

reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this

test for each supported SAN type.

The evaluator configured the server to use a cert that contains a CN that matches the reference identifier

and a SAN that does not match. A Wireshark capture was started and an attempt to establish a TLS

connection to a server was made. The TLS connection failed after the TOE received the server’s

certificate.

Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference

identifier and does not contains the SAN extension. The evaluator shall verify that the connection

succeeds.

The evaluator configured the server to use a server certificate that contains a CN that matches the reference

identifier and does not contain the SAN identifier. The server’s identifier is configured for test.gtlocal.net.

A Wireshark capture was started and an attempt to establish a TLS connection to a server was made.

of 69

Review the packet capture verified that the TLS connection was successful and application data was sent

by the TOE.

Test 4: The evaluator shall present a server certificate that contains a CN that does not match the

reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that

the connection succeeds.

The evaluator configured the server to use the server certificate that contains a CN that does not match the

reference identifier but does contain an identifier in the SAN that matches. The server’s identifier is

configured for test.gtlocal.net. A Wireshark capture was started and an attempt to establish a TLS

connection to a server was made. Review the packet capture verified that the TLS connection was

successful and application data was sent by the TOE.

Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference

identifier:

1) The evaluator shall present a server certificate containing a wildcard that is not in the left-most

label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails.

2) The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g.

*.example.com). The evaluator shall configure the reference identifier with a single left-most label

(e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the

reference identifier without a left-most label as in the certificate (e.g. example.com) and verify

that the connection fails. The evaluator shall configure the reference identifier with two left-most

labels (e.g. bar.foo.example.come) and verify that the connection fails.

Test 5.1 - The evaluator modified the server certificate to contain a wildcard that is not in the left-most

label of the presented identifier. In this test the configured host name in the cert is test.*.net while the

server’s identifier is test.gtlocal.net. A Wireshark capture was started and an attempt to establish a TLS

connection to a server was made. Review the packet capture verified that the TLS connection was

unsuccessful and the TLS connection failed.

Test 5.2 - The evaluator configured the server to use a server certificate containing a wildcard in the left-

most label. The dnsName in the cert was configured for *.gtlocal.net. The evaluator ran a wireshark

capture and attempted to connect to the server with a configured reference identifier with a single left-

most label. Review the packet capture verified that the TLS connection was successful.

Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall

configure the DNS name and the service identifier. The evaluator shall present a server certificate

containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN

and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service

identifier (but correct DNS name) and verify that the connection fails.

URI or Service name are not supported as reference identifiers and therefore this test is not applicable.

Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does

not match the pinned certificate and verify that the connection fails.

The TOE supports pinning of CA certificates, meaning a specific CA certificate is defined for a connection

to a specific host. The testing of attempting to authenticate with a cert signed by a different CA is

demonstrated in FCS_TLSC_EXT.2.3.

of 69

FCS_TLSC_EXT.2.3

Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results

in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or

certificates needed to validate the certificate to be used in the function, and demonstrate that the function

succeeds. . If the certificate is validated and a trusted channel is established, the test passes. The evaluator

then shall delete one of the certificates, and show that the certificate is not validated and the trusted

channel is not established.

The evaluator sent a certificate from the TLS server that was issued by a CA not installed on the TOE.

The evaluator viewed an unsuccessful connection. The evaluator loaded the CA certificate needed to

validate the server 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.

FCS_TLSC_EXT.2.4

Test 1: The evaluator shall configure the server to perform an ECDHE key exchange in the TLS

connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects

after receiving the server’s Key Exchange handshake message.

The evaluator configured the server to attempt to perform an ECDHE key exchange in the TLS connection

using a non-supported curve size of P-192. The evaluator ran a Wireshark capture and attempted to

connect to the server. Review of the packet capture verified that no connection could be attempted by

the server because the TOE did not support the P-192 curve.

FCS_TLSC_EXT.2.5

Test 1: The evaluator shall perform the following modification to the traffic:

a) Configure the server to require mutual authentication and then modify a byte in a CA field in the

Server’s Certificate Request handshake message. The modified CA field must not be the CA used

to sign the client’s certificate. The evaluator shall verify the connection fails.

The Network Interpretation Team (NIT) has issued a Technical Decision, RfI201705, that replaces

this test with the following two tests:

Test 1: The evaluator shall establish a connection to a peer server that is not configured for mutual

authentication (i.e. does not send Server’s Certificate Request (type 13) message). The evaluator observes

negotiation of a TLS channel and confirms that the TOE did not send Client’s Certificate message (type

11) during handshake.

Test 2: The evaluator shall establish a connection to a peer server with a shared trusted root that is

configured for mutual authentication (i.e. it sends Server’s Certificate Request (type 13) message). The

evaluator observes negotiation of a TLS channel and confirms that the TOE responds with a non-empty

Client’s Certificate message (type 11) and Certificate Verify (type 15) messages."

Test 1: The evaluator configured a TLS Server to establish a TLS connection without mutual

authentication required. The evaluator ran a Wireshark capture and attempted a TLS connection from the

TOE to the TLS server. The evaluator verified a successful TLS connection and that the TOE did not send

a client certificate.

Test 2: The evaluator configured a TLS Server to establish a TLS connection with mutual authentication

required. The evaluator ran a Wireshark capture and attempted a TLS connection from the TOE to the

of 69

TLS server. The evaluator verified a successful TLS connection and that the TOE did send a client

certificate.

2.2.11 TLS Server Protocol with Mutual Authentication (FCS_TLSS_EXT.2)

This requirement has been modified per TD0226: NIT Technical Decision for TLS Encryption

Algorithms.


FCS_TLSS_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 are identical to those listed for this component.

[ST] Section 6.2.5.2 TLS Server Protocol with Mutual Authentication identifies the following ciphersuites:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The ciphersuites listed in the TSS are identical to those identified in the SFR component.

FCS_TLSS_EXT.2.2

The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions.

[ST] Section 6.2.5.2 TLS Server Protocol with Mutual Authentication states that the TOE supports the

TLS 1.2 protocol, and denies older TLS and SSL versions.

FCS_TLSS_EXT.2.3

The evaluator shall verify that the TSS describes the key agreement parameters of the server key exchange

message.

[ST] Section 6.2.5.2 TLS Server Protocol with Mutual Authentication states that the TOE supports elliptic

curve key establishment, as specified in FCS_TLSS_EXT.2.3. The key agreement parameters of the

server key exchange message specified in the SFR consist of the following key establishment parameters

generated by the TOE: NIST curves secp256r1, secp384r1, and secp521r1.

FCS_TLSS_EXT.2.4 and FCS_TLSS_EXT.2.5

The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of

client-side certificates for TLS mutual authentication.

[ST] Section 6.2.5.2 TLS Server Protocol with Mutual Authentication: The TOE uses the last certificate

imported into it, which specifies the type of key to be used. The TOE supports mutual authentication

using X.509v3 certificates.

FCS_TLSS_EXT.2.6

The evaluator shall verify that the TSS describes how the DN or SAN in the certificate is compared to the

expected identifier.

[ST] Section 6.2.5.2 TLS Server Protocol with Mutual Authentication: The expected identifier of the peer

is configured into the TOE as a remote host configuration parameter. During a TLS connection attempt,

of 69

the TOE performs a bit-wise comparison of the expected identifier with the Subject Alternative Name

(SAN) if it’s available else it’s compared to the Common Name (CN) in the peer’s certificate (which the

peers sends to the TOE). If the expected identifier does not match the SAN or CN, then the connection is

not established.


FCS_TLSS_EXT.2.1

The evaluator shall also check the guidance documentation to ensure that it contains instructions on

configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of

ciphersuites advertised by the TOE may have to be restricted to meet the requirements).

[AGD] Section 6.3.2 Server Mode Configuration and Section 6.3.3 Additional Related Information

contain instructions on configuring the TOE so that TLS conforms to the description in the TSS. The

ciphersuites required for the Elliptic Curve-based Key Establishment methods are described in the

guidance. The ciphersuites and the key establishment methods described in the guidance are in agreement

with the description in the TSS.

FCS_TLSS_EXT.2.2

The evaluator shall verify that any configuration necessary to meet the requirement must be contained in

the AGD guidance.


contain instructions and the configuration settings to configure the TOE for TLS communications.

The Black Lantern rejects client connection attempts that use SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.

FCS_TLSS_EXT.2.3

The evaluator shall verify that any configuration necessary to meet the requirement must be contained in

the AGD guidance.

[AGD] Section 6.2.1 Key Generation provides the guidance to generate the following key sizes:

RSA

o 2048

o 4096

ECDSA

o 256

o 384

o 521

The guidance instructions meet the requirements set by the security requirement.


The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions

for configuring the client-side certificates for TLS mutual authentication.

of 69

[AGD] Section 6.3.1 Client Mode Configuration includes instructions for configuring the client-side

certificates for TLS mutual authentication. The TOE acts as a client for trusted communication between

itself and a remote audit server as well as an authentication server.

FCS_TLSS_EXT.2.6

If the DN is not compared automatically to the Domain Name or IP address, username, or email address,

then the evaluator shall ensure that the AGD guidance includes configuration of the expected DN or the

directory server for the connection.

[AGD] Section 6.3.1.1 Trusted Communication Channel with an Audit Server states that the BL 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 BL 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 BL associates each remote machine with a hostname.


FCS_TLSS_EXT.2.1

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the

requirement. This connection may be established as part of the establishment of a higher-level protocol,

e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to

satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an

attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit

AES and not 256-bit AES).

The evaluator established a TLS connection to the server using the

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuites. A Wireshark network capture

verified the successful negotiation for each of the ciphersuites.

Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain

any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally,

the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL

ciphersuite and verify that the server denies the connection.

The evaluator modified the Client Hello to contain the TLS_NULL_WITH_NULL_NULL ciphersuite.

The evaluator started a Wireshark capture and attempted to connect to the server. Review of the packet

capture verified that the server denies the connection.

Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the

does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using

the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of

the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after the receiving the key

exchange message.

The evaluator used a vendor provided debugger to set a break point in the TLS code when the client sends

its key exchange method. The evaluator ran wireshark and attempted to connect to the TOE with an RSA

ciphersuite. The break point was hit in the code after the client sent the RSA key exchange method. The

of 69

evaluator modified the value of the key exchange message received so that the TOE processed it as an

ECDSA key exchange method. The first two words of the key exchange method were modified:

First 2 words of a RSA Key Exchange Message = 0x10000102 0x0100759d changed to first two words

of an ECDHE Key Exchange Message = 0x10000042 0x4104ff68.

The evaluator ran the rest of the code, thus completing the handshake attempt. The wireshark capture

verifies that the connection was terminated by the TOE after receiving the client key exchange method. A

TLS connection failure log message was also generated by the TOE.

Test 4: The evaluator shall perform the following modifications to the traffic:

Modififed per TD0151: NIT Technical Decision for FCS_TLSS_EXT Testing - Issue 1 in NDcPP

v1.0.

a) Modify at a byte in the client’s nonce in the Client Hello handshake message, and verify that the

server rejects the client’s Certificate Verify handshake message (if using mutual authentication)

or that the server denies the client’s Finished handshake message.

b) Modify the signature block in the Client’s Key Exchange handshake message, and verify that the

server rejects the client’s Certificate Verify handshake message (if using mutual authentication)

or that the server denies the client’s Finished handshake message.

c) Modify a byte in the Client Finished handshake message, and verify that the server rejects the

connection and does not send any application data.


As part of completing negotiation of the TLS tunnel, a Finished message is sent (after

ChangeCipherSpec) which contains a hash of the previous messages exchanged. The tunnel

should be set up only if this hash is correctly verified. By sending a garbled message (before

Finished message is sent) it can be verified that the TLS implementation waits for Finished

message and verifies the hash before sending data. So for the purpose of this test the garbled

messaged shall be sent before the Finished message is sent.

d) After generating a fatal alert by sending a Finished message from the client before the client sends

a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous

test, and verify that the server denies the connection.

e) Send a garbled message from the client after the client has issued the ChangeCipherSpec message

and verify that the Server denies the connection.

4c - The evaluator used a vendor provided debugger to set a break point in the TLS code when the client

sends its Client Finished message. The evaluator ran wireshark and attempted to connect to the TOE. The

break point was hit in the code after the client sent the Client Finished message. The evaluator modified a

byte of the hash in the client finished handshake message before the TOE processed it. The evaluator ran

the rest of the code, thus completing the handshake attempt. The Wireshark capture verified that the

connection was terminated by the TOE after receiving the client finished message. A log message was

generated by the TOE.

4d – The evaluator used the ssl_tls package of Scapy to develop a tool that attempts a TLS connection but

sends a client Finished message before sending a ChangeCipherSpec message. The evaluator ran

Wireshark and attempted a connection to the TOE using the developed tool. The client Finished message

of 69

was sent and the handshake failed. The evaluator used Scapy to send a new client hello using the session

identifier from the previous connection. The server responded with server hello with a new session

identifier, meaning the attempt to reopen the previous session failed.

4e – The evaluator used the ssl_tls package of Scapy to develop a tool that attempts to establish a TLS

connection with a server but sends a garbled message after issuing the ChangeCipherSpec message. The

garbled message was generated by creating an encrypted handshake message and filling it with key

exchange data instead of the client finished data. The evaluator ran a Wireshark capture and attempted to

connect to the TOE using the developed tool. The evaluator verified via the capture that the server

terminated the connection after receiving the garbled message.

This test was modified per TD0156: NIT Technical Decision for SSL/TLS Version Testing in the

NDcPP v1.0 and FW cPP v1.0.

FCS_TLSS_EXT.2.2

The evaluator shall send a Client Hello requesting a connection with version SSL 1.0 and verify that the

server denies the connection. The evaluator shall repeat this test with SSL 2.0, SSL 3.0, TLS 1.0, and any

selected TLS versions.

The evaluator shall send a Client Hello requesting a connection for all mandatory and selected protocol

versions in the SFR (e.g. by enumeration of protocol versions in a test client) and verify that the server

denies the connection for each attempt

The evaluator modified the Client Hello to connect to the server with version SSL 2.0. The evaluator ran

a Wireshark capture and attempted to connect to the server. Review of the packet capture verified that the

connection was not successful.

The test was repeated using protocol versions SSL 3.0, TLS 1.0 and TLS 1.1. The packet captures verified

that the connection was not successful for each protocol version.

This test was modified per TD0155: NIT Technical Decision for TLSS tests using ECDHE in the

NDcPP v1.0.

FCS_TLSS_EXT.2.3

The evaluator shall attempt a connection using an ECDHE ciphersuite and a configured curve and, using

a packet analyzer, verify that the key agreement parameters in the Key Exchange message are the ones

configured. (Determining that the size matches the expected size for the configured curve is sufficient.)

The evaluator shall repeat this test for each supported NIST Elliptic Curve and each supported Diffie-

Hellman key size.

The evaluator shall attempt establishing connection using each claimed key establishment protocol (RSA,

DH, ECDHE) with each claimed parameter (RSA key size, Diffie-Hellman parameters, supported curves)

as selected in FCS_TLSS_EXT.1.3 (or FCS_TLSS_EXT.2.3). For example, determining that the RSA key

size matches the claimed size is sufficient to satisfy this test. The evaluator shall ensure that each supported

parameter combination is tested.

Note that this testing can be accomplished in conjunction with the other testing activities

A Wireshark capture was started and an attempt to establish a TLS connection with the TOE using the

secp256r1 curve was made. The TLS connection was successful and the evaluator viewed that secp256r1

was the curve found in the Key Exchange message.

of 69

The evaluator successfully established a connection using the ECDHE key establishment protocol using

the following curves:

secp256r1

secp384r1

secp521r1


Test 1: The evaluator shall configure the server to send a certificate request to the client and shall attempt

a connection without sending a certificate from the client. The evaluator shall verify that the connection

is denied.

The server was configured to send a certificate request to the client. The evaluator ran a Wireshark capture

while the client attempted to connect to the server without sending a certificate. Review of the packet

capture verified that the server denied the connection.

Test 2: The evaluator shall configure the server to send a certificate request to the client without the

supported_signature_algorithm used by the client’s certificate. The evaluator shall attempt a connection

using the client certificate and verify that the connection is denied.

The ssl_tls package of SCAPY was used to develop a tool that attempts a TLS connection to a server and

sends an unsupported signature algorithm (in this case RSA-SHA1) after the server sends its certificate

request message. A Wireshark capture was started and the developed tool was executed. Review of the

packet capture verified that the TOE denied the connection after the client tried to use an unsupported

signature algorithm.

Test 3: The evaluator shall demonstrate that using a certificate without a valid certification path results

in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or

certificates needed to validate the certificate to be used in the function, and demonstrate that the function

succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.

A CA certificate needed to validate the client certificate to be used in the function was loaded. The

evaluator ran a Wireshark capture and attempted to connect to the TOE. Review of the packet capture

verified that the connection was not successful.

The certificate chain was invalidated by replacing the CA cert with a different CA (the TOE will not

attempt a connection without a CA loaded) and ran a Wireshark capture while attempting to connect to

the TOE. The packet capture verified that the TLS connection failed because the certificate is not

validated and the trusted channel is not established.

Test 4: The evaluator shall configure the client to send a certificate that does not chain to one of the

Certificate Authorities (either a Root or Intermediate CA) in the server’s Certificate Request message.

The evaluator shall verify that the attempted connection is denied.

The Network Interpretation Team (NIT) has issued a Technical Decision, RfI201715, that changes this

test as follows:

Test 4: If the TOE supports sending a non-empty Certificate Authorities list in its Certificate Request

message, the evaluator shall configure the client to send a certificate that does not chain to one of the

Certificate Authorities (either a Root or Intermediate CA) in the server’s Certificate Request message.

The evaluator shall verify that the attempted connection is denied. If the TOE doesn't support sending a

non-empty Certificate Authorities list in its Certificate Request message, this test shall be omitted.

of 69

FCS_TLSS_EXT.2.1 Test 1 demonstrated that the TOE does not support sending a non-empty Certificate

Authorities list in its Certificate Request message. Therefore this test is not applicable to the TOE.

Test 5: The evaluator shall configure the client to send a certificate with the Client Authentication purpose

in the extendedKeyUsage field and verify that the server accepts the attempted connection. The evaluator

shall repeat this test without the Client Authentication purpose and shall verify that the server denies the

connection. Ideally, the two certificates should be identical except for the Client Authentication purpose.

The client was configured to use a certificate that contained the Client Authentication purpose. A

Wireshark capture was started and an attempt to establish a TLS connection with the TOE was made.

Review of the packet capture verified that the connection was successful.

The client was configured to use a certificate that did not contain the Client Authentication purpose. A

Wireshark capture was started and an attempt to establish a TLS connection with the TOE was made.

Review of the packet capture verified that the connection was unsuccessful.

Test 6: The evaluator shall perform the following modifications to the traffic:

a) Configure the server to require mutual authentication and then modify a byte in the client’s

certificate. The evaluator shall verify that the server rejects the connection.

Modified per TD0151: NIT Technical Decision for FCS_TLSS_EXT Testing - Issue 1 in NDcPP

v1.0.

b) Configure the server to require mutual authentication and then modify a byte in the client’s Certificate

Verify handshake message. The evaluator shall verify that the server rejects the connection.

b) Configure the server to require mutual authentication and then modify a byte in the *signature block

of the* client’s Certificate Verify handshake message. The evaluator shall verify that the server

rejects the connection.

6a - A vendor provided debugger was used to set a breakpoint in the TOE’s TLS code after the client

sends its certificate. A Wireshark capture was started and an attempt to establish a TLS connection with

the TOE was made. The breakpoint was hit after the client sent its certificate. Using the debugger the

evaluator modified the first byte in the certificate before it was processed by the TOE. The rest of the

code was executed allowing the TLS connection attempt to complete. The TLS connection was rejected

by the TOE.

6b - A vendor provided debugger was used to set a breakpoint in the TOE’s TLS code after the client

sends its certificate verify message. A Wireshark capture was started and an attempt to establish a TLS

connection with the TOE was made. The breakpoint was hit after the client sent its certificate verify

message. Using the debugger the evaluator modified the first byte in the signature block of the certificate

verify message before it was processed by the TOE. The rest of the code was executed allowing the TLS

connection attempt to complete. The TLS connection was rejected by the TOE.

FCS_TLSS_EXT.2.6

The evaluator shall send a client certificate with an identifier that does not match an expected identifier

and verify that the server denies the connection.

A CA certificate needed to validate the client certificate for a specific DNS hostname was loaded. In this

case the DNS hostname of the client is test.gtlocal.net. A Wireshark capture was started and an attempt

to establish a TLS connection with the TOE was made. The client certificate had a CN of

of 69

wrong.wrong.wrong and no SAN. The TOE rejected the connection after receiving a cert that did not

contain the DNS name of test.gtlocal.net.

2.3 Identification and Authentication (FIA)

2.3.1 Password Management (FIA_PMG_EXT.1)


None defined.


The evaluator shall examine the guidance documentation to determine that it provides guidance to

security administrators on the composition of strong passwords, and that it provides instructions on

setting the minimum password length.

[AGD] Section 8.1.2 Password Guidance provides the guidance to security administrators on the

composition of strong passwords. [AGD] Section 8.1.1 Minimum Password Length provides the guidance

to set the minimum password length.


Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the

requirements, in some way. For each password, the evaluator shall verify that the TOE supports the

password. While the evaluator is not required (nor is it feasible) to test all possible compositions of

passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length

listed in the requirement are supported, and justify the subset of those characters chosen for testing.

The TOE was configured for the minimum password length was 8 characters.

An attempt to create a password that was less than the 8 character minimum password length was

unsuccessful

o Password = tEs1!

An attempt to create a password that met the 8 character minimum password length was

successful

o Password = Friends723#@!!

An attempt to create a password with invalid characters was unsuccessful.

o Password = PassworD$2\

An attempt to create a password that did not contain numbers or special was unsuccessful.

o Password = Password

An attempt to create a password with no uppercase characters was unsuccessful.

o Password = hello456&%(

The evaluator configured the TOE to support a minimum password length of 16 characters.

An attempt to create a password with less than the 16 minimum character requirement was

unsuccessful.

of 69

o Password = 432computerS&

An attempt to create passwords that met the 16 character minimum requirement was successfully

created.

o Password = %$Desktop1234567!

o Password = Abc093<>~)(^vfrA6

2.3.2 User Identification and Authentication (FIA_UIA_EXT.1)


The evaluator shall examine the TSS to determine that it describes the logon process for each logon

method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain

information pertaining to the credentials allowed/used, any protocol transactions that take place, and

what constitutes a “successful logon”.

Section 6.3.2 of [ST] Authentication Mechanism describes two logon methods supported by the TOE:

Local, exercised via the local console

Remote, exercised via the RESTful interface over a TLS channel.

For local access, the administrator uses the local serial console to provide logon credentials (User ID and

Password), which the TOE checks against its local user database. A successful logon will provide the

administrator with access to the TOE’s Command Line Interface. If the logon attempt fails (e.g., incorrect

password or unknown User ID), the TOE displays a “Login failed” message.

For Remote access, the TOE provides a RESTful API that allows for a remote entity to perform the

Identification and Authentication (I&A) of the Administrator user, and the TOE validates the response of

the entity. The RESTful API is established over HTTPS connection.

The TSS describes the credentials allowed/used and the protocol transactions.

A successful logon using the local method results in administrator access to the TOE Serial Console

Interface (SCI). A successful logon using the remote method results in the TOE extracting the

Administrator user privileges and processing the management functionality command.


The evaluator shall examine the guidance documentation to determine that any necessary preparatory

steps (e.g., establishing credential material such as preshared keys, tunnels, certificates, etc.) to logging

in are described. For each supported the login method, the evaluator shall ensure the guidance

documentation provides clear instructions for successfully logging on. If configuration is necessary to

ensure the services provided before login are limited, the evaluator shall determine that the guidance

documentation provides sufficient instruction on limiting the allowed services.

[AGD] Section 6 Initial Configuration – Local describes the necessary steps the Security Administrator

must perform to configure the local login and remote login methods.

[AGD] Section 6.1.1 Configuring Local Login states that Local login is performed by using the Serial

Console Interface (SCI) of the Black Lantern and a terminal emulator (e.g., Putty). Before the SCI can be

used the Security Administrator must configure the Black Lantern encrypted Initial Configuration File.

of 69

The credentials and the configuration file are delivered using different delivery channels agreed upon by

Guardtime and the customer at the time of contract signing.

The Black Lantern is delivered in Factory Reset state without any user accounts in its local users database.

The Initial Configuration File contains the Black Lantern’s users database, which in this case is only the

Initial Security Administrator account. Initial configuration files are unique to a specific Black Lantern.

They are encrypted with a key residing within its associated Black Lanterns, and must be hosted on an

HTTP server. During the configuration process, the Security Administrator will command the Black

Lantern to fetch this file from the HTTP server. At which point, the Black Lantern will configure itself

with the Initial Security Administrator account. The credentials for the Initial Security Administrator

account is also provided to the customer via a different channel.

Before using the Black Lantern, the customer must create a new Security Administrator account, and the

initial account must be deleted. The new Security Administrator account can be then used to create

additional user accounts for other admins. Each account created must be associated with a role supported

by the Black Lantern. Guidance is provided to configure the Initial Configuration File, use the setupbl

command to configure the Black Lantern for local login.

[AGD] Section 6.1.2 Configuring Remote Login provides the instructions for the Security Administrator

to configure the remote management and authentication servers to support remote login. [AGD] Section

6.3.2.1 Trusted Communication Path with Remote Management Tool provides instructions to configure

the Black Lantern RESTful interface using HTTPS.

[AGD] Section 6.3.1.2 Trusted Communication Channel with an Authentication Server provides the

instructions to setup the trusted channel with an authentication server using TLS.


The evaluator shall perform the following tests for each method by which administrators access the TOE

(local and remote), as well as for each type of credential supported by the login method:

Test 1: The evaluator shall use the guidance documentation to configure the appropriate credential

supported for the login method.

For that credential/login method, the evaluator shall show that providing correct I&A information results

in the ability to access the system, while providing incorrect information results in denial of access.

A new user and credentials were created. The newly created user successfully logged in while using the

proper credentials. An attempt to logon with incorrect credentials for the new user resulted in login access

being denied.

For remote administrative access, the evaluator used a RESTful API client to first request an authentication

token from the authentication server, and then modified the token to invalidate it. The evaluator then

attempted a RESTful API call to the TOE using the invalid token. The evaluator confirmed the request

was denied by the TOE. The TOE logs showed it had attempted to verify the token and that this attempt

had failed.



Test 2: The evaluator shall configure the services allowed (if any) according to the guidance

documentation, and then determine the services available to an external remote entity. The evaluator shall

determine that the list of services available is limited to those specified in the requirement.

of 69

Note: The TOE is managed remotely by a RESTful API. These API calls are the only service available to

remote entities.



Test 3: For local access, the evaluator shall determine what services are available to a local administrator

prior to logging in, and make sure this list is consistent with the requirement.

The evaluator verified that the displayed warning banner was the only service available prior to logging

in.

2.3.3 Password-based Authentication Mechanism (FIA_UAU_EXT.2)


Evaluation Activities for this requirement are covered under those for FIA_UIA_EXT.1. If other

authentication mechanisms are specified, the evaluator shall include those methods in the activities for

FIA_UIA_EXT.1.




FIA_UIA_EXT.1.




FIA_UIA_EXT.1.

2.3.4 Protected Authentication Feedback (FIA_UAU.7)


None defined.


None defined.


The evaluator shall perform the following test for each method of local login allowed:

Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall

verify that at most obscured feedback is provided while entering the authentication information.

of 69

The evaluator successfully logged into the TOE and verified that the password was not visible.

2.3.5 X.509 Certificate Validation (FIA_X509_EXT.1)


The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place.

The evaluator ensures the TSS also provides a description of the certificate path validation algorithm.

[ST] Section 6.3.3 X.509 Certificates states that the TOE uses X.509v3 certificates as specified in RFC

5280. The TSS summarizes the certificate path validation algorithm specified in RFC 5280, which can

be summarized as follows:

The public key algorithm and parameters are checked.

The current date/time is checked against the validity period.

Revocation status is checked.

Issuer name of X matches the subject name of X+1.

Name constraints are checked.

Policy OIDs are checked.

Policy constraints are checked; issuers are ensured to have CA signing bits.

Path length is checked.

Critical extensions are processed.

Modified per TD0117: NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP

The evaluator shall ensure the TSS describes when the check of validity of the certificates takes place. It

is expected that revocation checking is performed when a certificate is used in an authentication step and

when performing trusted updates (if selected). It is not sufficient to verify the status of a X.509 certificate

only when it's loaded onto the device.

It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the

option for using X.509 certificates for self-testing is selected).

[ST] Section 6.3.3 X.509 Certificates states that the authentication of a peer takes place during the TLS

channel establishment (dual authentication) and uses its trust store certificates to validate the peer

certificate. Revocation status is also checked during path validation


None defined.


The following Test has been modified per TD0187: NIT Technical Decision for Clarifying

FIA_X509_EXT.1

The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate

is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It

is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device.

of 69

It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the

option for using X.509 certificates for self-testing is selected).”

The evaluator shall perform the following tests for FIA_X509_EXT.1.1:

Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path

results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs

needed to validate the certificate to be used in the function, and demonstrate that the function succeeds.

The evaluator shall then delete one of the certificates, and show that the function fails.

a) Test 1a: The evaluator shall load a valid chain of certificates (terminating in a trusted CA certificate)

as needed to validate the certificate to be used in the function, and shall use this chain to demonstrate that

the function succeeds.

Test 1b: The evaluator shall then delete one of the certificates in the chain (i.e. the root CA certificate or

other intermediate certificate, but not the end-entity certificate), and show that the function fails.

This test was successfully demonstrated in FCS_TLSC_EXT.2.3 and FCS_TLSS_EXT.2.4 Test 3.

Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function

failing.

The server configured was to use an expired certificate. A Wireshark capture was started and attempts to

connect to the server resulted in a failed TLS connection. Review of the packet capture verified that the

TLS connection failed after receiving the failed certificate from the server.

Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-–conditional on

whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method.

The evaluator shall test revocation of the TOE certificate and revocation of the TOE intermediate CA

certificate i.e. the intermediate CA certificate should be revoked by the root CA. The evaluator shall ensure

that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the

test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the

certificate is no longer valid that the validation function fails.

A certificate containing the URI of the OCSP responder was generated. A Wireshark capture was started

and an attempt to establish a TLS connection to the TOE with a non-revoked certificate was successful.

The certificate from the CA was revoked and attempts to establish a TLS connection were rejected by the

TOE.

Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle

tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the

OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a

certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.

The OCSP server was configured to use a certificate that did not contain the OCSP signing certificate. A

Wireshark capture was started and attempts to establish a TLS connection with a server failed. The TLS

connection failed since the certificates revocation status could not be validated.

Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that

the certificate fails to validate. (The certificate will fail to parse correctly.)

of 69

A Wireshark capture was started and attempts to connect to the server using the NIAP provided TLS tool

were made. The tool modified the first byte of the server’s certificate. Review of the packet capture

verified that the TLS connection failed after the TOE received the modified certificate.

Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the

certificate fails to validate. (The signature on the certificate will not validate.)


were made. The tool modified the last byte of the server’s certificate. Review of the packet capture


Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the

certificate fails to validate. (The hash of the certificate will not validate.)


were made. The test tool modified the first byte of the certificate modulus. Review of the packet capture


The following has been modified per TD0228: NIT Technical Decision for CA certificates -

basicConstraints validation

The evaluator shall perform the following tests for FIA_X509_EXT.1.2. The tests described must be

performed in conjunction with the other certificate services assurance activities, including the functions

in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the

uses that require those rules.

The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two

intermediate CAs, and the self-signed Root CA.

The goal of the following tests it to verify that the TOE accepts only certificates that have been marked as

CA certificates by using basicConstraints with the CA flag set to True (and implicitly that the TOE

correctly parses the basicConstraints extension as part of X509v3 certificate chain validation).

For each of the following tests the evaluator shall create a chain of at least four certificates: a self-signed

root CA certificate, two intermediate CA certificates, and a leaf (node) certificate. The properties of the

certificates in the chain are adjusted as described in each individual test below (and this modification

shall be the only invalid aspect of the relevant certificate chain).

Test 1: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the

TOE’s certificate does not contain the basicConstraints extension. The validation of the certificate path

fails.

Test 1: The evaluator shall ensure that at least one of the CAs in the chain does not contain the

basicConstraints extension. The evaluator confirms that the TOE rejects such a certificate at one (or both)

of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when

attempting to add a CA certificate without the basicConstraints extension to the TOE’s trust store (i.e.

when attempting to install the CA certificate as one which will be retrieved from the TOE itself when

validating future certificate chains).

of 69

The evaluator issued the certificate by an intermediate CA that does not contain the basicConstraints

extension. The evaluator imported the certificate chain onto the TOE and verified that the import failed

because the cert path could not be validated.

Test 2: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the

TOE’s certificate has the cA flag in the basicConstraints extension set to FALSE. The validation of the

certificate path fails.

Test 2: The evaluator shall ensure that at least one of the CA certificates in the chain has a

basicConstraints extension in which the CA flag is set to FALSE. The evaluator confirms that the TOE

rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf

certificate belonging to this chain; (ii) when attempting to add a CA certificate with the CA flag set to

FALSE to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be

retrieved from the TOE itself when validating future certificate chains).

The evaluator issued a certificate using an intermediate CA that has the cA flag in the basicConstraints

extension set to FALSE. The evaluator imported the certificate chain onto the TOE and verified that it

failed because the cert chain could not be validated.

2.3.6 X.509 Certificate Authentication (FIA_X509_EXT.2)


The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to

use, and any necessary instructions in the administrative guidance for configuring the operating

environment so that the TOE can use the certificates.

Section 6.3.3 X.509 Certificates states that the TOE is only allowed to have one localhost certificate.

Therefore, the TOE does not require a selection process to determine which certificate should be used.

TOE’s localhost certificate is used for all PKI-based communication.

The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a

connection cannot be established during the validity check of a certificate used in establishing a trusted

channel.

The evaluator shall verify that any distinctions between trusted channels are described. If the requirement

that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance

documentation contains instructions on how this configuration action is performed.

Section 6.3.3 X.509 Certificates: states that when the TOE receives a certificate, during importing or PKI-

based communication, it checks the Authority Information Access field to be configured with the OCSP

flag as well as with a URI for the OCSP server. If the OCSP server does not respond or if the certificate

is invalid, the TOE does not establish the connection.


The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to

use, and any necessary instructions in the administrative guidance for configuring the operating

environment so that the TOE can use the certificates.

of 69

[AGD] Section 6.2 provides the guidance for configuring the operating environment so that the TOE can

use the certificates.


The evaluator shall perform the following test for each trusted channel:

The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking

to be performed in at least some part by communicating with a non-TOE IT entity. The evaluator shall

then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and

observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is

administrator-configurable, then the evaluator shall follow the guidance documentation to determine that

all supported administrator-configurable options behave in their documented manner.

A TLS peer is configured to use a certificate containing the OCSP URL for both client and server TLS

connections. The OCSP responder is disabled therefore denying the TOE the ability to validate the peer

certificate. Attempts were made to establish a TLS connection with the TOE as the client. The TLS

connection failed when the OCSP Responder could not be reached.

2.3.7 X.509 Certificate Requests (FIA_X509_EXT.3)


If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a

description of the device-specific fields used in certificate requests.

[ST] Section 6.3.3 X.509 Certificates: The TOE can generate a Certificate Request Message as specified

by RFC 2986 and is able to provide the following information in the request: public key, device specific

information, Common Name, Organization, Organizational Unit, and Country. The device specific

information, such as DNS name and IP address are stored as the Subject Alternative Name (SAN), as

configured by the Security Administrator.


The evaluator shall check to ensure that the guidance documentation contains instructions on requesting

certificates from a CA, including generation of a Certificate Request Message. If the ST author selects

"Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that

this guidance includes instructions for establishing these fields before creating the certificate request

message.

[AGD] Section 6.2.2 Certificate Signing Request (CSR) generation provides the guidance to generate a

Certificate Signing Request (CSR) using the gencsr command.

A CSR generated and stored by the system can be displayed on the terminal; the Security Administrator

must use non TOE resources to send the CSR to a trusted CA. The public key, common name, device

specific information, organization, organizational unit, and country fields are established when invoking

the gencsr command. Public key and common name are mandatory fields, while the rest are optional

requiring their respective flag. The Guidance Document provides an example screenshot for generating

a CSR.

of 69


The evaluator shall perform the following tests:

Test 1: The evaluator shall use the guidance documentation to cause the TOE to generate a certificate

request message. The evaluator shall capture the generated message and ensure that it conforms to the

format specified. The evaluator shall confirm that the certificate request provides the public key and other

required information, including any necessary user-input information.

The evaluator caused the TOE to generate a private key and a certificate request message. The generated

message was captured and verified that it conforms to the format specified.

Test 2: The evaluator shall demonstrate that validating a certificate response message without a valid

certification path results in the function failing. The evaluator shall then load a certificate or certificates

as trusted CAs needed to validate the certificate response message, and demonstrate that the function

succeeds. The evaluator shall then delete one of the certificates, and show that the function fails.

The evaluator imported a certificate response without its trusted CA’s and verified that the function fails.

The evaluator then loaded the certificate with its trusted CAs needed to validate the certificate and Security

Management (FMT)

2.3.8 Management of Security Functions Behavior (FMT_MOF.1(1)/TrustedUpdate)


None defined.


None defined.


The evaluator shall try to perform the update using a legitimate update image without prior authentication

as security administrator (either by authentication as a user with no administrator privileges or without

user authentication at all – depending on the configuration of the TOE). This test should fail.

The evaluator shall try to perform the update with prior authentication as security administrator using a

legitimate update image. This test should pass. This test case should be covered by the tests for

FPT_TUD_EXT.1 already.

The test verifies that only the security administrators can update the TOE. The evaluator configured a

user to not have the security role. The blshell command was executed to identify the BLSHELL

commands available to the user. The evaluator verified that the updatebl command was not available

for the user.

The successful updating of the TOE by a user with the security role was demonstrated in

FPT_TUD_EXT.1.

of 69

2.3.9 Management of Security Functions Behavior (FMT_MOF.1(2)/Audit)


None defined.


None defined.


The evaluator shall try to modify all parameters for configuration of the handling of audit data without

prior authentication as security administrator (either by authentication as a user with no administrator

privileges or without user authentication at all – depending on the configuration of the TOE). This test

should fail. The term ‘handling of audit data’ refers to the different options for selection and assignments

in SFRs FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2.

The evaluator shall try to modify all parameters for configuration of the handling of audit data with prior

authentication as security administrator. The effects of the modifications should be confirmed. The term

‘handling of audit data’ refers to the different options for selection and assignments in SFRs

FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2.

The evaluator does not necessarily have to test all possible values of all parameters for configuration of

the handling of audit data but at least one allowed value per configurable parameter.

The test verifies that only the security administrators can update the TOE. The evaluator configured a

user to not have the security role by using the delrole testuser security command. The

blshell command was executed to identify the BLSHELL commands available to the user. The

evaluator executed the setconfig command and verified that the user could not update the

configuration for the audit collection.

2.3.10 Management of Security Functions Behavior (FMT_MOF.1(2)/AdminAct)


None defined.


None defined.


The evaluator shall try to perform at least one of the related actions without

prior authentication as security administrator (either by authentication as a user with no administrator

privileges or without user authentication at all – depending on the configuration of the TOE). These

attempts should fail.

of 69

The evaluator shall try to perform at least one of the related actions with prior authentication as security

administrator. These attempts should succeed.

The TOE restricts the managing of cryptographic keys to users with the security role. The security role

was deleted from the testuser user by executing the delrole testuser security command. The

evaluator verified that the import and genkey commands were not available for the user.

The successful operation of managing the cryptographic keys by a user with the security role was

demonstrated in Test FIA_X509_EXT.1.1 Test 3.

2.3.11 Management of TSF Data (FMT_MTD.1)


The evaluator shall examine the TSS to determine that, for each administrative function identified in the

guidance documentation; those that are accessible through an interface prior to administrator log-in are

identified. For each of these functions, the evaluator shall also confirm that the TSS details how the ability

to manipulate the TSF data through these interfaces is disallowed for non-administrative users.

[ST] Section 6.4.2 Management of TSF Data states that no administrative interfaces are available prior to

successful authentication.


The evaluator shall review the guidance documentation to determine that each of the TSF-data-

manipulating functions implemented in response to the requirements of the cPP is identified, and that

configuration information is provided to ensure that only administrators have access to the functions.

[AGD] Section 6.1.1 Configuring Local Login and Section 6.1.2 Configuring Remote Login provides

the guidance to configure the TOE to permit an administrator to manage the TOE both locally and

remotely.

[AGD] Section 9.2 Serial Interface Command Reference identifies the banner command. This

command sets or displays the login banner that appears when a user logs on the system. Section 9.1 Serial

Interface Command Reference provides additional details on the banner command.

[AGD] Section 3.3.3.4 Serial Terminal Session Timeout states that the Black Lantern will automatically

log users off and end the session after a configurable amount of inactivity. By default, it is configured to

end the session after 10 minutes of inactivity. Section 8.6 Session Timeout provides the commands and

guidance to set the local session time out.

Note that remote management of the Black Lantern is done via the RESTful Interface. This interface does

not have a concept of interactive session since each request to the API is a self-contained, identified, and

authenticated request. This can be interpreted as the “remote interactive session” being terminated

immediately after the request is serviced, and is never open for any measurable period of inactivity.

[AGD] Section 3.4 Black Lantern Software Updates and Patches states that the software update process

can be scheduled or initiated. [AGD] Section 8.4 Firmware Updates identifies the getconfig info

command to view the current executing version and the most recently installed version of the Black

Lantern (BL) firmware.

of 69

The firmware update image is encrypted and signed by Guardtime. The BL uses pre-install keys to verify

signature authenticity and decrypt the update image. If the verification or the decryption process of the

update image fails, the target BL will reject the firmware update. The updatebl command is executed

to perform the update. The execution of the updatebl command downloads the update image, verifies

the digital signature, decrypts image, and installs the firmware in primary location. If the digital signature

verification fails, the BL aborts the firmware update process and outputs an error message to the serial

console.

[AGD] Section 7 Audit Functionality identifies the administrator guidance to configure the local and

remote audit storage capabilities. The setconfig command is used to enable local and remote audit

logging. Section 6.3.1.1 Trusted Communication Channel with an Audit Server provides the guidance to

configure the trusted channel with a with a remote audit server. Section 7.2.1 Low Local Storage

Space Warnings identifies the warnings indicating low local storage space conditions. Section 7.2.2

Clearing Local Log Data identifies the rm command to clear the local audit record logs. Section 7.4

Audit Events provides a list of the Black Lantern audit events.


None defined.

2.3.12 Management of Security Functions Behavior (FMT_MTD.1/AdminAct)


None defined.


None defined.


The evaluator shall try to perform at least one of the related actions without prior authentication as

security administrator (either by authentication as a user with no administrator privileges or without user

authentication at all – depending on the configuration of the TOE). These attempts should fail.

The evaluator shall try to perform at least one of the related actions with prior authentication as security

administrator. These attempts should succeed.

The evaluator configured a user to not have the security role. The evaluator viewed that the import and

genkey commands were not available for the user to import certificates or generate keys. The successful

managing of keys and certificates by a security administrator was demonstrated during X509 testing.

of 69

2.3.13 Specification of Management Functions (FMT_SMF.1)

The security management functions for FMT_SMF.1 are distributed throughout the cPP and are included

as part of the requirements in FTA_TAB.1, FTA_SSL.3, FTA_SSL.4, FMT_MOF.1(1)/TrustedUpdate,

FMT_MOF.1(2)/TrustedUpdate (if included in the ST), FIA_X509_EXT.2.2 & FPT_TUD_EXT.2.2 (if

included in the ST and if they include an administrator-configurable action), FMT_MOF.1(1)/Audit,

FMT_MOF.1(2)/Audit, FMT_MOF.1.1(1)/AdminAct, FMT_MOF.1.1(2)/AdminAct and

FMT_MOF.1/LocSpace (for all of these SFRs that are included in the ST), FMT_MTD, FPT_TST_EXT,

and any cryptographic management functions specified in the reference standards. Compliance to these

requirements satisfies compliance with FMT_SMF.1.

The security management functions for FMT_SMF.1 are distributed throughout the cPP and are included

as part of the requirements in FTA_TAB.1, FTA_SSL.3, FTA_SSL.4, FMT_MOF.1(1)/TrustedUpdate,

FMT_MOF.1(2)/TrustedUpdate (if included in the ST), FIA_X509_EXT.2.2 & FPT_TUD_EXT.2.2 (if

included in the ST and if they include an administrator-configurable action), FMT_MOF.1(1)/Audit,

FMT_MOF.1(2)/Audit, FMT_MOF.1.1(1)/AdminAct, FMT_MOF.1.1(2)/AdminAct and

FMT_MOF.1/LocSpace (for all of these SFRs that are included in the ST), FMT_MTD, FPT_TST_EXT,

and any cryptographic management functions specified in the reference standards. Compliance to these

requirements satisfies compliance with FMT_SMF.1.

2.3.14 Restrictions on Security Roles (FMT_SMR.2)


None defined.


The evaluator shall review the guidance documentation to ensure that it contains instructions for

administering the TOE both locally and remotely, including any configuration that needs to be performed

on the client for remote administration.

[AGD] Section 6.1.2 Configuring Remote Login, states that for the Black Lantern to support remote login,

the Security Administrator must configure the remote management and authentication servers, as

described in [AGD] Sections 6.3.2.1 Trusted Communication Path with Remote Management Client and

6.3.1.2 Trusted Communication Channel with an Authentication Server respectively. The Black Lantern

is designed to provide a RESTful Interface for the purposes of remote management. The nature of this

type of interface does not allow the remote administrator to initiate remote login sessions to the Black

Lantern. Instead, when the remote administrator needs to remotely manage the Black Lantern, the

administrator sends a RESTful request to the Black Lantern.

This request is accompanied with a security token. The Black Lantern extracts the security token and

forwards it to the Authentication Server for authentication. Once the security token is authenticated, the

Black Lantern processes the RESTful request, and terminates any communication with the administrator.

The authentication scheme used by the Black Lantern is similar to that of a Lightweight Directory Access

Protocol (LDAP) scheme.

of 69

[AGD] Section 6.1.1 Configuring Local Login provides the guidance to configure the TOE for

administering the TOE locally.


In the course of performing the testing activities for the evaluation, the evaluator shall use all supported

interfaces, although it is not necessary to repeat each test involving an administrative action with each

interface. The evaluator shall ensure, however, that each supported method of administering the TOE that

conforms to the requirements of this cPP be tested; for instance, if the TOE can be administered through

a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be

exercised during the evaluation team’s test activities.

The testing of all management functions was met by performing the testing for the claimed SFRs.

2.4 Protection of the TSF (FPT)

2.4.1 Protection of Administrator Passwords (FPT_APW_EXT.1)


The evaluator shall examine the TSS to determine that it details all authentication data that are subject to

this requirement, and the method used to obscure the plaintext password data when stored.

[ST] Section 6.5.2 Protection of Administrator Passwords states: “The TOE uses of the Password Based

Key Derivation Function 2 (PBKDF2), as outlined in RFC 2898 and NIST SP 800-132. The PBKDF2

makes uses HMAC SHA 256 cryptographic hash function and random salt (generated from the

CTR_DRBG) to transform the plaintext password into a pseudo-random value before the TOE stores it”.

The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through

an interface designed specifically for that purpose, as outlined in the application note.

[ST] Section 6.5.2 Protection of Administrator Passwords states no user or administrator is able to read

the plaintext password through “normal” interfaces of the TOE.


None defined.


None defined.

2.4.2 Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1)


The evaluator shall examine the TSS to determine that it details how any preshared keys, symmetric

keys, and private keys are stored and that they are unable to be viewed through an interface designed

of 69

specifically for that purpose, as outlined in the application note. If these values are not stored in

plaintext, the TSS shall describe how they are protected/obscured.

[ST] Section 6.5.1 Protection of Stored Keys states the TOE stores the keys encrypted and when the keys

are to be used by the TOE, it decrypts the keys into volatile memory and does not provide an interface to

view those keys. All pre-shared, symmetric, and private keys that are stored in the TOE are stored and

protected at rest using AES 256 encryption format. The root or top-level key-encrypting key is an AES

256 key, derived from a special hardware-based secret called the OTPMK. The OTPMK is implemented

in specially-designed circuity by the chip manufacturer. The TOE protects such keys from unauthorized

modification or substitution.


None defined.


None defined.

2.4.3 TSF Testing (FPT_TST_EXT.1)


The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF; this

description should include an outline of what the tests are actually doing (e.g., rather than saying

"memory is tested", a description similar to "memory is tested by writing a value to each memory

location and reading it back to ensure it is identical to what was written" shall be used).

[ST] Section 6.5.3 Self-Test; details the Power On Self Tests (POST) that are run by the TSF. Each

firmware image gets verified/authenticated prior to executing its code. If the images are not verified, the

TOE will not boot up. If all the POST tests passed, the overall status on the POST will indicate Ok.

Otherwise, any failed POST test will trigger the TOE to display Failure on its “Power On Self Test” status.

In addition, any errors encountered are printed out at bootup.

The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate

that the TSF is operating correctly.

[ST] Section 6.5.3 Self-Test; the tests are sufficient to demonstrate that the TSF is operating correctly.

The combination of verifications and tests performed during bootup, along with the approach taken,

enables the TOE to convey to the Administrator that the TOE is operating properly. Furthermore, in the

event of catastrophic failures, printing out error during bootup will provide the Administrator adequate

information to diagnose the issue.

of 69


The evaluator shall also ensure that the guidance documentation describes the possible errors that may

result from such tests, and actions the administrator should take in response; these possible errors shall

correspond to those described in the TSS.

[AGD] Section 8.3 Self Test identifies the Power On Self Tests. In addition to performing authentication

and decryption for the software files, the extended boot also performs a series of Power On Self Tests

(POST). The following are the list of POST tests being performed by the Black Lantern’s boot firmware:

RAM March Test

Error-correcting Code Memory Test

Special Purpose Register (SPR) Test

General Purpose Register Test

Condition Register Test

Branch Test

Integer Math Test

Integer Load and Store Test

Floating Point Unit Register Test

Floating Point Unit Load and Store Test

Floating Point Unit Math Test

Timebase and Decrementer Test

Data Cache Test

RNG Test

SHA Test

AES CBC Test

HMAC Test

AES GCM Test

Sign and Verification Test

Each test is described in detail outlining the functionality being checked. If all the above tests passed,

the overall status on the POST will indicate Ok. Otherwise, any failed POST test will trigger the Black

Lantern to display Failure on its “Power On Self Test” status. In addition, any errors encountered are

printed out at bootup.


Future versions of this cPP will mandate a clearly defined minimum set of self tests. But also for this

version of the cPP it is expected that at least the following tests are performed:

a) Verification of the integrity of the firmware and executable software of the TOE

b) Verification of the correct operation of the cryptographic functions necessary to fulfill any of

the SFRs.

Although formal compliance is not mandated, the self tests performed should aim for a level of

confidence comparable to:

a) FIPS 140-2, chap. 4.9.1, Software/firmware integrity test for the verification of the integrity

of the firmware and executable software.

of 69

b) FIPS 140-2, chap. 4.9.1, Cryptographic algorithm test for the verification of the correct

operation of cryptographic functions.

Alternatively, national requirements of any CCRA member state for the security evaluation of

cryptographic functions should be considered as appropriate.

The evaluator shall verify that the self tests described above are either carried out during initial start-

up and that the developer has justified any deviation from this (if applicable).

The self-tests were verified to be carried out during start up. The TOE reported the following:

Power On Self Test : OK

Boot Status : OK

2.4.4 Trusted Update (FPT_TUD_EXT.1)


This requirement was modified per TD0154: NIT Technical Decision for Versions of TOE Software

in the NDcPP v1.0 and FW cPP v1.0

The evaluator shall verify that the TSS describes all TSF software update mechanisms for updating the

system software. The evaluator shall verify that the description includes a digital signature verification

of the software before installation and that installation fails if the verification fails. Alternatively an

approach using a published hash can be used. In this case the TSS shall detail this mechanism instead

of the digital signature verification mechanism. The evaluator shall verify that the TSS describes the

method by which the digital signature or published hash is verified to include how the candidate updates

are obtained, the processing associated with verifying the digital signature or published hash of the

update, and the actions that take place for both successful and unsuccessful signature verification or

published hash verification.

If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe

how and when the inactive version becomes active. The evaluator shall verify this description

[ST] Section 6.5.4 Trusted Updates; The TOE does not provide automatic updates to the software version

running on the TOE. Only the Security Administrator is capable of querying the current executing and

most recently installed versions of the TOE software image; both should match since the TOE reboots

itself after it is done installing updated software.

When software needs to be updated, the Security Administrator commands the TOE to initiate the update

process. The update process starts with the TOE requesting confirmation from the Security Administrator

to proceed with the update process. Upon confirmation, the TOE automatically proceeds with the rest of

the update process without requiring input from the Security Administrator.

The TOE downloads a signed and an encrypted package (containing the software update) from a pre-set

up HTTP (or HTTPS) server. The TOE uses ECDSA-521 to perform digital signature verification and

AES 256 to decrypt the image. The keys required for those cryptographic operations are pre-installed in

the TOE during manufacturing of the TOE.

The TOE proceeds to install the software in the primary location, and then reboots itself. Coming up from

reboot, the TOE verifies the software installed in the primary location. If primary location software is

verifies properly, the TOE copies the primary location software into the secondary location, and reboots

of 69

again. If the primary location software verification fails, the TOE copies the secondary location software

into the primary location, and reboots itself.

If any failures occur, including digital signature verification or decryption, the TOE aborts the software

update process, and outputs error messages to the serial console and records relevant audit logs. In the

event of a fail software update attempt, the Security Administrator will use the information displayed in

the Serial Console and the logs to troubleshoot the incident, and retry again.

If the ST author indicates that a certificate-based mechanism is used for software update digital

signature verification, the evaluator shall verify that the TSS contains a description of how the

certificates are contained on the device. The evaluator also ensures that the TSS (or guidance

documentation) describes how the certificates are installed/updated/selected, if necessary.

[ST] Section 6.5.4 Trusted Updates; The TOE does not provide a certificate-based mechanism used for

software update digital signature verification.


The evaluator shall verify that the guidance documentation describes how the verification of the

authenticity of the update is performed (digital signature verification or verification of published hash).

The description shall include the procedures for successful and unsuccessful verification. The

description shall correspond to the description in the TSS.

[AGD] Section 8.4 Software Updates identifies the getconfig info command to view the current executing

version and the most recently installed version of the Black Lantern (BL) firmware.







console.

The description in the [AGD] corresponds to the description in the TSS.


The evaluator shall perform the Tests 1 and 2 for all methods supported (manual updates, automatic

checking for updates, automatic updates).

Test 1: The evaluator performs the version verification activity to determine the current version of the

product as well as the most recently installed version (should be the same version before updating). The

evaluator obtains a legitimate update using procedures described in the guidance documentation and

verifies that it is successfully installed on the TOE. For some TOEs loading the update onto the TOE

and activation of the update are separate steps (‘activation’ could be performed e.g. by a distinct

activation step or by rebooting the device). In that case the evaluator verifies after loading the update

onto the TOE but before activation of the update that the current version of the product did not change

but the most recently installed version has changed to the new product version. After the update, the

evaluator performs the version verification activity again to verify the version correctly corresponds to

of 69

that of the update and that current version of the product and most recently installed version match

again.

The evaluator queried the TOE and found that it was running the latest version of the product: version

1.4.0. The evaluator updated the TOE with the most recent version of the product provided by the vendor.

The evaluator queried the TOE and found that it was running the latest version of the product: version

1.4.0-UpgradeTest.

The evaluator shall perform the Tests 1 and 2 for all methods supported (manual updates, automatic

checking for updates, automatic updates).

Test 2: The evaluator performs the version verification activity to determine the current version of the

product as well as the most recently installed version (should be the same version before updating). The

evaluator obtains or produces illegitimate updates as defined below, and attempts to install them on the

TOE. The evaluator verifies that the TOE rejects all of the illegitimate updates. The evaluator performs

this test using all of the following forms of illegitimate updates:

1) A modified version (e.g. using a hex editor) of a legitimately signed update (if digital

signatures are used) or a version that does not match the published hash (if published

hashes are used)

2) An image that has not been signed (if digital signatures are used) or an image without

published hash (if published hashes are used)

3) An image signed with an invalid signature (e.g. by using a different key as expected for

creating the signature or by manual modification of a legitimate signature) (only if digital

signatures are used).

4) The handling of version information of the most recently installed version might differ

between different TOEs. Depending on the point in time when the attempted update is rejected,

the most recently installed version might or might not be updated. The evaluator shall verify that

the TOE handles the most recently installed version information for that case as described in

the guidance documentation. After the TOE has rejected the update the evaluator shall verify,

that both, current version and most recently installed version, reflect the same version

information as prior to the update attempt.

Test 2.1 - The evaluator queried the TOE and determined that it was running the latest version of the

product. The vendor provided an invalid update with a modified image and then signed the image with a

legitimate signature. The evaluator attempted to update the TOE to the modified image. The TOE initially

loaded the image because it had a legitimate signature but did not execute the modified code.

Test .2.2 - The evaluator queried the current version of the TOE. The evaluator attempted to load an

image was provided by the vendor that was not signed and verified that an error was output from the TOE.

The evaluator verified that the TOE rejected the update and did not modify the firmware it was currently

running.

Test 2.3 - The evaluator queried the current version of the TOE and then attempted to load an image with

an invalid signature that was provided by the vendor. The evaluator verified that the TOE did not allow

the image to be loaded and displayed an error message. The attempt to load a bad image did not modify

the currently running firmware.

Test 2.4 - The tester verified that after each attempted update was rejected, the most recent installed

version displayed the correct version

of 69

Version number after good signature update – The TOE displayed the correct software version

after a successful update.

Version number after invalid signature update – The TOE was not updated and displayed the same

software version number prior to the update attempt.

Version number after no signature update. The TOE was not updated and displayed the same

software version number prior to the update attempt.

2.4.5 Reliable Time Stamps (FPT_STM.1)


The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time.

The TSS provides a description of how the time is maintained and considered reliable in the context of

each of the time related functions.

[ST] Section 6.5.5 Reliable Time Stamps; the TOE includes a real-time clock (RTC) within the TOE

hardware. The TOE uses the RTC to provide accurate date and time for the generated audit records and

track inactivity of administrative local sessions.

The time is maintained and considered reliable in the context of each of the time related functions since

the TOE supports synchronization with a primary and a secondary NTP server. The Security

Administrator can configure the NTP synchronization. The TOE does not provide the Security

Administrator a capability to manually set the date and time of the TOE.


The evaluator examines the guidance documentation to ensure it instructs the administrator how to set

the time. If the TOE supports the use of an NTP server, the guidance documentation instructs how a

communication path is established between the TOE and the NTP server, and any configuration of the

NTP client on the TOE to support this communication.

[AGD] Section 8.5 NTP Settings identifies the guidance to specify a Primary and Secondary server. It is

recommended that both the Primary and the Secondary NTP time servers are configured with stratum 1

NTP servers, which directly link to a reliable source of UTC time.

All of the Time Service's configuration items can be configured using the setconfig command on the

SCI. Note that only users with Network Administrator role for the BL are able to configure the Time

Service's parameter settings; Security Administrator roles can view them. Additional information on the

setconfig command are described in [AGD] Section 9.2 Serial Interface Command

Reference.


Test 1: The evaluator uses the guidance documentation to set the time. The evaluator shall then use an

available interface to observe that the time was set correctly.

If the audit component of the TOE consists of several parts with independent time information, then the

evaluator shall verify that the time information between the different parts are either synchronized or

of 69

that it is possible for all audit information to relate the time information of the different part to one base

information unambiguously.

The TOE is configured to use an NTP server. See Test 2 below.

Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance

documentation to configure the NTP client on the TOE, and set up a communication path with the NTP

server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE

supports multiple protocols for establishing a connection with the NTP server, the evaluator shall

perform this test using each supported protocol claimed in the guidance documentation.

If the audit component of the TOE consists of several parts with independent time information, then the

evaluator shall verify that the time information between the different parts are either synchronized or

that it is possible for all audit information to relate the time information of the different part to one base

information unambiguously.

The evaluator configured the NTP client to an NTP server with a configured time that was off. The

evaluator queried the TOE for the time. The evaluator then set the NTP client to the correct NTP server

and verified that the time updated correctly.

2.5 TOE Access (FTA)

2.5.1 TSF-initiated Session Locking (FTA_SSL_EXT.1)


None defined.


None defined.


Test 1: The evaluator follows the guidance documentation to configure several different values for the

inactivity time period referenced in the component. For each period configured, the evaluator

establishes a local interactive session with the TOE. The evaluator then observes that the session is

either locked or terminated after the configured time period. If locking was selected from the component,

the evaluator then ensures that reauthentication is needed when trying to unlock the session.

The evaluator configured the TOE inactivity logout period to be one minute and verified that the session

ended after the time had been reached. The test was repeated with time intervals of two minutes and three

minutes. The TOE successfully terminated each time interval when the inactivity time period was reached.

of 69

2.5.2 TSF-initiated Termination (FTA_SSL.3)


None defined.


None defined.


Test 1: The evaluator follows the guidance documentation to configure several different values for the

inactivity time period referenced in the component. For each period configured, the evaluator

establishes a remote interactive session with the TOE. The evaluator then observes that the session is

terminated after the configured time period.

Note: This SFR is implicitlt satisfied, since the “remote interactive session” is terminated immediately

after the request is submitted to the interface and is never open for any measurable period of inactivity.

2.5.3 User-initiated Termination (FTA_SSL.4)


None defined.


None defined.


Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the

guidance documentation to exit or log off the session and observes that the session has been terminated.

The evaluator initiated a local session and verified that after issuing the ‘exit’ command, the TOE

successfully ended the session.

Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows

the guidance documentation to exit or log off the session and observes that the session has been

terminated.

Given the nature of the RESTful API that supports remote administration of the TOE, this SFR is

inherently satisfied, since the “Administrator’s own interactive session” is terminated immediately after a

request is submitted to the RESTful API.

of 69

2.5.4 Default TOE Access Banners (FTA_TAB.1)


The evaluator shall check the TSS to ensure that it details each method of access (local and remote)

available to the administrator (e.g., serial port, SSH, HTTPS).

[ST] Section 6.6.2 Access Banner; the login banner is displayed prior to an administrative session via the

local console. Remote management can also be performed using the RESTful API. Due to the nature

of the RESTful interface, the login banner is not displayed using this interface.

[ST] Section 6.7.2 Trusted Path; states that when an Administrator uses a remote console to remotely

manage the TOE by sending RESTful requests, the remote console must first establish a TLS channel with

the TOE.


None defined.


Test 1: The evaluator follows the guidance documentation to configure a notice and consent warning

message. The evaluator shall then, for each method of access specified in the TSS, establish a session

with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in

each instance.

The evaluator configured a banner to display a warning before establishing a local session and verified

that the banner is displayed before a session is established.

2.6 Trusted Path/Channels (FTP)

2.6.1 Inter-TSF trusted channel (FTP_ITC.1)


The evaluator shall examine the TSS to determine that, for all communications with authorized IT

entities identified in the requirement, each communications mechanism is identified in terms of the

allowed protocols for that IT entity.

[ST] Section 6.7.1 Trusted Channel; the TOE protects communication with the audit server and

authentication server IT entities via TLS with mutual authentication.

The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the

requirements in the ST.

The TOE protects communication with audit server and authentication server IT entities via TLS and

HTTPS, respectively. The protocols listed in the TSS are specified in the security requirement.

of 69


The evaluator shall confirm that the operational guidance contains instructions for establishing the

allowed protocols with each authorized IT entity, and that it contains recovery instructions should a

connection be unintentionally broken.





to configure the TOE as a server using the TLS protocol. The guidance documentation t contains





guidance.

[AGD] 6.3.1.1 Trusted Communication Channel with an Audit Server states that in the event of the

connection between the Black Lantern and the Audit Server is broken, the Black Lantern drops the TLS

connection. Once the drop connection is detected, the Black Lantern stops sending logs to the Audit

Server. To recover from this event, the Security Administrator will need to set up the Black Lantern to

re-establish logging again.


Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT

entity is tested during the course of the evaluation, setting up the connections as described in the

guidance documentation and ensuring that communication is successful.

Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall

follow the operational guidance to ensure that in fact the communication channel can be initiated from

the TOE.

Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the

channel data are not sent in plaintext.

Test 4: The evaluators shall, for each protocol associated with each authorized IT entity tested during

test 1, the connection is physically interrupted. The evaluator shall ensure that when physical

connectivity is restored, communications are appropriately protected.

The evaluator followed the steps in the guidance document to configure TLS communication from the

TOE to the syslog server and verified that TLS connection was successful. The evaluator physically

disrupted the connection between the TOE and the syslog server. After 10 seconds the evaluator physically

reconnected the syslog server and viewed that the communication was still encrypted.

The evaluator imported the CA certificate used by the authentication server and configured the location

of the authentication server on the TOE. The communication link between the TOE and the authentication

server was verified to be encrypted via TLS. The physical connection between the TOE and the

authentication server was disrupted. After 20 seconds the evaluator physically reconnected the

authentication server and viewed that the communication was still encrypted.

of 69

2.6.2 Trusted Path (FTP_TRP.1)


The evaluator shall examine the TSS to determine that the methods of remote TOE administration are

indicated, along with how those communications are protected.

[ST] Section 6.7.2 Trusted Path; states that when an Administrator uses a remote console to remotely

manage the TOE by sending RESTful requests, which uses the HTTPS protocol.

The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration

are consistent with those specified in the requirement, and are included in the requirements in the ST.

[ST] Section 6.7.2 Trusted Path; identifies HTTPS as the protocol to support remote TOE administration.

The TSS description is consistent with the security requirement.


The evaluator shall confirm that the operational guidance contains instructions for establishing the

remote administrative sessions for each supported method.


contain instructions on configuring the TOE so that TLS conforms to the description in the TSS. Remote

management capabilities are done through the BL's RESTful Interface over HTTPS. The ciphersuites

required for the Elliptic Curve-based Key Establishment methods are described in the guidance.


Test 1: The evaluators shall ensure that communications using each specified (in the guidance

documentation) remote administration method is tested during the course of the evaluation, setting up

the connections as described in the guidance documentation and ensuring that communication is

successful.

Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall

follow the guidance documentation to ensure that in fact the communication channel can be initiated

from the TOE.

Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the

channel data is not sent in plaintext.

Test 4: The evaluators shall ensure that, for each protocol associated with each authorized IT entity

tested during test 1, the connection is physically interrupted. The evaluator shall ensure that when

physical connectivity is restored, communications are appropriately protected.

The evaluator imported the CA certificate used by the Overwatch remote administration onto the TOE

and configured the TOE to listen for REST API calls. The communication link between the TOE and the

Overwatch remote administration was verified to be encrypted via TLS. The evaluator physically

disrupted the connection between the TOE and the remote administration. After 17 seconds, the evaluator

physically reconnected the Overwatch remote administration to the TOE and viewed that the

communication was still encrypted.

of 69

3 SECURITY ASSURANCE REQUIREMENTS

3.1 Class ADV: Development

3.1.1 ADV_FSP.1 Basic Functional Specification

The Evaluation Activities for this assurance component focus on understanding the interfaces presented

in the TOE Summary Specification (TSS) in response to the functional requirements, and on the interfaces

presented in the AGD documentation. Specific requirements on this documentation are identified (where

relevant) for each SFR in NDcPP section 2, and in Evaluation Activities for AGD, ATE and AVA SARs

in other parts of section 3 in the NDcPP Supporting Document.

3.1.1.1 FSP_FSP.1 Assurance Activity

The evaluator shall check the interface documentation to ensure it describes the purpose and method

of use for each TSFI that is identified as being security relevant.

In this context, TSFI are deemed security relevant if they are used by the administrator to configure the

TOE, or to perform other administrative functions (e.g., audit review or performing updates).

Additionally, those interfaces that are identified in the ST, or guidance documentation, as adhering to

the security policies (as presented in the SFRs), are also considered security relevant. The intent, is that

these interfaces will be adequately tested, and having an understanding of how these interfaces are used

in the TOE is necessary to ensure proper test coverage is applied.

The evaluator shall check the interface documentation to ensure it identifies and describes the

parameters for each TSFI that is identified as being security relevant.

The documents to be examined for this assurance component in an evaluation are therefore the Security

Target, AGD documentation, and any supplementary information required by the cPP for aspects such

as entropy analysis or cryptographic key management architecture: no additional “functional

specification” documentation is necessary to satisfy the Evaluation Activities. The interfaces that need

to be evaluated are also identified by reference to the assurance activities listed for each SFR, and are

expected to be identified in the context of the Security Target, AGD documentation, and any

supplementary information required by the cPP rather than as a separate list specifically for the

purposes of CC evaluation. The direct identification of documentation requirements and their

assessment as part of the Evaluation Activities for each SFR also means that the tracing required in

ADV_FSP.1.2D is treated as implicit, and no separate mapping information is required for this element.

However, if the evaluator is unable to perform some other required Evaluation Activity because there

is insufficient design and interface information, then the evaluator is entitled to conclude that an

adequate functional specification has not been provided, and hence that the verdict for the ADV_FSP.1

assurance component is a ‘fail’.

The evaluation activities for collaborative Protection Profile for Network Devices focus on understanding

the interfaces presented in the TOE Summary Specification (TSS) in response to the functional

requirements, and on the interfaces presented in the AGD documentation. The TSS and AGD

documentation identifies and describes the parameters for each TSFI that is security relevant. The

Evaluation Activities for each SFR tracing required in ADV_FSP.1.2D is treated as implicit and separate

mapping information is not required for this element. No additional documentation is required to satisfy

this assurance requirement.

of 69

3.2 Class AGD: Guidance Documents

It is not necessary for a TOE to provide separate documentation to meet the individual requirements of

AGD_OPE and AGD_PRE. Although the Evaluation Activities in this section are described under the

traditionally separate AGD families, the mapping between real TOE documents and AGD_OPE and

AGD_PRE requirements may be many-to-many, as long as all requirements are met in documentation

that is delivered to administrators and users (as appropriate) as part of the TOE.

3.2.1 AGD_OPE.1 Operational User Guidance

Specific requirements and checks on the user guidance documentation are identified (where relevant) in

the individual Evaluation Activities for each SFR, and for some other SARs (e.g. ALC_CMC.1).

3.2.1.1 AGD_OPE.1 Assurance Activity

The evaluator shall check the requirements below are met by the guidance documentation.

Guidance documentation shall be distributed to administrators and users (as appropriate) as part of

the TOE, so that there is a reasonable guarantee that administrators and users are aware of the

existence and role of the documentation in establishing and maintaining the evaluated configuration.

Guidance documentation must be provided for every Operational Environment that the product

supports as claimed in the Security Target and must adequately address all platforms claimed for the

TOE in the Security Target.

The contents of the guidance documentation will be verified by the Evaluation Activities defined below

and as appropriate for each individual SFR in section 2 above.

In addition to SFR-related Evaluation Activities, the following information is also required.

a) The guidance documentation shall contain instructions for configuring any cryptographic

engine associated with the evaluated configuration of the TOE. It shall provide a warning to the

administrator that use of other cryptographic engines was not evaluated nor tested during the

CC evaluation of the TOE.

b) The documentation must describe the process for verifying updates to the TOE by verifying a

digital signature. The evaluator shall verify that this process includes the following steps:

1) Instructions for obtaining the update itself. This should include instructions for

making the update accessible to the TOE (e.g., placement in a specific directory).

2) Instructions for initiating the update process, as well as discerning whether the

process was successful or unsuccessful. This includes generation of the hash/digital

signature.

c) The TOE will likely contain security functionality that does not fall in the scope of evaluation

under this cPP. The guidance documentation shall make it clear to an administrator which

security functionality is covered by the Evaluation Activities.

The guidance documentation contains instructions for configuring any cryptographic engine associated

with the evaluated configuration of the TOE.




of 69


to configure the TOE as a server using the TLS protocol. The guidance documentation contains





guidance. [AGD] Section 6.3.3.1.1 Elliptic Curve-based Key Establishment provides a warning that no

other cryptographic engines were evaluated nor tested during the Common Criteria evaluation of the TOE.

The [AGD] documentation describes the process for verifying updates to the TOE by verifying a digital

signature.

[AGD] Section 8.4 Firmware Updates states that to perform a firmware update, the Security Administrator

will command the BL to obtain the update image from a specific URL address. The customer is

responsible for setting an HTTP server to host the update image. Guardtime is responsible for generating

the update image and provide it to the customer.







console.

[AGD] Section 1.1 Target of Evaluation (TOE) identifies the security functionality that does not fall in

the scope of evaluation under the cPP. GAE (Gateway, Aggregator, Extender) are KSI (Keyless Signature

Infrastructure) related applications that are independent of what is required to comply with the

collaborative Protection Profile for Network Devices [NDcPPv1.0], version 1.0, date February 27, 2015.

The TOE’s software version under evaluation is 1.5.2. Note that the TOE’s security functionalities

evaluated are those specified within the TOE’s Security Target.

3.2.2 AGD_PRE.1 Preparative Procedures

3.2.2.1 AGD_PRE.1 Assurance Activity

The evaluator shall check the requirements below are met by the preparative procedures. The contents of

the preparative procedures will be verified by the Evaluation Activities defined below and as appropriate

for each individual SFR in the section above.

The evaluator shall check the requirements below are met by the preparative procedures.

The contents of the preparative procedures will be verified by the Evaluation Activities defined below


Preparative procedures shall be distributed to administrators and users (as appropriate) as part of the

TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence

and role of the documentation in establishing and maintaining the evaluated configuration.

of 69

The contents of the preparative procedures will be verified by the Evaluation Activities defined below


In addition to SFR-related Evaluation Activities, the following information is also required.

Preparative procedures must include a description of how the administrator verifies that the operational

environment can fulfil its role to support the security functionality (including the requirements of the

Security Objectives for the Operational Environment specified in the Security Target). The

documentation should be in an informal style and should be written with sufficient detail and

explanation that they can be understood and used by the target audience (which will typically include

IT staff who have general IT experience but not necessarily experience with the TOE product itself).

Preparative procedures must be provided for every Operational Environment that the product supports

as claimed in the Security Target and must adequately address all platforms claimed for the TOE in the

Security Target.

The preparative procedures must include

a) instructions to successfully install the TSF in each Operational Environment; and

b) instructions to manage the security of the TSF as a product and as a component of the larger

operational environment; and

c) instructions to provide a protected administrative capability.

The Preparative procedures include a description of how the administrator verifies that the operational

environment can fulfil its role to support the security functionality (including the requirements of the

Security Objectives for the Operational Environment specified in the Security Target).

[AGD] Section 1.3 Operational Environment identifies the security objectives for the operational

environment as the following:

OE.PHYSICAL Physical security, commensurate with the value of the

TOE and the data it contains, is provided by the

environment.

OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities

(e.g., compilers or user applications) available on the

TOE, other than those services necessary for the

operation, administration and support of the TOE.

OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic

that traverses it. It is assumed that protection of this

traffic will be covered by other security and assurance

measures in the operational environment.

OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all

guidance documentation in a trusted manner.

OE.UPDATES The TOE firmware and software is updated by an

administrator on a regular basis in response to the

release of product updates due to known

vulnerabilities.

of 69

OE.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to

access the TOE must be protected on any other

platform on which they reside.

[AGD] provides the instructions to install, configure, and administrator the TOE is a secure manner.

[AGD] Section 1.2 Target of Evaluation (TOE) identifies the TOE platform identified in the Security

Target and the guidance provides the instructions to successfully install the TOE.

3.3 ATE_IND.1 Independent Testing Conformance

3.3.1 ATE_IND.1 Assurance Activity

The evaluator shall examine the TOE to determine that the test configuration is consistent with the

configuration under evaluation as specified in the ST.

The evaluator shall examine the TOE to determine that it has been installed properly and is in a known

state. The evaluator shall prepare a test plan that covers all of the testing actions for ATE_IND.1 in

the CEM and in the SFR-related Evaluation Activities.

While it is not necessary to have one test case per test listed in an Evaluation Activity, the evaluator

must show in the test plan that each applicable testing requirement in the SFR-related Evaluation

Activities is covered.

The test plan identifies the platforms to be tested, and for any platforms not included in the test plan but

included in the ST, the test plan provides a justification for not testing the platforms. This justification

must address the differences between the tested platforms and the untested platforms, and make an

argument that the differences do not affect the testing to be performed. It is not sufficient to merely

assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST

are tested, then no rationale is necessary.

The test plan describes the composition and configuration of each platform to be tested, and any setup

actions that are necessary beyond what is contained in the AGD documentation. It should be noted that

the evaluator is expected to follow the AGD documentation for installation and setup of each platform

either as part of a test or as a standard pre-test condition. This may include special test drivers or tools.

For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool

will not adversely affect the performance of the functionality by the TOE and its platform. This also

includes the configuration of any cryptographic engine to be used (e.g. for cryptographic protocols

being evaluated).

The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve

those objectives, and the expected results.

The test report (which could just be an updated version of the test plan) details the activities that took

place when the test procedures were executed, and includes the actual results of the tests. This shall be

a cumulative account, so if there was a test run that resulted in a failure, so that a fix was then installed

and then a successful re-run of the test was carried out, then the report would show a “fail” result

followed by a “pass” result (and the supporting details), and not just the “pass” result2.

The evaluator created a Test Report to address all of the tests required by the NDcPP. The Test Report

identifies the test configuration, the expected test results, and the actual test results.

of 69

The TOE is a hardware appliance consisting of two models.BL300-B2

BL300-C2

The difference between the two models is that the C2 version includes an upgraded oscillator to improve

the accuracy of the system clock and real time clock. The security functionality claimed is considered to

be equivalent between the two models.

3.4 Class AVA: Vulnerability Assessment

3.4.1 AVA_VAN.1 Assurance Activity

The evaluator shall document their analysis and testing of potential vulnerabilities with respect to this

requirement. This report could be included as part of the test report for ATE_IND, or could be a

separate document.

The evaluator formulates hypotheses in accordance with process defined in Appendix A. The evaluator

documents the flaw hypotheses generated for the TOE in the report in accordance with the guidelines

in Appendix A.5. The evaluator shall then perform vulnerability analysis in accordance with Appendix

A.4. The results of the analysis shall be documented in the report according to Appendix A.5.

The evaluator documented their analysis and testing of potential vulnerabilities with respect to this

requirement. Public searches were performed against all keywords found within the Security Target and

AGD that may be applicable to specific TOE components. The evaluation team determined that no

residual vulnerabilities exist that are exploitable by attackers with Basic Attack Potential.

The keyword searches included the following terms:

Guardtime

Guard time

BlackLantern

Black Lantern

Green Hills

Keyless Signature Infrastructure

KSI

Router

Switch

TLS

TCP

3.5 Class ALC: Life-Cycle Support

3.5.1 ALC_CMC.1 Labeling of the TOE Assurance Activity

This component is targeted at identifying the TOE such that it can be distinguished from other products

or versions from the same vendor and can be easily specified when being procured by an end user. A

label could consist of a “hard label” (e.g., stamped into the metal, paper label) or a “soft label” (e.g.,

electronically presented when queried).

of 69

The evaluator performs the CEM work units associated with ALC_CMC.1.

The evaluator shall check that the TOE provided for evaluation is labelled with its reference.

The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This

could be achieved through labelled packaging or media, or by a label displayed by the operational

TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of

purchase or use).

The TOE may provide a method by which it can be easily identified. For example, a software TOE may

display its name and version number during the start up routine, or in response to a command line

entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE.

Alternatively, the unique reference provided for the TOE may be the combination of the unique

reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE).

The evaluator shall check that the TOE references used are consistent.

If the TOE is labelled more than once then the labels have to be consistent. For example, it should be

possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated

operational TOE. This ensures that consumers can be confident that they have purchased the evaluated

version of the TOE, that they have installed this version, and that they have the correct version of the

guidance to operate the TOE in accordance with its ST.

The evaluator also verifies that the TOE reference is consistent with the ST.

The evaluator verified that the Security Target, TOE Hardware Platforms with the firmware, and the

Guidance documentation were consistently identified. The TOE reference was verified during testing to

be consistent with the Security Target.

The initial round of testing was performed on the TOE software version 1.4.0. After the initial round of

testing occurred the TOE’s software version was upgraded to 1.5.2. The update to the TOE’s software

version was made for two reasons:

1) RSA ciphersuites were removed by the vendor after the potential Labgram #106/Valgram #126

was initially issued. This has no effect on the TLS implementation for the remaining ciphersuites.

2) An issue with SHA-512 existed that needed to be resolved for the purpose of Key Establishment

CAVP testing. This has no effect on testing as none of the implemented TLS ciphersuites use SHA-512.

TLS packet captures were collected after the update for the purpose of proving TLS is still implemented

correctly.

3.5.2 ALC_CMS.1 TOE CM Coverage Assurance Activity

The evaluator performs the CEM work units associated with ALC_CMS.1.

The evaluator shall check that the configuration list includes the following set of items:

a) the TOE itself;

b) the evaluation evidence required by the SARs in the ST.

The evaluator shall examine the configuration list to determine that it uniquely identifies each

configuration item.

of 69

The configuration list contains sufficient information to uniquely identify which version of each item

has been used (typically a version number). Use of this list will enable the evaluator to check that the

correct configuration items, and the correct version of each item, have been used during the evaluation.

The evaluator verified that the Security Target, TOE Hardware Platforms with the firmware, and the

Guidance documentation were consistently identified. The TOE reference was verified during testing to

be consistent with the Security Target. The correct version of each item was used during the evaluation.

Guardtime Black Lantern Common Criteria Assurance ... · Page i of iv The Developer of the TOE:...

Documents

Transcript of Guardtime Black Lantern Common Criteria Assurance ... · Page i of iv The Developer of the TOE:...