document version: 1.0 november 2017 - niap-ccevs.org · pdf file5.1 fdp_acc.1 subset access...

For

Xerox® AltaLink™ C8030/C8035/C8045/C8055/C8070

Document version: 1.0

November 2017

Document prepared by

Table of Contents 1 Introduction ................................................................................................................. 4

1.1 Overview .............................................................................................................. 4

2 CC used for this evaluation ......................................................................................... 5

3 Evaluation Documents ................................................................................................. 6

4 SFRs Assurance Activities for HCD_PP ..................................................................... 7

4.1 FAU_GEN.1 Audit data generation ..................................................................... 7

4.2 FAU_GEN.2 User identity association ................................................................ 8

4.3 FAU_STG.1 Protected audit trail storage ............................................................ 9

4.4 FAU_STG.4 Prevention of audit data loss ......................................................... 10

4.5 FAU_STG_EXT.1 Extended: External Audit Trail Storage .............................. 11

4.6 FCS_CKM.1(a) Cryptographic Key Generation (for asymmetric keys) ........... 13

4.7 FCS_CKM.1(b) Cryptographic key generation (Symmetric Keys) ................... 14

4.8 FCS_CKM_EXT.4.1 Extended: Cryptographic key destruction ....................... 15

4.9 FCS_CKM.4 .1 Cryptographic Key Material Destruction ................................. 17

4.10 FCS_COP.1(a) Cryptographic Operation (Symmetric encryption/decryption) . 22

4.11 FCS_COP.1(b) Crypt. Operation (for signature generation/verification) .......... 23

4.12 FCS_COP.1(d) Cryptographic operation (AES Data Encryption/Decryption) . 24

4.13 FCS_COP.1(g) Crypt. Operation (for keyed-hash message authentication) ..... 28

4.14 FCS_RBG_EXT.1 (a) Extended: Cryptographic Operation (Random Bit

Generation) .................................................................................................................... 29

4.15 FCS_RBG_EXT.1 (b) Extended: Cryptographic Operation (Random Bit

Generation) .................................................................................................................... 31

4.16 FCS_IPSEC_EXT.1 Extended: IPsec selected .................................................. 33

4.17 FCS_HTTPS_EXT.1 Extended: HTTPS selected ............................................. 42

4.18 FCS_TLS_EXT.1 Extended: TLS selected ........................................................ 43

4.19 FCS_SSH_EXT.1 Extended: SSH selected ....................................................... 46

4.20 FCS_KYC_EXT.1 Extended: Key Chaining ..................................................... 49

5.1 FDP_ACC.1 Subset access control .................................................................... 50

5.2 FDP_ACF.1 Security attribute based access control ......................................... 51

5.3 FDP_DSK_EXT.1 Extended: Protection of Data on Disk ................................. 53

5.4 FDP_FXS_EXT.1 Extended: Fax separation ..................................................... 56

5.5 FDP_RIP.1(a) Subset residual information protection ...................................... 58

5.6 FDP_RIP.1(b) Subset residual information protection ...................................... 59

5.7 FIA_AFL.1 Authentication failure handling ...................................................... 60

5.8 FIA_ATD.1 User attribute definition ................................................................. 62

5.9 FIA_PMG_EXT.1 Extended: Password Management....................................... 63

5.10 FIA_UAU.1 Timing of authentication ............................................................... 64

5.11 FIA_UAU.7 Protected authentication feedback................................................. 66

5.12 FIA_UID.1 Timing of identification .................................................................. 67

5.13 FIA_USB.1 User-subject binding ...................................................................... 68

5.14 FIA_PSK_EXT Extended: Pre-Shared Key Composition ................................. 69

5.15 FMT_MOF.1 Management of security functions behavior ............................... 71

5.16 FMT_MSA.1 Management of security attributes .............................................. 73

5.17 FMT_MSA.3 Static attribute initialization ........................................................ 74

5.18 FMT_MTD.1 Management of TSF data ............................................................ 75

5.19 FMT_SMF.1 Specification of Management Functions...................................... 77

5.20 FMT_SMR.1 Security roles ............................................................................... 83

5.21 FPT_KYP_EXT.1 Extended: Protection of Key and Key Material................... 84

5.22 FPT_SKP_EXT.1 Extended: Protection of TSF Data ....................................... 85

5.23 FPT_STM.1 Reliable time stamps ..................................................................... 86

5.24 FPT_TST_EXT.1 Extended: TSF testing .......................................................... 87

5.25 FPT_TUD_EXT.1 Extended: Trusted Update ................................................... 88

5.26 FTA_SSL.3 TSF-initiated termination ............................................................... 90

5.27 FTP_ITC.1 Inter-TSF trusted channel ............................................................... 91

5.28 FTP_TRP.1(a) Trusted path (for Administrators) .............................................. 93

5.29 FTP_TRP.1(b) Trusted path (for Non-administrators) ...................................... 94

6 SARs Assurance Activities for HCD_PP .................................................................. 95

6.1 ADV_FSP.1 ....................................................................................................... 95

6.2 AGD_OPE.1 ....................................................................................................... 98

6.3 AGD_PRE.1 ....................................................................................................... 99

6.4 ALC_CMC.1 .................................................................................................... 100

6.5 ALC_CMS.1 .................................................................................................... 101

6.6 ATE_IND.1 ...................................................................................................... 102

6.7 AVA_VAN.1.................................................................................................... 103

7 Test Configuration ................................................................................................... 104

1 Introduction

1.1 Overview

This Assurance Activity Report (AAR) documents the evaluation of Xerox developed by

Xerox against the Protection Profile for Hardcopy Devices, Version 1.0, 10 September

2015.

Xerox is the sponsor of this evaluation which is being conducted by DXC Technology

Security Testing and Certification Laboratory (STCL) under the United States National

Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation

Scheme (CCEVS).

2 CC used for this evaluation

The standards used in the conduct of this evaluation:

Common Criteria for Information Technology Security Evaluation Part 1:

Introduction and general model September 2012 Version 3.1 Revision 4


Security functional components September 2012 Version 3.1 Revision 4


Security assurance components September 2012 Version 3.1 Revision 4

Common Methodology for Information Technology Security Evaluation

methodology September 2012 Version 3.1 Revision 4

3 Evaluation Documents

[ST] Xerox Multi-Function Device Xerox® AltaLink™

C8030/C8035/C8045/C8055/ C8070 Security Target, Version 0.21

[SIG] Secure Installation and Operation of Your AltaLink™

B8045/B8055/B8065/B8075/B8090 Multifunction Printer AltaLink™

C8030/C8035/C8045/C8055/C8070 Multifunction Printer, Version 1.2

[SAG] Xerox® AltaLink Series® System Administrator Guide, Version 1.0

[UG] Xerox® AltaLink™ C80XX Multifunction Printer User Guide, 1.0

[PP] Protection Profile for Hardcopy Devices, Version 1.0

[TD074] TD0074: FCS_CKM.1(a) Requirement in HCD PP, Version 1.0

[TD0176] TD0176 – FDP_DSK_EXT.1.2 - SED Testing

[TD0157] TD0157 – FCS_IPSEC_EXT.1.1 – Testing for SPDs

[TD0219] TD0219 – NIAP Endorsement of Errata for HCD PP v1.0

[KMD] Xerox Key Management Description for Xerox Atlantis Multi-Function

Device, Version 1.1

[EAR] Xerox C8030/C8035/C8045/C8055/C8070 Entropy Assessment Report,

Version 0.5

4 SFRs Assurance Activities for HCD_PP

4.1 FAU_GEN.1 Audit data generation

TSS Assurance Activity

The evaluator shall check the TOE Summary Specification (TSS) to ensure that auditable

events and its recorded information are consistent with the definition of the SFR.

Section 6.1.2 [ST] states that the TOE generates events listed in Table 9 of the [ST] and

points to Appendix A of the [SIG] for a comprehensive list of audit events. A

correspondence mapping, Attachment 2 of the [SIG] shows how the events included in

Table 9 are the same events that are found in Table 1 of the [PP], which is consistent with

the definition of the SFR. In addition, each log entry contains a time stamp.

Operational Guidance Assurance Activity

The evaluator shall check the guidance documents to ensure that auditable events and

its recorded information are consistent with the definition of the SFRs.

The [SIG], Attachment 1, includes a table named ‘Selected Audit Log Entries’ that lists all

the required TOE auditable events. The [SIG] additionally includes Attachment 2, at the

end of the manual, to provide a correspondence mapping between the audit events in Table

9 of the Security Target and Attachment 1 of the [SIG] showing each of the audit events.

Testing Assurance Activity

The evaluator shall also perform the following tests:

The evaluator shall check to ensure that the audit record of each of the auditable

events described in Table 1 is appropriately generated.

The evaluator shall check a representative sample of methods for generating

auditable events, if there are multiple methods.

The evaluator shall check that FIA_UAU.1 events have been generated for each

mechanism, if there are several different I&A mechanisms.

The test report includes test cases that demonstrate generation of all the required audit

records. The audit records were generated as part of exercising related functionalities.

For example, records of use of the management functions were generated as part of

exercising the management functions, audit of use of the identification and authentication

functions were generated for user login and logout at the management interfaces. All

auditable events are demonstrated in the test cases. See the table provided in

FAU_GEN.1 of the test report.

4.2 FAU_GEN.2 User identity association


The Assurance Activities for FAU_GEN.1 address this SFR.

Section 6.1.2 [ST] states that the audit log tracks the user identification and authentication

for the events/actions to logged in users.

4.3 FAU_STG.1 Protected audit trail storage


The evaluator shall check to ensure that the TSS contains a description of the means of

preventing audit records from unauthorized access (modification, deletion).

Section 6.1.2 [ST] indicates that only the System Administrator can download the audit log

for review and management by logging onto the WebUI.

The TSS prevents unauthorized access to the audit log and interface to modify audit records

by restricting access to only an authorized System Administrator.


The evaluator shall check to ensure that the TSS and operational guidance contain

descriptions of the interfaces to access to audit records, and if the descriptions of the

means of preventing audit records from unauthorized access (modification, deletion) are

consistent.

The [SIG], No. 12 Audit log, describes the interfaces to access audit log as the WebUI; the

guidance specifies that only the system administrator can download the audit log for

review. The TOE provides no interfaces to modify the audit records.

In addition, it is warned that once downloaded the audit log should be protected and should

only be accessible by authorized individuals.

In the [SIG], page 2, it states that the System Administrator authentication is required to

access all security features, which is also consistent with the TSS.


The evaluator shall also perform the following Testing Assurance Activity

1. The evaluator shall test that an authorized user can access the audit records.

2. The evaluator shall test that a user without authorization for the audit data cannot

access the audit records.

The evaluator tested this capability by performing actions that caused the TSF to generate

audit records in the audit log, then attempted to login to the device to review the audit

records both as an authorized administrator with permission to review and audit records

and an as a non-administrator user, only the administrator could view the audit records.

The test report includes the test cases in FAU_STG.1, which test this capability.

4.4 FAU_STG.4 Prevention of audit data loss


The evaluator shall check to ensure that the TSS contains a description of the processing

performed when the capacity of audit records becomes full, which is consistent with the

definition of the SFR.

Section 6.1.2 [ST] indicates that the TOE can store a maximum of 15,000 audit records in

its audit trail, when the audit log reaches 13,500 entries (or 90% full) an email warning is

sent to a set of administrator-defined email addresses. If the audit log has not been cleared

after 15,000 entries, subsequent warnings will be emailed to the administrator.

Additionally, if the number of audit entries in the audit log reached the maximum, The TSF

will overwrite the oldest audit events first. This implementation is consistent with the



The evaluator shall check to ensure that the operational guidance contains a description

of the processing performed (such as informing the authorized users) when the capacity

of audit records becomes full.

The [SIG], Page 13 – Audit Log, states an e-mail warning is sent before the audit log

reaches its capacity about 90% full or approximately 13,500 audit entries.

In addition, it describes to set the e-mail address to notify when the audit log reaches 13,500

audit events or when the audit log reaches full capacity.

The [SAG], Section Configuring Alerts (pg. 232) describes how to set e-mail alerts to

notify System Administrator.



1. The evaluator generates auditable events after the capacity of audit records

becomes full by generating auditable events in accordance with the operational

guidance.

2. The evaluator shall check to ensure that the processing defined in the SFR is

appropriately performed to audit records.

The test report includes a test case in the FAU_STG.4 section that verifies the audit log

will send an e-mail warning to the administrator when the audit log reaches 90% (13500

entries) and after 15000 entries thereafter.

The test also verifies that the audit log was overwritten when it reached full capacity.

4.5 FAU_STG_EXT.1 Extended: External Audit Trail Storage


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. Testing of the trusted channel mechanism will be performed as specified in the

associated assurance activities for the particular trusted channel mechanism.

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.

Section 6.1.2 in the [ST] states the means in which the audit data is transferred; it is

transferred to a designated file server in the operational environment and that the audit logs

are sent via the SFTP protocol only.

Section 6.1.2 states the TOE stores a maximum of 15,000 entries in the local audit store.

When the audit log is full the TOE overwrites the oldest entries first. An email is sent to

warn the system administrator at 13,500 audit event entries and again when the maximum

number of audit log entries have been reached.

Section 6.1.2 states the administrator must be logged in to download the audit log and is

the only user with authorized access to the audit to protect the audit log from unauthorized

access.


The evaluator shall also examine the operational guidance to determine that it describes

the relationship between the local audit data and the audit data that are sent to the audit

log server. For example, when an audit event is generated, is it simultaneously sent to

the external server and the local store, or is the local store used as a buffer and

“cleared” periodically by sending the data to the audit server.

The [SAG] in Section 4 - Audit Log (page 107) indicates that the TOE can be configured

to schedule automatic daily transfer of audit log data to an external audit server for storage;

audit transfer can also be performed on-demand by the authorized administrator.

The TOE uses SFTP when transferring audit data to the external audit server and the

guidance includes instructions for enabling the protocol logs and for enabling the automatic

log transfer via SFTP.

In addition, the [SIG] in Section 12 ‘Audit Log’ includes a warning that the audit log server

used for external audit storage must support the SFTP protocol as the TOE is configured

to use SFTP for transferring audit data log data.


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 test report includes a test case in FAU_STG_EXT.1 where the evaluator tested this

capability by performing several management functions to generate audit records and

sending the audit records to the external audit server; the evaluation verified that the audit

data is obfuscated during the transfer.

4.6 FCS_CKM.1(a) Cryptographic Key Generation (for asymmetric keys)


The evaluator shall ensure that the TSS contains a description of how the TSF complies

with 800-56A and/or 800-56B, depending on the selections made. This description shall

indicate the sections in 800-56A and/or 800-56B that are implemented by the TSF, and

the evaluator shall ensure that key establishment is among those sections that the TSF

claims to implement.

Any TOE-specific extensions, processing that is not included in the documents, or

alternative implementations allowed by the documents that may impact the security

requirements the TOE is to enforce shall be described in the TSS.

The TSS may refer to the Key Management Description (KMD), described in Appendix

F, that may not be made available to the public.

The [ST], Table 15 states, RSA Key Generation is provided by Mocana (RSA CMVP Cert

#2859 and CAVP RSA Cert #2296) and is compliant to FIPS 186-4. For the TOE-specific

extensions in Section 6.1.6., the [ST] author refers to the [KMD] document.

The [KMD] document states in section 1.4 that SP800-56A that are implemented by

Mocana for RSA and describes the key creation,


N/A

The [PP] does not define Operational Guidance Assurance Activity for this SFR.


The evaluator shall use the key pair generation portions of "The FIPS 186-4 Digital

Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-4 Elliptic Curve

Digital Signature Algorithm Validation System (ECDSA2VS)", and “The 186-4 RSA

Validation System (RSA2VS)” as a guide in testing the requirement above, depending

on the selection performed by the ST author. This will require that the evaluator have a

trusted reference implementation of the algorithms that can produce test vectors that are

verifiable during the test.

No actual testing was required, covered under Mocana CMVP certificate number #2859

and CAVP RSA Cert #2296. Mocana was tested with Wind River Linux 6.0 running on

Intel Atom E3800 (single-user mode), which is consistent with the ST which states the

TOE runs on Wind River 6 on Linux 3.10 kernel using an Atom(TM) CPU E3845

processor.

4.7 FCS_CKM.1(b) Cryptographic key generation (Symmetric Keys)


The evaluator shall review the TSS to determine that it describes how the functionality

described by FCS_RBG_EXT.1 is invoked.

The [ST], Section 6.1.6., references the [KMD] and Table 15 for a description of how the

functionality described by FCS_RBG_EXT.1 is invoked. The [KMD] document references

how the underlying Linux operating environment is invoked for entropy.


N/A

The [PP] does not define Operational Guidance Assurance Activity for this SFR.

KMD Assurance Activity

If the TOE is relying on random number generation from a third-party source, the KMD

needs to describe the function call and parameters used when calling the third-party

DRBG function. Also, the KMD needs to include a short description of the vendor's

assumption for the amount of entropy seeding the third-party DRBG. The evaluator uses

the description of the RBG functionality in FCS_RBG_EXT or the KMD to determine

that the key size being requested is identical to the key size and mode to be used for the

encryption/decryption of the user data (FCS_COP.1(d)).

The KMD is described in Appendix F.

The [KMD] Section 1.3 document references how the underlying Linux operating

environment is invoked for entropy for both the OpenSSL and Mocana cryptographic

libraries.

It is states that the TOE relies on the following third parties for random number generation;

Linux 3.10 Kernel via various Linux random API functions, OpenSSL Library and

Mocana’s NanoSEC Library and Kernel Modules.

The section notes that a minimum 256 bits are pulled from the entropy sources. by invoking

the OpenSSL’s RAND_bytes() function, which is FIPS-compliant for entropy.


N/A

No actual testing required, covered under Mocana CMVP certificate number #2859 and

CAVP DRBG Cert #1336 and OpenSSL CMVP certificate number #2398 and CAVP

DRBG certificate #845. Mocana was tested with Wind River Linux 6.0 running on Intel

Atom E3800 (single-user mode) and OpenSSL was tested on Linux 3.10 on Intel Atom

E3845 (x86), which are consistent with the ST which states the TOE runs on Wind River

6 on Linux 3.10 kernel using an Atom(TM) CPU E3845 processor.

4.8 FCS_CKM_EXT.4.1 Extended: Cryptographic key destruction

TSS Assurance activity

The evaluator shall verify the TSS provides a high- level description of what it means for

keys and key material to be no longer needed and when then should be expected to be

destroyed.

Section 6.1.6 in the [ST] states keys and keying material when no longer used or replaced

are securely deleted. Securely deleted means that the material is overwritten three times

with a static pattern and finally deleted.


The evaluator shall verify the Key Management Description (KMD) includes a

description of the areas where keys and key material reside and when the keys and key

material are no longer needed.

The evaluator shall verify the KMD includes a key lifecycle, that includes a description

where key material reside, how the key material is used, how it is determined that keys

and key material are no longer needed, and how the material is destroyed once it is not

needed and that the documentation in the KMD follows FCS_CKM.4 for the destruction.

Section 2 in the [KMD] describes the Configuration Server Key lifecycle with the creation

in Section 2.3. In Section 2 it describes how the Configuration server enables the client

application to read and write persistent property information. To protect the properties that

contain key material the configuration server caches the property information into a

memory cache.

Section 2.1 in the [KMD] describes the Configuration Server Key Material Storage and

Section 2.4 describes how the Configuration Server Key Material is destroyed including

why it is no longer needed.

Section 6 [KMD] describes the lifecycle of the Certificate Manager Private Key with the

creation in section 6.3. It describes how the TOE has the ability to manage certificates that

contain public encryption keys.

Section 6.1 [KMD] describes the Certificate Manager Private Key Storage and Section 6.4

describes the Certificate Manager Private Key destruction. Section 6.4.2 describes how

the keys are destroyed during a software upgrade.

Section 10 in the [KMD] describes the Hard Disk Key lifecycle with the creation in 10.3.

The use of the Hard Disk Key is to provide encryption for 10 partitions on the hard disk.

It describes in the [KMD] the Hard Disk Key Storage in Section 10.1 and the key

destruction description is in Section 10.4. It describes that the manufacturer never destroys

the passphrase from which the device derives the key and it lives in non-user-serviceable

BIOS/EFI memory.

Section 11 in the [KMD] describes the IPSec Key Material lifecycle with the creation in

section 11.3.2. Section 11 describes the use of the IPSec Key Material.

The IPSEC Key Material storage description is in Section 11.1 of the [KMD] document.

Section 11.4 contains the key destruction description and the cause of the destruction.

Section 14 in the [KMD] describes the Software Upgrade Key Material lifecycle.

Section 14 in the [KMD] describes how the Software Upgrade Key Material Destruction

destroys all stale key material prior to installing new software.

The installer does not create key material only destroys the archives and files that already

contained key material.

Section 16.3 [KMD] describes the Web Server Private key creation. It is used for the Web

Server private key for secure communications.

Section 16.1 [KMD] provides the Web Server Private Key Storage and Section 16.4

describes the key destruction, including the cause, which is a software swipe or overlay

upgrade.

Section 17 of the [KMD] describes how the Xerox Generic Certificate Authority Private

Key is used to sign the default device certificate.

Section 17.3 [KMD] describes the Xerox Generic Certificate Authority Private Key

creation.

It describes in Section 17.1, of the [KMD], the Xerox Generic Certificate Authority Private

Key. It describes the key destruction in Section 17.4 of the [KMD] which is prompted by

a wipe upgrade.

Section 18 [KMD] describes that for SSH/SFTP the Certificate Manager manages

certificate storage and destruction.


N/A

4.9 FCS_CKM.4 .1 Cryptographic Key Material Destruction


The evaluator shall verify the TSS provides a high- level description of what it means for

keys and key material to be no longer needed and when then should be expected to be

destroyed.

Section 6.1.6 [ST] states that temporary files that contain keys or keying material are

securely deleted when no longer used. When the device certificate is regenerated all

certificate based keys are destroyed. When the IPSec passphrase or is changed or server

certificate removed or replaced the old passphrase and certificate keys are destroyed.

The section also states that keys or keying material that are deleted during a software

upgrade process are securely deleted when no longer used.

Additionally, all keys and key material stored on the HDD are securely deleted before the

HDD is wiped during a software upgrade that performs a HDD wipe. These upgrade types

include altboot upgrades (PWS, USB, regardless of flags) and PSR upgrades.

Section 6.1.6 [ST] also provides a list of the private keys or passphrases that are securely

deleted when no longer needed for current or future use.


N/A

The [PP] defines no operational guidance assurance activity for this SFR.


The evaluator shall check to ensure the KMD lists each type of key material, its origin,

possible temporary locations (e.g. key register, cache memory, stack, FIFO), and

storage location.

The evaluator shall verify that the KMD describes when each type of key material is

destroyed (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.).

The evaluator shall also verify that, for each type of key and storage, the type of

destruction 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 destroyed by overwriting once and with

zeros, while secret keys stored on the internal persistent storage device are destroyed by

overwriting three times with a random pattern that is changed before each write").

The evaluator shall check to ensure the KMD lists each type of key material (software-

based key storage, BEVs, passwords, etc.) and its origin, storage location, and the

method for destruction for each key.

Section 3 [KMD] Data Destruction Functions and Commands describes the three overwrite

methods on which data is destroyed.

Section 3.1 describes the diskOverwrite Library which contains a function called

FileOverwrite(), to overwrite files.

Section 3.2 [KMD] describes the misc Library which contains an alternate set of functions

that developers can use to overwrite files.

The other method used to destroy the contents of a file is described in Section 3.3 [KMD],

the xsdelete program, by overwriting the files.

The table below includes the sections (see numbers in parenthesis) in the [KMD]

document where the [KMD] SFR requirements for FCS_CKM_EXT.4 Cryptographic Key

Material Destruction are met.

Name and Key

Type

Key Origin

Section in KMD

Temporary

Locations and

Permanent

Storage Location

Section in KMD

When Key

Material

Destroyed

Section in KMD

Key Destruction

Procedure

Section in KMD

Configuration

Server Key

Material - Disk

Encryption Key

(2.3)

Configuration

Server Key

Material Creation

The Configuration

Server is a

repository only.

Thus, it does not

create key

material; it merely

stores it.

(2) Configuration

Server caches

property

information in a

memory cache,

called Data Store

2.

(2.1) The

Configuration

Server stores its

configuration data

under the

/xpaths/nc_config

directory.

(2.4) Whenever

the configuration

server receives an

update

(2.4) The

configuration

server key

material

destruction

description.

Overwrite

Encryption Key -

SSL/TLS key

(1.4) Atlantis

Certificate

Creation with

Mocana RSA Key

(5.2) Mocana

RSA Key -

Atlantis uses

Mocana’s

NanoSec IPSEC

library in

conjunction with

OpenSSL to create

device certs. that

are compliant with

FIPS 186-4.

(1.3.3) Mocana

NanoSec Random.

When NanoSEC

computes keys it

stores them in

volatile memory.

(Table 1.1)

Atlantis

Certificate

Creation with

RSA-Key Pair

(Table 1.1)

Atlantis

Certificate

Creation with

RSA-Key Pair

Overwrite

Name and Key

Type

Key Origin

Section in KMD

Temporary

Locations and

Permanent

Storage Location

Section in KMD

When Key

Material

Destroyed

Section in KMD

Key Destruction

Procedure

Section in KMD

Certificate

Manager Private

Key - SSL/TLS

key

(6.3) Certificate

Manager Private

Key Creation

(6.1) Certificate

Manager stores all

private keys in the

file system of the

device under the

directory,

/xpaths/nc_var_etc

/ssl/private

(6.4.2) During

upgrade, no

software is

running so the

software

upgrader/installer

must destroy key

material.

(6.4) Certificate

Manager Private

Key Destruction

Hard Disk Key

- Disk Encryption

key

(10.3) Hard Disk

Creation

(10.1) Hard Key

storage

(10.4)

Manufacturing

never destroys the

passphrase from

which the device

derives its key, and

it lives in non-

user-serviceable

BIOS/EFI

memory.

(10.4) Hard Disk

Key Destruction.

IPSEC Key

Material

- Ipsec key

(11.3) IPSEC Key

Creation

(11.1) IPSEC Key

Storage

(11.4) The

function,

SaveConfigFileDa

ta(), destroys the

previous version

of the file before

replacing it with a

new one. In

addition, the

Software

Upgrader/Installer

destroys the

cfgipsec.xml.

encrypted file for

both types of

installation

processes — wipe

(full installation)

and overlay

(upgrade).

(11.4) IPSEC Key

Material

Destruction

description

Software Upgrade

Key Material Key

Destruction

-

Software Upgrade

key

(14) Software

Upgrade Key

Material Key

Destruction

The Software

Upgrade

application is

responsible for

destroying all stale

(14) Software

Upgrade Key

Material Key

Destruction

Installer does not

create key material

only destroying

keys.

(14) The Software

Upgrade

application is

responsible for

destroying all stale

key material prior

to installing new

software.

(14) Software

Upgrade Key

Material Key

Destruction

Name and Key

Type

Key Origin

Section in KMD

Temporary

Locations and

Permanent

Storage Location

Section in KMD

When Key

Material

Destroyed

Section in KMD

Key Destruction

Procedure

Section in KMD

key material prior

to installing new

software.

However, the

installer does not

create key

material; it merely

destroys the

archives and files

that already

contain key

material.

Web Server

Private Key

-

Software Upgrade

key

(16.3) Web Server

Private Key

Creation

(16.1) Web Server

Private Key

Storage

(16.4) The Web

Server private key

persists until the

next software

wipe or overlay

upgrade.

(16.4) The

Software Upgrade

(SWUP) installer

is responsible for

destroying the

private key.

Xerox Generic

Certificate

Authority Private

Key

- SSL/TLS key

(17.3) Xerox

Generic

Certificate

Authority Private

Key Creation

(17.4) The Xerox

private key

remains on the

device until the

next wipe

upgrade.

(17.4) The

Software Upgrade

(SWUP)

application

destroys the

cakey.pem file at

the path,

/xpaths/nc_var_etc

/ssl/LocalCA/priv

ate/cakey

SSH: SFTP

- SSH/SFTP key

(18) The

Certificate

Manager manages

Certificate Storage

(18) The

Certificate

Manager manages

Certificate

Destruction

(18) The

Certificate

Manager manages

Certificate

Destruction


For each software and firmware key destruction the evaluator shall repeat the following

tests for Nonvolatile Memory. There is no test for keys in volatile memory, since they are

destroyed by powering down the TOE. For the test below, “key” refers to keys and key

material.

Test 1: The evaluator shall utilize appropriate combinations of specialized Operational

Environment (e.g. a Virtual Machine) and development tools (debuggers, simulators,

etc.) to test that keys are destroyed, including all copies of the key that may have been

created internally by the TOE during normal cryptographic processing with that key.

For each key subject to destruction, including intermediate copies of keys that are

persisted encrypted by the TOE the evaluator shall:

1. Attach to the TOE software/firmware with a debugger, or use alternative methods to

perform the tests that follow, including the use of developer-provided special tools that

allow inspection of device memory in a special test configuration.

2. Record the value of the key in the TOE subject to destruction.

3. Cause the TOE to perform a normal cryptographic processing with the key from #1.

4. Cause the TOE to destroy the key.

5. Cause the TOE to stop the execution but not exit.

6. Cause the TOE to dump the entire memory footprint of the TOE into a

binary file.

7. Search the content of the binary file created in #6 for instances of the known key value

from #2. The test succeeds if no copies of the key from #2 are found in step #7 above and

fails otherwise.

The evaluator shall perform this test on all keys subject to destruction, including those

persisted in encrypted form, to ensure intermediate copies are cleared.

As stated in FCS_CKM_EXT.4 in the Test Report, no specific test activities, tested

included as part of FCS_CKM.4.

4.10 FCS_COP.1(a) Cryptographic Operation (Symmetric encryption/decryption)

TSS Assurance Activity:

N/A

The ST refers to the CMVP certificate number #2398 and CAVP AES certificate #3451.


N/A

The [PP] does not define Operational Guidance Assurance Activity for this SFR


The evaluator shall use tests appropriate to the modes selected in the above requirement

from "The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", The

CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining-

Message Authentication Code (CCM) Validation System (CCMVS)", and "The

Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" (these

documents are available from http://csrc.nist.gov/groups/STM/cavp/index.html) as a

guide in testing the requirement above. This will require that the evaluator have a

reference implementation of the algorithms known to be good that can produce test

vectors that are verifiable during the test.

No actual testing required, covered under OpenSSL CMVP certificate number #2398 and

CAVP AES certificate #3451. OpenSSL was tested on Linux 3.10 on Intel Atom E3845

(x86), which are consistent with the ST which states the TOE runs on Wind River 6 on

Linux 3.10 kernel using an Atom(TM) CPU E3845 processor.

4.11 FCS_COP.1(b) Crypt. Operation (for signature generation/verification)


Table 15 [ST] states the RSA Sig Gen/Ver 186-4 CAVP RSA certificate #2690 is used for

Signature generation/verification.


N/A



The evaluator shall use the signature generation and signature verification portions of

"The Digital Signature Algorithm Validation System” (DSA2VS), "The Elliptic Curve

Digital Signature Algorithm Validation System” (ECDSA2VS), and "The RSA Validation

System” RSA2VS as a guide in testing the requirement above. The Validation System

used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB

186-4). This will require that the evaluator have a reference implementation of the

algorithms known to be good that can produce test vectors that are verifiable during the

test.

No actual testing required, covered under CAVP RSA certificate #2690. Xerox OpenSSL

was tested on Linux 3.10 on Intel Atom E3845, which are consistent with the ST which

states the TOE runs on Wind River 6 on Linux 3.10 kernel using an Atom(TM)

CPU E3845 processor.

4.12 FCS_COP.1(d) Cryptographic operation (AES Data Encryption/Decryption)


The evaluator shall verify the TSS includes a description of the key size used for

encryption and the mode used for encryption.

Section 6.1.6, Encryption, [ST] references Table 15.

In Table 15 it states that the TOE utilizes AES CBC algorithm mode and CMVP certificate

number #2398 and CAVP AES certificate #3451. The key size is 256.


If multiple encryption modes are supported, the evaluator examines the guidance

documentation to determine that the method of choosing a specific mode/key size by the

end user is described.

The only encryption mode utilized by the TOE is AES CBC.

It states in the [SIG], page 4 Data Encryption, that encryption is enabled by default at the

factory and that the device will automatically set the key size -no set up is required. No

additional configuration is necessary.


The following tests are conditional based upon the selections made in the SFR. AES-

CBC Tests

AES-CBC Known Answer Tests

There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext,

ciphertext, and IV values shall be 128-bit blocks. The results from each test may either

be obtained by the evaluator directly or by supplying the inputs to the implementer and

receiving the results in response. To determine correctness, the evaluator shall compare

the resulting values to those obtained by submitting the same inputs to a known good

implementation.

KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of

10 plaintext values and obtain the ciphertext value that results from AES-CBC

encryption of the given plaintext using a key value of all zeros and an IV of all zeros.

Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the other five

shall be encrypted with a 256-bit all-zeros key. To test the decrypt functionality of AES-

CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values

as input and AES-CBC decryption.

KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of

10 key values and obtain the ciphertext value that results from AES-CBC encryption of

an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys

shall be 128-bit keys, and the other five shall be 256-bit keys. To test the decrypt

functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using

an all-zero ciphertext value as input and AES-CBC decryption.

KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the two

sets of key values described below and obtain the ciphertext value that results from AES

encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The

first set of keys shall have 128 128-bit keys, and the second set shall have 256 256-bit

keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be

zeros, for i in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall

supply the two sets of key and ciphertext value pairs described below and obtain the

plaintext value that results from AES-CBC decryption of the given ciphertext using the

given key and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128-

bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-

bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the

rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the

value that results in an all-zeros plaintext when decrypted with its corresponding key.

KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set

of 128 plaintext values described below and obtain the two ciphertext values that result

from AES-CBC encryption of the given plaintext using a 128-bit key value of all zeros

with an IV of all zeros and using a 256-bit key value of all zeros with an IV of all zeros,

respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the

rightmost 128-i bits be zeros, for i in [1,128]. To test the decrypt functionality of AES-

CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of

the same form as the plaintext in the encrypt test as input and AES-CBC decryption.

AES-CBC Multi-Block Message Test

The evaluator shall test the encrypt functionality by encrypting an i-block message where

1 < i <=10. The evaluator shall choose a key, an IV and plaintext message of length i

blocks and encrypt the message, using the mode to be tested, with the chosen key and IV.

The ciphertext shall be compared to the result of encrypting the same plaintext message

with the same key and IV using a known good implementation.

The evaluator shall also test the decrypt functionality for each mode by decrypting an i-

block message where 1 < i <=10. The evaluator shall choose a key, an IV and a

ciphertext message of length i blocks and decrypt the message, using the mode to be

tested, with the chosen key and IV. The plaintext shall be compared to the result of

decrypting the same ciphertext message with the same key and IV using a known good

implementation.

AES-CBC Monte Carlo Tests

The evaluator shall test the encrypt functionality using a set of 200 plaintexts, IV, and

key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The

plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall

be run as follows:

# Input: PT, IV, Key

for i = 1 to 1000:

if i == 1:

CT [1] = AES-CBC-Encrypt(Key, IV, PT)

PT = IV

else:

CT[i] = AES-CBC-Encrypt(Key, PT)

PT = CT[i-1]

The ciphertext computed in the 1000th iteration (i.e., CT [1000]) is the result for that

trial. This result shall be compared to the result of running 1000 iterations with the same

values using a known good implementation. The evaluator shall test the decrypt

functionality using the same test as for encrypt, exchanging CT and PT and replacing

AES-CBC-Encrypt with AES-CBC-Decrypt.

AES-GCM Test

The evaluator shall test the authenticated encrypt functionality of AES-GCM for each

combination of the following input parameter lengths: 128 bit and 256 bit keys Two

plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128

bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits,

if supported. Three AAD lengths. One AAD length shall be 0, if supported. One AAD

length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length

shall not be an integer multiple of 128 bits, if supported. Two IV lengths. If 96 bit IV is

supported, 96 bits shall be one of the two IV lengths tested.

The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD,

and IV tuples for each combination of parameter lengths above and obtain the ciphertext

value and tag that results from AES-GCM authenticated encrypt. Each supported tag

length shall be tested at least once per set of 10. The IV value may be supplied by the

evaluator or the implementation being tested, as long as it is known.

The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag,

AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a

Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall

include five tuples that Pass and five that Fail. The results from each test may either be

obtained by the evaluator directly or by supplying the inputs to the implementer and

receiving the results in response. To determine correctness, the evaluator shall compare

the resulting values to those obtained by submitting the same inputs to a known good

implementation.

XTS-AES Test

The evaluator shall test the encrypt functionality of XTS-AES for each combination of

the following input parameter lengths: 256 bit (for AES-128) and 512 bit (for AES-256)

keys Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-

zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an

integer multiple of 128 bits, if supported. The third data unit length shall be either the

longest supported data unit length or 216 bits, whichever is smaller.

The evaluator shall test the encrypt functionality using a set of 100 (key, plaintext and

128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-

AES encrypt. The evaluator may supply a data unit sequence number instead of the tweak

value if the implementation supports it. The data unit sequence number is a base-10

number ranging between 0 and 255 that implementations convert to a tweak value

internally.

The evaluator shall test the decrypt functionality of XTS-AES using the same

test as for encrypt, replacing plaintext values with ciphertext values and XTS-

AES encrypt with XTS-AES decrypt.

No actual testing required, covered under OpenSSL CMVP certificate number #2398 and

CAVP AES certificate #3451. OpenSSL was tested on Linux 3.10 on Intel Atom E3845



4.13 FCS_COP.1(g) Crypt. Operation (for keyed-hash message authentication)

TSS Assurance Activity:

N/A

It states in Table 15 [ST] that the HMAC uses CMVP certificate number #2859 and CAVP

HMAC Cert #2810 and SHS Cert #3511.


N/A



The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC)

Validation System (HMACVS)" as a guide in testing the requirement above. This will

require that the evaluator have a reference implementation of the algorithms known to

be good that can produce test vectors that are verifiable during the test.


and CAVP HMAC Cert #2810 and SHS Cert #3511. Mocana was tested with Wind River

Linux 6.0 running on Intel Atom E3800 (single-user mode), which is consistent with the

ST which states the TOE runs on Wind River 6 on Linux 3.10 kernel using an Atom(TM)

CPU E3845 processor.

4.14 FCS_RBG_EXT.1 (a) Extended: Cryptographic Operation (Random Bit

Generation)


For any RBG services provided by a third party, the evaluator shall ensure the TSS

includes a statement about the expected amount of entropy received from such a source,

and a full description of the processing of the output of the third-party source. The

evaluator shall verify that this statement is consistent with the selection made in

FCS_RBG_EXT.1.2 for the seeding of the DRBG. If the ST specifies more than one

DRBG, the evaluator shall examine the TSS to verify that it identifies the usage of each

DRBG mechanism.

The [ST], Section 6.1.6, states that both crypto modules use a SP800-90A AES-256 CTR

DRBG.

The OpenSSL DRBG is used for generating hard drive encryption keys, TLS keys, and

SSH keys. The Mocana DRBG is used for generating IPsec keys.

The entropy source draws from two component sources hard disk events and processor

interrupt events

Both crypto modules draw from the same entropy source in the Linux kernel, using the

native Linux source /dev/random and /dev/urandom.

Entropy Description

The evaluator shall ensure the Entropy Description provides all of the required

information as described in Appendix E. The evaluator assesses the information

provided and ensures the TOE is providing sufficient entropy when it is generating a

Random Bit String.

The vendor provided a detailed entropy analysis for the OpenSSL and Mocana DRBGs

which included a design description, justification for entropy, operating conditions for the

TOE and entropy system, and entropy health testing. The entropy document contains the

Operating System Entropy (Section 2), Design Description (Section 2.1), Entropy Source

(Section 2.1.1), Entropy Boundary, Entropy Justification (Section 2.2) and Health Testing

(Section 2.3).


The evaluator shall verify that the AGD guidance instructs the administrator how to

configure the TOE to use the selected DRBG mechanism(s), if necessary.

The [SIG] (pg. 14) confirmed that no additional configuration needs to be done for DRBG

on the TOE.


The evaluator shall perform 15 trials for the RBG implementation. If the RBG is

configurable by the TOE, the evaluator shall perform 15 trials for each configuration.

The evaluator shall verify that the instructions in the operational guidance for

configuration of the RBG are valid.

If the RBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG,

(2) generate the first block of random bits (3) generate a second block of random bits

(4) uninstantiate. The evaluator verifies that the second block of random bits is the

expected value. The evaluator shall generate eight input values for each trial. The first

is a count (0 – 14). The next three are entropy input, nonce, and personalization string

for the instantiate operation. The next two are additional input and entropy input for the

first call to generate. The final two are additional input and entropy input for the second

call to generate. These values are randomly generated. “Generate one block of random

bits” means to generate random bits with number of returned bits equal to the Output

Block Length (as defined in NIST SP800-90A).

If the RBG does not have prediction resistance, each trial consists of (1) instantiate

DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block

of random bits (5) uninstantiate. The evaluator verifies that the second block of random

bits is the expected value. The evaluator shall generate eight input values for each trial.

The first is a count (0 – 14). The next three are entropy input, nonce, and personalization

string for the instantiate operation. The fifth value is additional input to the first call to

generate. The sixth and seventh are additional input and entropy input to the call to

reseed. The final value is additional input to the second generate call.

The following paragraphs contain more information on some of the input values to be

generated/selected by the evaluator.

Entropy input: the length of the entropy input value must equal the seed length. Nonce:

If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce),

the nonce bit length is one-half the seed length.

Personalization string: The length of the personalization string must be <= seed length.

If the implementation only supports one personalization string length, then the same

length can be used for both values. If more than one string length is support, the

evaluator shall use personalization strings of two different lengths.

If the implementation does not use a personalization string, no value needs to be

supplied.

Additional input: the additional input bit lengths have the same defaults and restrictions

as the personalization string lengths.


and CAVP DRBG Cert #1336 and OpenSSL CMVP certificate number #2398 and CAVP

DRBG Cert #845. Mocana was tested with Wind River Linux 6.0 running on Intel Atom

E3800 (single-user mode) and OpenSSL was tested on Linux 3.10 on Intel Atom E3845



4.15 FCS_RBG_EXT.1 (b) Extended: Cryptographic Operation (Random Bit

Generation)


For any RBG services provided by a third party, the evaluator shall ensure the TSS

includes a statement about the expected amount of entropy received from such a source,

and a full description of the processing of the output of the third-party source. The

evaluator shall verify that this statement is consistent with the selection made in

FCS_RBG_EXT.1.2 for the seeding of the DRBG. If the ST specifies more than one

DRBG, the evaluator shall examine the TSS to verify that it identifies the usage of each

DRBG mechanism.

The [ST], Section 6.1.6, states that both crypto modules use a SP800-90A AES-256 CTR

DRBG.

The OpenSSL DRBG is used for generating hard drive encryption keys, TLS keys, and

SSH keys. The Mocana DRBG is used for generating IPsec keys.

The entropy source draws from two component sources hard disk events and processor

interrupt events

Both crypto modules draw from the same entropy source in the Linux kernel, using the

native Linux source /dev/random and /dev/urandom.

Entropy Description

The evaluator shall ensure the Entropy Description provides all of the required

information as described in Appendix E. The evaluator assesses the information

provided and ensures the TOE is providing sufficient entropy when it is generating a

Random Bit String.

The vendor provided a detailed entropy analysis for the OpenSSL and Mocana DRBGs

which included a design description, justification for entropy, operating conditions for the

TOE and entropy system, and entropy health testing. The entropy document contains the

Operating System Entropy (Section 2), Design Description (Section 2.1), Entropy Source

(Section 2.1.1), Entropy Boundary, Entropy Justification (Section 2.2) and Health Testing

(Section 2.3).


The evaluator shall verify that the AGD guidance instructs the administrator how to

configure the TOE to use the selected DRBG mechanism(s), if necessary.

The [SIG] (pg. 14) confirmed that no additional configuration needs to be done for DRBG

on the TOE.


The evaluator shall perform 15 trials for the RBG implementation. If the RBG is

configurable by the TOE, the evaluator shall perform 15 trials for each configuration.

The evaluator shall verify that the instructions in the operational guidance for

configuration of the RBG are valid.

If the RBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG,

(2) generate the first block of random bits (3) generate a second block of random bits

(4) uninstantiate. The evaluator verifies that the second block of random bits is the

expected value. The evaluator shall generate eight input values for each trial. The first

is a count (0 – 14). The next three are entropy input, nonce, and personalization string

for the instantiate operation. The next two are additional input and entropy input for the

first call to generate. The final two are additional input and entropy input for the second

call to generate. These values are randomly generated. “Generate one block of random

bits” means to generate random bits with number of returned bits equal to the Output

Block Length (as defined in NIST SP800-90A).

If the RBG does not have prediction resistance, each trial consists of (1) instantiate

DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block

of random bits (5) uninstantiate. The evaluator verifies that the second block of random

bits is the expected value. The evaluator shall generate eight input values for each trial.

The first is a count (0 – 14). The next three are entropy input, nonce, and personalization

string for the instantiate operation. The fifth value is additional input to the first call to

generate. The sixth and seventh are additional input and entropy input to the call to

reseed. The final value is additional input to the second generate call.

The following paragraphs contain more information on some of the input values to be

generated/selected by the evaluator.

Entropy input: the length of the entropy input value must equal the seed length. Nonce:

If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce),

the nonce bit length is one-half the seed length.

Personalization string: The length of the personalization string must be <= seed length.

If the implementation only supports one personalization string length, then the same

length can be used for both values. If more than one string length is support, the

evaluator shall use personalization strings of two different lengths.

If the implementation does not use a personalization string, no value needs to be

supplied.

Additional input: the additional input bit lengths have the same defaults and restrictions

as the personalization string lengths.


and CAVP DRBG Cert #1336 and OpenSSL CMVP certificate number #2398 and CAVP

DRBG Cert #845. Mocana was tested with Wind River Linux 6.0 running on Intel Atom

E3800 (single-user mode) and OpenSSL was tested on Linux 3.10 on Intel Atom E3845



4.16 FCS_IPSEC_EXT.1 Extended: IPsec selected

FCS_IPSEC_EXT.1.1


The evaluator shall examine the TSS and determine that it describes what takes place when

a packet is processed by the TOE, e.g., the algorithm used to process the packet. The TSS

describes how the SPD is implemented and the rules for processing both inbound and

outbound packets in terms of the IPsec policy. The TSS describes the rules that are

available and the resulting actions available after matching a rule. The TSS describes how

those rules and actions form the SPD in terms of the BYPASS (e.g., no encryption),

DISCARD (e.g., drop the packet) and PROTECT (e.g., encrypt the packet) actions defined

in RFC 4301.

As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is non-trivial

and the evaluator shall determine that the description in the TSS is sufficient to determine

which rules will be applied given the rule structure implemented by the TOE. For example,

if the TOE allows specification of ranges, conditional rules, etc., the evaluator shall

determine that the description of rule processing (for both inbound and outbound packets)

is sufficient to determine the action that will be applied, especially in the case where two

different rules may apply. This description shall cover both the initial packets (that is, no

SA is established on the interface or for that particular packet) as well as packets that are

part of an established SA.

The [ST], in Section 6.1.7, states the IPSec implements a Security Policy Database (SPD)

that allows configurations to discard, bypass, and protect packets. The SPD further uses

filtering to selectively manage which hosts (IPv4 address or IPv6 address or DNS names)

and protocols to use with IPsec, and which packets to pass through (bypass), drop (discard),

or to which to apply cryptography (protect).

Policies are configured at the TOE WebUI configuration pages. In the configuration,

Policies consist of combinations of three parts: Host Group, Protocol Group, and Actions

(bypass, discard, protect). Several policies can be configured and are listed in order on the

WebUI in the IPsec configuration page. The SPD which consists of these policies is

consulted during the processing of all traffic, both inbound and outbound. The entries in

the SPD are ordered as the order seen in the policy list on the WebUI. As a packet is

analyzed, the policies are consulted in order and the first matched policy will be used to

process the traffic, and the associated action applied. For any packet not fitting any of the

defined polices, the default action is to discard the packet.


The evaluator shall examine the guidance documentation to verify it instructs the

Administrator how to construct entries into the SPD that specify a rule for processing a

packet. The description includes all three cases – a rule that ensures packets are

encrypted/decrypted, dropped, and flow through the TOE without being encrypted. The

evaluator shall determine that the description in the guidance documentation is

consistent with the description in the TSS, and that the level of detail in the guidance

documentation is sufficient to allow the administrator to set up the SPD in an

unambiguous fashion. This includes a discussion of how ordering of rules impacts the

processing of an IP packet.

In the [SIG], Section IPsec (13), it contains the instructions for creating security policies

for the protocols not to be encrypted (BYPASS).

It also states that by default any packet that does not fit any user defined security policy

will be dropped (DISCARD).

The instructions for encrypting (PROTECT) a protocol via IPsec by creating a security

policy is also provided.


The evaluator uses the guidance documentation to configure the TOE to carry out the

following tests:

a) Test 1: The evaluator shall configure the SPD such that there is a rule for dropping a

packet, encrypting a packet, and (if configurable) allowing a packet to flow in plaintext.

The selectors used in the construction of the rule shall be different such that the evaluator

can generate a packet and send packets to the gateway with the appropriate fields (fields

that are used by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header.

The evaluator performs both positive and negative test cases for each type of rule (e.g.

a packet that matches the rule and another that does not match the rule). The evaluator

observes via the audit trail, and packet captures that the TOE exhibited the expected

behavior: appropriate packets were dropped, allowed to flow without modification,

encrypted by the IPsec implementation.

b) Test 2: The evaluator shall devise several tests that cover a variety of scenarios for

packet processing. As with Test 1, the evaluator ensures both positive and negative test

cases are constructed. These scenarios must exercise the range of possibilities for SPD

entries and processing modes as outlined in the TSS and guidance documentation.

Potential areas to cover include rules with overlapping ranges and conflicting entries,

inbound and outbound packets, and packets that establish SAs as well as packets that

belong to established SAs. The evaluator shall verify, via the audit trail and packet

captures, for each scenario that the expected behavior is exhibited, and is consistent with

both the TSS and the guidance documentation.

The Test Report in FCS_IPSEC_EXT.1 test case demonstrates that the TOE can configure

IPsec with the BYPASS, DISCARD and PROTECT rules. The further test verified with

positive and negative test cases that the rules exhibit the proper behavior. The test verified

that the configured SPD and different SAs was applied the expected behavior was seen;

and it also verified with Wireshark that the appropriate IPsec packets were being used.

FCS_IPSEC_EXT.1.2


The evaluator checks the TSS to ensure it states that the VPN can be established to

operate in tunnel mode and/or transport mode (as selected).

It states [ST], Section 6.1.7, that both transport and tunnel mode are supported and are

configuration options when configuring IPsec.


The evaluator shall confirm that the operational guidance contains instructions on how

to configure the connection in each mode selected.

The [SAG], (IPsec Section 4), contains the instructions for configuring the IPsec mode.

The selection can be made for either Transport Mode or Tunnel Mode.


The evaluator shall perform the following test(s) based on the selections chosen:

1. (conditional): If tunnel mode is selected, the evaluator uses the operational guidance

to configure the TOE to operate in tunnel mode and also configures an IPsec Peer to

operate in tunnel mode. The evaluator configures the TOE and the IPsec Peer to use any

of the allowable cryptographic algorithms, authentication methods, etc. to ensure an

allowable SA can be negotiated. The evaluator shall then initiate a connection from the

client to connect to the IPsec Peer. The evaluator observes (for example, in the audit

trail and the captured packets) that a successful connection was established using the

tunnel mode.

2. (conditional): If transport mode is selected, the evaluator uses the operational

guidance to configure the TOE to operate in transport mode and also configures an

IPsec Peer to operate in transport mode. The evaluator configures the TOE and the

IPsec Peer to use any of the allowed cryptographic algorithms, authentication methods,

etc. to ensure an allowable SA can be negotiated. The evaluator then initiates a

connection from the TOE to connect to the IPsec Peer. The evaluator observes (for

example, in the audit trail and the captured packets) that a successful connection was

established using the transport mode.

FCS_IPsec_EXT.1.2_Transport and Tunnel mode was tested in FCS_IPSec_EXT.1.4 in

Steps 2, 13 & Step 14.

Step 2 in FCS_IPSec_EXT.1.4 is where is was initiated and programed.

Step 13 in FCS_IPSec_EXT.1.4 uses Wireshark to show a successful handshake using

correct parameters.

Step 14 in FCS_IPSec_EXT.1.4 shows successful print job with the audit log.

FCS_IPSEC_EXT.1.3


The evaluator shall examine the TSS to verify that the TSS provides a description of how

a packet is processed against the SPD and that if no “rules” are found to match, that a

final rule exists, either implicitly or explicitly, that causes the network packet to be

discarded.

Section 6.1.7 [ST] states that a policy can be configured to block (discard) and set as default

action when no matches in the policies occur with a communicating node.

By default, any packet that does not fit any user defined security policy will be dropped

(DISCARD).


The evaluator checks that the operational guidance provides instructions on how to

construct the SPD and uses the guidance to configure the TOE for the following tests.

The [SIG], (Section IPsec 13), contains the instructions for creating security policies.

It states that by default any packet that does not fit any user defined security policy will be

dropped (DISCARD).

The [SAG] contains more detailed instructions in IPsec Section 4.


The evaluator shall perform the following test:

The evaluator shall configure the SPD such that it has entries that contain operations

that DISCARD, BYPASS, and PROTECT network packets. The evaluator may use the

SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall

construct a network packet that matches a BYPASS entry and send that packet. The

evaluator should observe that the network packet is passed to the proper destination

interface with no modification. The evaluator shall then modify a field in the packet

header; such that it no longer matches the evaluator-created entries (there may be a

“TOE created” final entry that discards packets that do not match any previous entries).

The evaluator sends the packet, and observes that the packet was not permitted to flow

to any of the TOE’s interfaces.

The Test Plan includes a test case in FCS_IPSec_Ext.1.3 that demonstrates that the TOE

allows a BYPASS entry network packet but discards a modified packet that does not match

the entry.

The test uses Wireshark to observe the successful transmission of packets that matched the

SPD created.

The source value of the packets were edited and Wireshark was used to observe the failure

of transmission.

FCS_IPSEC_EXT.1.4


The evaluator shall examine the TSS to verify that the symmetric encryption algorithms

selected (along with the SHA-based HMAC algorithm, if AES-CBC is selected) are

described. If selected, the evaluator ensures that the SHA-based HMAC algorithm

conforms to the algorithms specified in FCS_COP.1(g) Cryptographic Operations (for

keyed-hash message authentication).

Section 6.17, [ST], states that the encryption algorithms supported are AES 128 and AES

256 when AES is selected as the encryption algorithm and included in the negotiation with

the IPsec peer device. SHA-1 and SHA-256 are selected and supported.


The evaluator checks the operational guidance to ensure it provides instructions on how

to configure the TOE to use the algorithms selected by the ST author.

The [SIG] (pg. 15) states to make sure the “Authentication/Encryption” selection in the

evaluated configuration is SHA-1/AES-128.



The evaluator shall configure the TOE as indicated in the operational guidance

configuring the TOE to using each of the selected algorithms, and attempt to establish a

connection using ESP. The connection should be successfully established for each

algorithm.

The Test Plan includes a test case in FCS_IPSec_Ext.1.4 that demonstrates successful

protection of the packets by using the [SAG] to configure AES-CBC-128 and AES-CBC-

256 with – SHA1 and SHA-256 encryption algorithms.

FCS_IPSEC_EXT.1.5


The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented.

In Section 6.1.7 of the [ST] states that IKEv1 is implemented.


The evaluator shall check the operational guidance to ensure it instructs the

administrator how to configure the TOE to use IKEv1 and/or IKEv2 (as selected), and

uses the guidance to configure the TOE to perform NAT traversal for the following test

if IKEv2 is selected.

In the [SIG] (pg. 6) states the TOE only supports IKEv1 protocol.

The [SAG] in Section Ipsec (pg. 114) describes how to configure IKEv1.

Test Assurance Activity

(conditional): If IKEv2 is selected, the evaluator shall configure the TOE so that it will

perform NAT traversal processing as described in the TSS and RFC 5996, section 2.23.

The evaluator shall initiate an IPsec connection and determine that the NAT is

successfully traversed.

The TOE does not support IKEv2.

FCS_IPSEC_EXT.1.6


The evaluator shall ensure the TSS identifies the algorithms used for encrypting the

IKEv1 and/or IKEv2 payload, and that the algorithms AES-CBC-128, AES-CBC-256 are

specified, and if others are chosen in the selection of the requirement, those are included

in the TSS discussion.

In Section 6.1.7 [ST] states the encryption algorithms supported are AES 128 and AES 256

when AES is selected as the encryption algorithm.


The evaluator ensures that the operational guidance describes the configuration of the

mandated algorithms, as well as any additional algorithms selected in the requirement.

The guidance is then used to configure the TOE to perform the following test for each

ciphersuite selected.

It states in the [SIG] (pg. 6) that AES is recommended as the encryption option.

Section IPSec in the [SAG] (pg. 117) describes how to configure the algorithms.

Test Assurance Activity

The evaluator shall configure the TOE to use the ciphersuite under test to encrypt the

IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is

configured to only accept the payload encrypted using the indicated ciphersuite. The

evaluator will confirm the algorithm was that used in the negotiation.

FCS_IPSEC_EXT.1.6 – AES-CBC-128 & AES-CBC-256 were tested in

FCS_IPSEC_EXT.1.4.

FCS_IPSEC_EXT.1.7


The evaluator shall examine the TSS to ensure that, in the description of the IPsec

protocol supported by the TOE, it states that aggressive mode is not used for IKEv1

Phase 1 exchanges, and that only main mode is used. It may be that this is a configurable

option.

Section 6.1.7 [ST] states that IKEv1 is implemented, with main mode being used in IKEv1

and no use of aggressive mode implemented.


If the mode requires configuration of the TOE prior to its operation, the evaluator shall

check the operational guidance to ensure that instructions for this configuration are

contained within that guidance.

The [SIG] (pg. 6) states the TOE only supports IKEv1 protocol with main mode, no

additional configuration is necessary.


The evaluator shall also perform the following test:

(conditional): The evaluator shall configure the TOE as indicated in the operational

guidance, and attempt to establish a connection using an IKEv1 Phase 1 connection in

aggressive mode. This attempt should fail. The evaluator should then show that main

mode exchanges are supported. This test is not applicable if IKEv1 is not selected above

in the FCS_IPSEC_EXT.1.5 protocol selection.

The Test Plan includes a test case in FCS_IPSEC_EXT.1.7 that demonstrates the TOE will

not accept connections when an attempt is made to connect with the TOE using IKEv1 in

aggressive mode. Previous tests for Ipsec show main mode exchanged are successful.

FCS_IPSEC_EXT.1.8


N/A

The [ST] states that IKEv1 Phase 2 associated key lifetime can be configured in seconds,

minutes, or hours, with the maximum values being 28800, 480, and 8 respectively. Phase

2 peer negotiations use RSA certificates along DH modes configured (DH group 2 or 14)

or via pre-shared keys generated from the passphrased configured.


The evaluator verifies that the values for SA lifetimes can be configured and that the

instructions for doing so are located in the operational guidance. If time-based limits

are supported, the evaluator ensures that the values allow for Phase 1 SAs values for 24

hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the

number of packets or number of bytes, the evaluator just ensures that this can be

configured if selected in the requirement.

When testing this functionality, the evaluator needs to ensure that both sides are

configured appropriately. From the RFC “A difference between IKEv1 and IKEv2 is that

in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for

enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the

two ends have different lifetime policies, the end with the shorter lifetime will end up

always being the one to request the rekeying. If the two ends have the same lifetime

policies, it is possible that both will initiate a rekeying at the same time (which will result

in redundant SAs). To reduce the probability of this happening, the timing of rekeying

requests SHOULD be jittered.”

It states in the [SIG] (pg. 6) that the maximum key lifetime for IKE Phase 1 and 2 is 24

hours, which is the default value. The minimum key lifetime for is 60 seconds for IKE

Phase 1 and the 300 seconds for IKE Phase 2.

In the [SAG], Section Configuring Internet Key Exchange Settings, the instructions are

provided for setting the SA key lifetime values (seconds, minutes or hours).

The [SIG] (pg. 6) states the TOE only supports IKEv1 so SFR requirements for IKEv2

testing are not applicable to TOE.


Each of the following tests shall be performed for each version of IKE selected in the

FCS_IPSEC_EXT.1.5 protocol selection:

1. (Conditional): The evaluator shall configure a maximum lifetime in terms of the # of

packets (or bytes) allowed following the operational guidance. The evaluator shall

establish an SA and determine that once the allowed # of packets (or bytes) through this

SA is exceeded, the connection is renegotiated.

2. (Conditional): The evaluator shall construct a test where a Phase 1 SA is established

and attempted to be maintained for more than 24 hours before it is renegotiated. The

evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such

an action requires that the TOE be configured in a specific way, the evaluator shall

implement tests demonstrating that the configuration capability of the TOE works as

documented in the operational guidance.

3. (Conditional): The evaluator shall perform a test similar to Test 1 for Phase 2 SAs,

except that the lifetime will be 8 hours instead of 24.

The Test Plan includes a test case in FCS_IPSEC_EXT.1.8 that demonstrates the maximum

key lifetime setting for IKE Phase 1 and 2.

FCS_IPSEC_EXT.1.9


The evaluator shall check to ensure that the DH groups specified in the requirement are

listed as being supported in the TSS. If there is more than one DH group supported, the

evaluator checks to ensure the TSS describes how a particular DH group is

specified/negotiated with a peer.

Section 6.1.7 [ST] states that DH Groups 14 (2048-bit MODP) and 2 (1024-MODP) are

configurable.


The evaluator shall also perform the following test (this test may be combined with other

tests for this component, for instance, the tests associated with FCS_IPSEC_EXT.1.1):

For each supported DH group, the evaluator shall test to ensure that all IKE protocols

can be successfully completed using that particular DH group.

Along with the algorithms tested in FCS_IPSEC_EXT.1.4 DH 14 group was configured

and tested and IKE exchanged successfully negotiated.

FCS_IPSEC_EXT.1.10


The evaluator shall check that the TSS contains a description of the IKE peer

authentication process used by the TOE, and that this description covers the use of the

signature algorithm or algorithms specified in the requirement.

The [ST] states in Section 6.1.7 that. the encryption algorithms supported are AES 128 and

AES 256 when AES is selected as the encryption algorithm and included in the negotiation

with the IPsec peer device.

Phase 2 peer negotiations use RSA certificates along DH modes configured (DH group 2

or 14) or via preshared keys generated from the passphrased configured.

The key that was used to encrypt with AES 256 is encrypted itself by use of a RSA 2048-

bit private key.



For each supported signature algorithm, the evaluator shall test that peer authentication

using that algorithm can be successfully achieved and results in the successful

establishment of a connection.

The Test Plan includes a test case in FCS_IPSEC_EXT.1.1 that tests the Pre-shared keys

for FCS_IPsec_EXT.1.10.

4.17 FCS_HTTPS_EXT.1 Extended: HTTPS selected


The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses TLS to

establish an administrative session, focusing on any client authentication required by

the TLS protocol vs. security administrator authentication which may be done at a

different level of the processing stack.

It states in Section 6.1.7 in the [ST], that the use of HTTPS for securing data channels can

be configured at the TOE for use of all traffic to and from a client and the WebUI service.

HTTPS is implemented on the TOE, according to RFC 2818, which describes in depth how

the HTTPS uses the TLS protocol. HTTPS is enforced on WebUI pages that require

Administrative access and are security sensitive.

TOE can act as an HTTPS client to connect to external servers using HTTPS over TLS for

LDAP and Kerberos connections and the TOE acts as HTTPS Server for browsers

connections using HTTPS over TLS.


N/A

The [SIG] page 4 provides instructions to enable HTTPS and to force traffic to use SSL.

In addition to disable SSLv3.0 in favor of TLSv1.x .


Testing for this activity is done as part of the TLS testing; this may result in additional

testing if the TLS tests are done at the TLS protocol level.

As stated in the Test Report in FCS_HTTPS_EXT.1, testing for this activity is done as part

of the TLS testing.

4.18 FCS_TLS_EXT.1 Extended: TLS selected


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.

The [ST] states in Section 6.1.7, that the use of a ciphersuite is negotiated in a TLS

connection between client and server.

Section 6.1.7 of the ST indicates that the TOE supports the following ciphersuites which

is consistent with the ciphersuites listed for this SFR in the statement of security

requirements.

TLS_RSA_WITH_AES_128_CBC_SHA


TLS_DHE_RSA_WITH_AES_128_CBC_SHA


TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_ SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256


TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256


TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]


The evaluator shall also check the operational guidance 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).

In the [SIG], Section III (e.), it states that customers are advised to set the crypto policy of

their clients to request either TLS1.1 and TLS1.2 (SSLv3 should be disabled). Using the

Device in FIPS mode will automatically restrict the device to using TLS 1.x only.

Moreover, it states to disallow the use of RC4, MD5 and TLS1.0.

The [SIG], Section III (e.), also lists the following TLS ciphersuites supported by the TSF;





TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_ SHA256











The cryptographic module supports additional ciphers that be called by other unevaluated

functions. However, when using the TOE in FIPS mode, it will automatically restrict the

device to using TLS.


The evaluator shall also perform the following Testing Assurance Activity

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

2. The evaluator shall setup a man-in-the-middle tool between the TOE and the TLS Peer

and shall perform the following modifications to the traffic: a. [Conditional: TOE is a

server] Modify at least one byte in the server’s nonce in the Server Hello handshake

message, and verify that the server denies the client’s Finished handshake message.

b. [Conditional: TOE is a client] 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.

c. [Conditional: TOE is a client] If a DHE or ECDHE ciphersuite is supported, modify

the signature block in the Server’s KeyExchange handshake message, and verify that the

client rejects the connection after receiving the Server KeyExchange. d. [Conditional:

TOE is a client] 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.

The Test Plan includes a test case in FCS_TLS_EXT.1 that used Wireshark to verify that

the list of ciphersuites presented by the TOE for client/server negotiation when

establishing a trusted channel between the TOE and the Authentication Server, and

between the TOE and the Document Repository is consistent with the SFR and the TSS

list. The test also verified that the ciphersuites used for establishing a secure path for

remote administrator accessing the WebUI interface is consistent with the SFR and the

TSS.

4.19 FCS_SSH_EXT.1 Extended: SSH selected

FCS_SSH_EXT.1.1

No Assurance Activities

FCS_SSH_EXT.1.2


The evaluator shall check to ensure that the TSS contains a description of the public key

algorithms that are acceptable for use for authentication, that this list conforms to

FCS_SSH_EXT.1.5, and ensure that password-based authentication methods are also

allowed.

In the [ST], Section 6.1.7, the description of the public key algorithms is provided. It lists

the SSH transport supported algorithms as; AES-CBC-128 and AES-CBC-256 only.

Public key algorithms supported are SSH_RSA, ecdsa-sha2-nistp256, and ecdsa-sha2-

nistp384 only, which conforms to the algorithms in FCS_SSH_EXT.1.5.

Additionally, it states that authentication to the SFTP server can be with username and

password (password-based authentication).



1. The evaluator shall, for each public key algorithm supported, show that the TOE

supports the use of that public key algorithm to authenticate a user connection. Any

configuration activities required to support this test shall be performed according to

instructions in the operational guidance.

2. Using the operational guidance, the evaluator shall configure the TOE to accept

password-based authentication, and demonstrate that a user can be successfully

authenticated to the TOE over SSH using a password as an authenticator.

The Test Plan includes a test case in FCS_SSH_EXT.1.2 that demonstrates that the TOE

supports SSH RSA encryption for authentication when configured per the [SIG] and [SAG]

operational guides.

The test used Wireshark to observe the SSH RSA packets that were displayed when the

audit log is transferred to the Cerberus server.

FCS_SSH_EXT.1.3


The evaluator shall demonstrate that if the TOE receives a packet larger than that

specified in this component, that packet is dropped.

The Test Plan includes a test case in FCS_SSH_EXT.1.3 that demonstrates the TOE will

drop a packet that is not supported.

The test utilized Linux to prove that the SFTP connection was refused.

In addition, that Wireshark verified that the packets were dropped.

FCS_SSH_EXT.1.4


The evaluator shall check the description of the implementation of this protocol in the

TSS to ensure that optional characteristics are specified, and the encryption algorithms

supported are specified as well. The evaluator shall check the TSS to ensure that the

encryption algorithms specified are identical to those listed for this component. The

evaluator shall also check the operational guidance to ensure that it contains

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

(for instance, the set of algorithms advertised by the TOE may have to be restricted to

meet the requirements).

Section 6.1.7 [ST] identifies the supported encryption algorithms to include AES-CBC-

128 and AES-CBC-256 only.

It states in the [SIG] (pg. 7) that for SFTP the underlying SSH encryption algorithm (which

SFTP uses) cannot be configured.

In addition, it states in the [SIG], page 15, that all specific characters for these devices are

configured by default. Note, however, that the devices do not provide options for

authorized administrators to further configure SSH and SFTP other than to select

passphrase vs. certificate.



The evaluator shall establish a SSH connection using each of the encryption algorithms

specified by the requirement. It is sufficient to observe (on the wire) the successful

negotiation of the algorithm to satisfy the intent of the test.

The Test Plan includes a test case in FCS_SSH_EXT.1.4 that demonstrates the SSH

connection used for SSH2 encryption algorithm during the audit log transfer to the

Cerberus Server.

FCS_SSH_EXT.1.5


The assurance activity associated with FCS_SSH_EXT.1.4 verifies this requirement.

Public key algorithms supported are SSH_RSA only as stated in Section 6.1.7 of the ST.

FCS_SSH_EXT.1.6


The evaluator shall check the TSS to ensure that it lists the supported data integrity

algorithms, and that that list corresponds to the list in this component. The evaluator

shall also check the operational guidance to ensure that it contains instructions to the

administrator on how to ensure that only the allowed data integrity algorithms are used

in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not

allowed).

The data integrity algorithms allowed in SSH transport connection is HMAC-SHA1,

HMAC-SHA1-96, HMAC-SHA2-512 per Section 6.1.7 of the [ST].

It states in the [SIG] (pg. 7) that for SFTP the underlying SSH encryption algorithm (which




The evaluator shall establish a SSH connection using each of the integrity algorithms

specified by the requirement. It is sufficient to observe (on the wire) the successful

negotiation of the algorithm to satisfy the intent of the test.



Cerberus Server.

Wireshark was used to observe the packets which proved that the TOE SSH2 HMAC-

SHA1, HMAC-SHA1-96, HMAC-SHA2-512 encryption.

FCS_SSH_EXT.1.7


The evaluator shall ensure that operational guidance contains configuration

information that will allow the security administrator to configure the TOE so that all

key exchanges for SSH are performed using DH group 14 and any groups specified from

the selection in the ST. If this capability is “hard-coded” into the TOE, the evaluator

shall check the TSS to ensure that this is stated in the discussion of the SSH protocol.

The [SIG] (pg. 7) states in that for SFTP the underlying SSH encryption algorithm (which


Stated in Section 6.1.7 [ST], the TSF ensures that diffie-hellman-group14-sha1 is the only

allowed key exchange method used for the SSH protocol. This is hardcoded into the SSH

implementation by the TSF.



The evaluator shall attempt to perform a diffie-hellman-group1-sha1 key exchange, and

observe that the attempt fails. For each allowed key exchange method, the evaluator

shall then attempt to perform a key exchange using that method, and observe that the

attempt succeeds.



Cerberus Server.

Wireshark was used to observe the packets which proved that the TOE SSH2 Diffie-

Hellman-group14-SHA1 authentication encryption.

4.20 FCS_KYC_EXT.1 Extended: Key Chaining

FCS_KYC_EXT.1.1 The TSF shall maintain a key chain of: [one] while maintaining an

effective strength of [256 bits].


The evaluator shall verify the TSS contains a high-level description of the BEV sizes –

that it supports BEV outputs of no fewer 128 bits for products that support only AES-

128, and no fewer than 256 bits for products that support AES-256.

In Section 6.1.6 [ST], it states that the TOE generates a BEV output of 256 bits from the

OpenSSL DRBG for input into the AES256 encryption algorithm for disk encryption.


The evaluator shall examine the KMD to ensure that it describes a high level description

of the key hierarchy for all accepted BEVs. The evaluator shall examine the KMD to

ensure it describes the key chain in detail. The description of the key chain shall be

reviewed to ensure it maintains a chain of keys using key wrap, submask combining, or

key encryption.

The evaluator shall examine the KMD to ensure that it describes how the key chain

process functions, such that it does not expose any material that might compromise any

key in the chain. (e.g. using a key directly as a compare value against a TPM) This

description must include a diagram illustrating the key hierarchy implemented and detail

where all keys and keying material is stored or what it is derived from. The evaluator

shall examine the key hierarchy to ensure that at no point the chain could be broken

without a cryptographic exhaust or the initial authorization value and the effective

strength of the BEV is maintained throughout the Key Chain.

The evaluator shall verify the KMD includes a description of the strength of keys

throughout the key chain.

In [KMD], (Section 1.2.5), it states that TOE does not employ key chaining. The BEV

(Hard Drive Encryption Key) is generated directly from the DRBG; therefore, an effective

keychain of one. There is no key derivation, agreement or transport scheme involved in the

generation of the 256-bit AES key.

5.1 FDP_ACC.1 Subset access control

No separate assurance activity, refer to FDP_ACF.1.

5.2 FDP_ACF.1 Security attribute based access control


The evaluator shall check to ensure that the TSS describes the functions to realize SFP

defined in Table 2 and Table 3.

In Section 6.1.3 in the [ST], it states that the Functions referenced in Table 10 and Table

11 via the Web user interface or the Local User interface are as follows: Print, Scan, Fax

(receive and send), Copy and Document Storage and Retrieval. The table describes the

access controls that are in place for users, such as U. NORMAL and Unauthenticated, as

well as U.ADMIN. U. NORMAL and Unauthenticated are denied the “Read”, “Modify”

and “Delete” access to the TOE functions listed above. U. NORMAL users require explicit

authorization from system administrators. This corroborates with the SFPs defined in

Tables 2 and 3 of the [PP].



of the operation to realize the SFP defined in Table 2 and Table 3, which is consistent

with the description in the TSS.

The [SIG], Section 4-Authorization, instructs that when adding new user accounts, to set

up the user roles and permissions by following the instructions in the [SAG] – Section 4.

In addition, the instructions for setting the permissions for all Non-logged in Users Roles

for Not Allowed was provided for by following using the detailed instructions in Section

4 of the [SAG]:

All print permission categories

All apps/services and tools

The [SAG] in Section 4 also states to ensure that Logged-In-Users have access (permission

allowed) to the print from, fax, workflow scanning and e-mail.

Section 15 (Secure Print) of the [SIG], warns to ensure for best security print jobs, the TOE

should be set to Secure Print by using instructions in Section 5 of the [SAG].

Furthermore, the guide states to ensure that print jobs can only be submitted as secure print

jobs for logged in users (since Non-logged in users are denied print permission to any jobs

in the evaluator configuration) and to follow the instructions in Section 4 of the [SIG].

Detailed instructions are provided in the [SAG] in Section 4 – Authorization for allowing

or restricting access to the TOE features.


The evaluator shall perform tests to confirm the functions to realize the SFP defined in

Table 2 and Table 3 with each type of interface (e.g., operation panel, Web interfaces)

to the TOE.

The evaluator testing should include the following viewpoints:

• representative sets of the operations against representative sets of the object types

defined in Table 2 and Table 3 (including some cases where operations are either

permitted or denied)

• representative sets for the combinations of the setting for security attributes that are

used in access control

The Test Report includes a test case in FDP_ACF.1 that demonstrates the security policy

enforcement capabilities of the TOE.

The test case confirms that only the designated TOE users can create, read, modify or delete

print, copy, scan and fax jobs based on the configured security policies.

It was determined that only an administrator or a job owner (user who created job) can

delete a job.

No user is allowed to modify a job.

In addition, no user can read data for a job created on the TOE.

5.3 FDP_DSK_EXT.1 Extended: Protection of Data on Disk


The evaluator shall examine the TSS to ensure that the description is comprehensive in

how the data is written to the Device and the point at which the encryption function is

applied. For the cryptographic functions that are provided by the Operational

Environment, the evaluator shall check the TSS to ensure it describes the interface(s)

used by the TOE to invoke this functionality.

The evaluator shall verify that the TSS describes the initialization of the Device at

shipment of the TOE, or by the activities the TOE performs to ensure that it encrypts all

the storage devices entirely when a user or administrator first provisions the Device.

The evaluator shall verify the TSS describes areas of the Device that it does not encrypt

(e.g., portions that do not contain confidential data boot loaders, partition tables, etc.).

If the TOE supports multiple Device encryptions, the evaluator shall examine the

administration guidance to ensure the initialization procedure encrypts all Devices.

The [ST], Section 6.1.6, states all files and meta data for the file system will be written in

blocks by the file system code. Those blocks are passed through a block i/o driver to

loopaes, which then encrypts each block sending the encrypted block to the hard disk drive

controller driver that sends it to the disk drive controller.

Furthermore, that the encryption is applied when the user writes file data -> file system

writes data in blocks -> loopaes gets block and encrypts -> drive block controller writes

block (which is encrypted data) to disk drive.

It also states that encryption is enabled by default at the factory when the device is first

delivered.

It was noted in the [ST] (6.1.6) that the device does not encrypt data in these partitions

named: boot, root, opt, and swap.

The [ST] states that details on encrypted partitions are in the [ KMD].


The evaluator shall review the AGD guidance to determine that it describes the initial

steps needed to enable the Device encryption function, including any necessary

preparatory steps. The guidance shall provide instructions that are sufficient to ensure

that all Devices will be encrypted when encryption is enabled or at shipment of the TOE.

The [SIG] (Section 10. Data Encryption) states that the data encryption is enabled by

default by the factory when the TOE is first delivered.


The evaluator shall verify the KMD includes a description of the data encryption engine,

its components, and details about its implementation (e.g. for hardware: integrated

within the device’s main SOC or separate co-processor, for software: initialization of

the Device, drivers, libraries (if applicable), logical interfaces for

encryption/decryption, and areas which are not encrypted (e.g. boot loaders, portions

that do not contain confidential data, partition tables, etc.)). The evaluator shall verify

the KMD provides a functional (block) diagram showing the main components (such as

memories and processors) and the data path between, for hardware, the Device’s

interface and the Device’s persistent media storing the data, or for software, the initial

steps needed to the activities the TOE performs to ensure it encrypts the storage device

entirely when a user or administrator first provisions the product. The hardware

encryption diagram shall show the location of the data encryption engine within the data

path. The evaluator shall validate that the hardware encryption diagram contains

enough detail showing the main components within the data path and that it clearly

identifies the data encryption engine.

The evaluator shall verify the KMD provides sufficient instructions to ensure that when

the encryption is enabled, the TOE encrypts all applicable Devices. The evaluator shall

verify that the KMD describes the data flow from the interface to the Device’s persistent

media storing the data. The evaluator shall verify that the KMD provides information on

those conditions in which the data bypasses the data encryption engine (e.g. read-write

operations to an unencrypted area).

The evaluator shall verify that the KMD provides a description of the boot initialization,

the encryption initialization process, and at what moment the product enables the

encryption. If encryption can be enabled and disabled, the evaluator shall validate that

the product does not allow for the transfer of confidential data before it fully initializes

the encryption. The evaluator shall ensure the software developer provides special tools

which allow inspection of the encrypted drive either in-band or out-of-band, and may

allow provisioning with a known key.

The [KMD] states in Section 10, Hard Disk Key, states that during bootup, Atlantis

determines whether a key exists within the BIOS NVM.

It describes that if there is no key how it obtains 256 bits of entropy via an OpenSSL FIPS

function. The value is stored as an ASCII-encoded key in BIOS NVM.

Furthermore, it describes how Atlantis uses the key and loop-back interface of the Linux

Kernel to create and initialize each file system. This is then made accessible to user-space

via an appropriate mount point.

The [KMD] Section 10, describes the process if the key already exists in the BIOS,

Atlantis uses the key to mount the file system using loop-back driver.

Figure 10.1 in the KMD provides a diagram of the Hard Disk Key Creation process. The

diagram includes the Block Device Path and Loop Mount Operation. and Serial Peripheral

Interface.


The evaluator shall perform the following tests:

Test 1. Write data to Storage device: Perform writing to the storage device with

operating TSFI which enforce write process of User documents and Confidential TSF

data.

Test 2. Confirm that written data are encrypted: Verify there are no plaintext data

present in the encrypted range written by Test 1; and, verify that the data can be

decrypted by proper key and key material.

All TSFIs for writing User Document Data and Confidential TSF data should be tested

by above Test 1 and Test 2.

The Test Report includes a test case in FDP_DSK_EXT.1 that demonstrates that the TOE

encrypts the data on the hard disk.

The test includes steps that verify encrypted partitions and its respective file systems.

5.4 FDP_FXS_EXT.1 Extended: Fax separation


The evaluator shall check the TSS to ensure that it describes:

1. The fax interface use cases

2. The capabilities of the fax modem and the supported fax protocols

3. The data that is allowed to be sent or received via the fax interface

4. How the TOE can only be used transmitting or receiving User Data using fax

protocols

It states in Section 6.1.8 in the [ST], that the only communication via the fax interface

allowed is that of transmitting or receiving User Data using fax protocols.

Furthermore, that the TOE provides separation between the fax processing board and the

network interface. Therefore, it prevents an interconnection between the PSTN and the

internal network.

All internal command calls (API) and response messages for both the network and fax

interfaces are statically defined within the TOE. No user or system administrator is able to

change their formats or functionalities.

In addition, it states for network interface to fax interface (LanFax) jobs, that the entire job

must be received as an image and buffered in memory before it is sent out through the fax

interface.

For fax interface to network interface (fax forwarding to email) jobs, the entire job must

be received from the fax interface and buffered in memory before it is transformed by an

intermediary subsystem into an email attachment and sent out through the network

interface



of the fax interface in terms of usage and available features.

The [SIG], Section 3, named Embedded Fax contains a description of the fax interface

usage and features.

The instructions for setting the minimum length of the secure receive passcode are in

Section 8 in the [SAG]. Additionally, in Section 8, there is a description of the required fax

settings at the control panel and how to set the secure receive passcode lengths, enabling

the Secure Fax Feature.


The evaluator shall test to ensure that the fax interface can only be used transmitting or

receiving User Data using fax protocols. Testing will be dependent upon how the TOE

enforces this requirement. The following tests shall be used and supplemented with

additional testing or a rationale as to why the following tests are sufficient:

1. Verify that the TOE accepts incoming calls using fax carrier protocols and rejects

calls that use data carriers. For example, this may be achieved using a terminal

application to issue modem commands directly to the TOE from a PC modem (issue

terminal command: ‘ATDT <TOE Fax Number>’) – the TOE should answer the call

and disconnect.

2. Verify TOE negotiates outgoing calls using fax carrier protocols and rejects

negotiation of data carriers. For example, this may be achieved by using a PC modem

to attempt to receive a call from the TOE (submit a fax job from the TOE to <PC modem

number>, at PC issue terminal command: ‘ATA’) – the TOE should disconnect without

negotiating a carrier.

The Test Report includes a test case in FDP_FXS_EXT.1 that demonstrates that the fax

rejects data carriers.

5.5 FDP_RIP.1(a) Subset residual information protection



describing where image data is stored and how and when it is overwritten.

It states in the [ST], Section 6.1.9, that the TOE automatically starts an IIO procedure for

all abnormally terminated copy, print, scan or fax jobs stored on the HDD prior to coming

“on line” when any of the following occurs: a reboot or once the MFD is turned back on

after a power failure/disorderly shutdown.

It further states that the image overwrite security function can also be invoked manually

(on demand) by the system administrator (ODIO). Once invoked, the ODIO cancels all

jobs, halts the printer interface (network), performs the overwrites, and then the network

controller reboots.

A scheduling function allows ODIO to be executed on a recurring basis as set up by the

System Administrator.

Furthermore, a standard ODIO overwrites all files written to temporary storage areas of the

HDD. A full ODIO overwrites those files as well as the Fax mailbox/dial directory and

Scan to mailbox data.


The evaluator shall check to ensure that the operational guidance contains instructions

for enabling the Image Overwrite function.

The [SAG], Security, Section 4(Overwriting Image Data), describes how to enable the

Image Overwrite function.

The image overwrite can be enabled for immediate overwrite or a scheduled time (daily,

weekly, monthly).


The evaluator shall include tests related to this function in the set of tests performed in

FMT_SMF.1.

This is tested as part of FMT_MTD.1, which tests the functions in FMT_SMF.1.

5.6 FDP_RIP.1(b) Subset residual information protection



describing what customer-supplied data is to be purged, where it is stored, and how it is

made unavailable.

In the [ST], Section 6.1.9, it states that the purge function is invoked manually by the

system administrator.

Once invoked, the purge function overwrites all jobs that are actively being processed by

the TOE or are being held on the TOE for later processing; overwrites all jobs and log files

that are stored on the hard drive(s); overwrites all local authentication data stored on the

internal database; overwrites all customer data stored in address books and accounting

databases and resets the fax and copy controller NVM on the TOE to their factory default

values.

At the completion of the purge function the TOE will reformat the hard drive(s).


The evaluator shall check to ensure that the operational guidance contains instructions

for initiating the Purge Data function.

The [SIG], Section Erase Customer Data, states to initiate the feature to erase all customer

data from the device at the control panel by following the instructions for ‘Erase Customer

Data’ in Section 10 of the [SAG].


The evaluator shall include tests related to this function in the set of tests performed in

FMT_SMF.1.

This is tested as part of FMT_MTD.1, which tests the functions in FMT_SMF.1.

5.7 FIA_AFL.1 Authentication failure handling


The evaluator shall check to ensure that the TSS contains a description of the actions in

the case of authentication failure (types of authentication events, the number of

unsuccessful authentication attempts, actions to be conducted), which is consistent with

the definition of the SFR.

Section 6.1.1 in the [ST], states for the WebUI login that after three unsuccessful login

attempts, where the login name or passwords were incorrect, the TOE shall impose a

Lockout Period of five minutes for that session only. It also states that for a lockout session

for the WebUI, the user will receive a message stating, “Login is currently locked: too

many invalid login attempts. Please try again later.”

The [ST] also states, the actions for the unsuccessful authentication attempts for the local

user interface are; after three successive failed attempts to login at Local UI (i.e. the user

acknowledged the error, and submitted incorrect data three times without canceling out of

the authentication process) the device shall lockdown Touch UI Authentication. The Local

UI shall continue to display the login prompt after the lockdown has been initiated

The [ST] (6.1.1) also states that all attempts to login at the Local UI shall fail after the

lockdown has been initiated, even if a valid username and password are provided for the

Local UI lockdown shall last for five minutes.


The evaluator shall check to ensure that the administrator guidance describes the setting

for actions to be taken in the case of authentication failure, if any are defined in the SFR.

The [SIG] (Section III (s.)) states that the device has an automatic 5-minute lockout that

will disable the ability of anyone who enters three unsuccessful incorrect authentication

credentials at the local user interface or Web user interface. This lockout period is fixed

and cannot be altered.

The [SAG], Section named System Timeout, describes in more detail the system timeout

feature of the device.



1. The evaluator shall check to ensure that the subsequent authentication attempts do

not succeed by the behavior according to the actions defined in the SFR when

unsuccessful authentication attempts reach the status defined in the SFR.

2. The evaluator shall check to ensure that authentication attempts succeed when

conditions to re-enable authentication attempts are defined in the SFR and when the

conditions are fulfilled.

3. The evaluator shall perform the tests 1 and 2 described above for all the targeted

authentication methods when there are multiple Internal Authentication methods (e.g.,

password authentication, biometric authentication).

4. The evaluator shall perform the tests 1 and 2 described above for all interfaces when

there are multiple interfaces (e.g., operation panel, Web interfaces) that implement

authentication attempts.

The Test Report includes test case Authentication Failure Actions, which tests the

authentication failure handling capability of the TOE. The evaluator deliberately entered

incorrect passwords and observed that after the three of failed attempts the system locked

the user account for the five- minute time period.

5.8 FIA_ATD.1 User attribute definition


The evaluator shall check to ensure that the TSS contains a description of the user

security attributes that the TOE uses to implement the SFR, which is consistent with the


Section 6.1.1 of the [ST], states that the TOE maintains username and password credentials

for each authenticated user. User and associated roles configured for the authenticated

user.


N/A

The [SIG] (Section 3 Authentication) instructs the to set up unique user accounts with

appropriate credentials (username and passwords) on the device for all users who require

access to the device via the Control Panel or WebUI.

Detailed instructions are provided in Authentication Section of the [SAG].

5.9 FIA_PMG_EXT.1 Extended: Password Management


N/A

The [ST] Section 6.1.1states that the administrator can set whether the password shall be

required to contain at least one numeric character. The administrator can set the minimum

required password length to be anywhere between 1 and 63 characters.

Moreover, it states that the valid character set for setting up passwords for accounts is the

printable ISO 8859-15 set and Unicode/UTF-8 set, including: “!”, “@”, “#”, “$”, “%”, “^”,

“&”, “*”, “(“, “)”, but not allowing the ‘>’character.


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

guidance to security administrators on the composition of passwords, and that it

provides instructions on setting the minimum password length.

[SIG], Section 1 Authentication Passwords, states that passwords should be set for all users

to a minimum of 8 alphanumeric characters. In addition, that authentication passwords be

strong by using a combination of upper and lowercase letters and digits. To use special

characters such as [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,)”, and any other

printable ISO 8859-15 set and Unicode/UTF-8 set characters except “>”, and not to use

common names or phrases etc. to ensure a strong password.


The evaluator shall also perform the following Testing Assurance Activity.

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 Test Report includes test case Password Requirement Management, which tests the

password management capability of the TOE. The evaluator configured password

requirements for the TOE to be minimum length of 15 and require at least 1 number.

Additionally, the evaluator entered passwords that did not meet this requirement and

passwords that did meet the requirement to ensure the TOE met the password requirement.

5.10 FIA_UAU.1 Timing of authentication


The evaluator shall check to ensure that the TSS describes all the identification and

authentication mechanisms that the TOE provides (e.g., Internal Authentication and

authentication by external servers).

The evaluator shall check to ensure that the TSS identifies all the interfaces to perform

identification and authentication (e.g., identification and authentication from operation

panel or via Web interfaces).

The evaluator shall check to ensure that the TSS describes the protocols (e.g., LDAP,

Kerberos, OCSP) used in performing identification and authentication when the TOE

exchanges identification and authentication with External Authentication servers.

The evaluator shall check to ensure that the TSS contains a description of the permitted

actions before performing identification and authentication, which is consistent with the


In Section (6.1.1), in the [ST] it states that the TOE provides the following means in which

to identify and authenticate to the TOE; Local UI and WebUI, Network Authentication and

Smartcard. In addition, that the Local UI utilizes an operation panel and the Web UI utilizes

a browser. Both use a local information database for users. The network authentication

uses an external authentication server (LDAP, SMB, Kerberos) to identify and authenticate

users. Furthermore, it states that by default unauthenticated users (Guest users) can execute

the following actions: Copy, Print, Fax, Scan to Destination, Scan to Email. The only

operation permitted prior to successful identification and authentication is job requests can

be received via printing protocols


The evaluator shall check to ensure that the administrator guidance contains

descriptions of identification and authentication methods that the TOE provides (e.g.,

External Authentication, Internal Authentication) as well as interfaces (e.g.,

identification and authentication from operation panel or via Web interfaces), which are

consistent with the ST (TSS).

The [SIG], Section 3 Authentication, describes the methods of authentication. The system

administrator can set up local authentication or network (remote) authentication for users.

Detailed descriptions of the methods of authentication are in the [SAG] in Section 4 –

Setting Access Rights (Authentication). The methods described are; validating on the

device or network, convenience authentication (proximity card), Xerox secure access (card

reader) or smart card, which is consistent with the TSS description.



1. The evaluator shall check to ensure that identification and authentication succeeds,

enabling the access to the TOE when using authorized data.

2. The evaluator shall check to ensure that identification and authentication fails,

disabling the access to the TOE afterwards when using unauthorized data. The

evaluator shall perform the tests described above for each of the authentication methods

that the TOE provides (e.g., External Authentication, Internal Authentication) as well as

interfaces (e.g., identification and authentication from operation panel or via Web

interfaces).

The Test Report includes the test case in Time of Authentication, which tests the

authentication and authorization capability of the TOE. The tests that were performed were

to verify that the passwords were obfuscated and that the appropriate features of the TOE

were available to the different users. The test case includes both positive and negative cases

for all methods of user authentication (i.e. local authentication and external ‘network’

authentication (LDAP) from both the LUI and WebUI.

5.11 FIA_UAU.7 Protected authentication feedback


The evaluator shall check to ensure that the TSS contains a description of the

authentication information feedback provided to users while the authentication is in

progress, which is consistent with the definition of the SFR.

It states in the [ST], Section 6.1.1, that when a user enters a password in either the Web

User Interface or Local User Interface asterisks are displayed and not characters so that the

password is obfuscated.


N/A

It states in the SIG (pg. 14) that all passwords on the (UI and WebUI) Control panel will

obfuscated.



1. The evaluator shall check to ensure that only the information defined in the SFR is

provided for feedback by attempting identification and authentication.

2. The evaluator shall perform the test 1 described above for all the interfaces that the

TOE provides (e.g., operation panel, identification and authentication via Web

interface).

As stated in FIA_UAU.7 in the Test Report, not tested separately. When executing the tests

included with FIA_UAU.1 verify through the Web UI, Operation Panel, and Smart Card,

that the authentication data entered is obscured by dummy characters. Take screenshots

and include in this activity.

5.12 FIA_UID.1 Timing of identification


It is covered by assurance activities for FIA_UAU.1.

The TSS Assurance Activity has been covered in FIA_UAU.1.

5.13 FIA_USB.1 User-subject binding


The evaluator shall check to ensure that the TSS contains a description of rules for

associating security attributes with the users who succeed identification and

authentication, which is consistent with the definition of the SFR.

Section 6.1.1, in the [ST], it states that the TOE implements a role based access control

system. The users are System Administrator, Accounting Administrator, Non-Logged-In

and Logged-in user.

Their permissions and features that they have access based on their specific role.

Furthermore, it states that upon successful authentication, users are granted access based

on their role.


N/A

The [SAG], User Permissions Section (4) - Configuring Authorization Settings, provides

the description of the user’s roles

Furthermore, Users Roles Section, in the [SAG], provides the guidance on setting the

permissions based on user roles.


The evaluator shall also perform the following Testing Assurance Activity.

The evaluator shall check to ensure that security attributes defined in the SFR are

associated with the users who succeed identification and authentication (it is ensured in

the tests of FDP_ACF) for each role that the TOE supports (e.g., User and

Administrator).

As stated in FIA_USB.1 in the Test Report, not tested separately. This is tested as part of

FIA_UAU.1 by logging in as each type of user; administrator, supervisor, and normal user.

The test verifies that the only functions available to the identified user are those applicable

to the assigned role for the user identity.

5.14 FIA_PSK_EXT Extended: Pre-Shared Key Composition


The evaluator shall examine the TSS to ensure that it states that text-based pre-shared

keys of 22 characters are supported, and that the TSS states the conditioning that takes

place to transform the text-based pre-shared key from the key sequence entered by the

user (e.g., ASCII representation) to the bit string used by IPsec, and that this

conditioning is consistent with the first selection in the FIA_PSK_EXT.1.3 requirement.

If the assignment is used to specify conditioning, the evaluator will confirm that the TSS

describes this conditioning.

If “bit-based pre-shared keys” is selected, the evaluator shall confirm the operational

guidance contains instructions for either entering bit-based pre-shared keys for each

protocol identified in the requirement, or generating a bit-based pre-shared key (or

both). The evaluator shall also examine the TSS to ensure it describes the process by

which the bit-based pre-shared keys are generated (if the TOE supports this

functionality), and confirm that this process uses the RBG specified in

FCS_RBG_EXT.1.

Section 6.1.7, in the [ST], states that Pre-shared key is configurable with an ASCII text

string with range of 1 – 32 octets. This includes the construction of the 22-octet length pre-

shared key. The entry of the pre-shared key is masked so that onlookers will not see the

values, and the values cannot be displayed at any time. Moreover, it states that Pre-shared

key is initially conditioned using a SHA-1 or SHA-256 hash and then encrypted with AES

256 algorithm, and securely destroyed with overwrites on deletion or replacement.

The [ST], 5.2.34 states that bit based pre-shared keys is not selected.


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

guidance on the composition of strong text-based pre-shared keys, and (if the selection

indicates keys of various lengths can be entered) that it provides information on the

merits of shorter or longer pre-shared keys. The guidance must specify the allowable

characters for pre-shared keys, and that list must be a super-set of the list contained in

FIA_PSK_EXT.1.2.

The [SIG], Section IPsec, states that the pre-shared keys for IPsec are set by following the

instructions for “Creating a New Action.” Pre-shared keys can be between 1 and 32

characters in length. Furthermore, it states that the pre-shared keys follow the same rules

for creating strong passwords; i.e. uses a combination upper and lowercase letters and

digits.



1. The evaluator shall compose at least 15 pre-shared keys of 22 characters that cover

all allowed characters in various combinations that conform to the operational

guidance, and demonstrates that a successful protocol negotiation can be performed

with each key.

2. [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator

shall repeat Test 1 using the minimum length; the maximum length; and an invalid

length. The minimum and maximum length tests should be successful, and the invalid

length must be rejected by the TOE.

3. [conditional]: If the TOE supports bit-based pre-shared keys but does not generate

such keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length

and enter it according to the instructions in the operational guidance. The evaluator

shall then demonstrate that a successful protocol negotiation can be performed with the

key.

4. [conditional]: If the TOE supports bit-based pre-shared keys and does generate such

keys, the evaluator shall generate a bit-based pre-shared key of the appropriate length

and use it according to the instructions in the operational guidance. The evaluator shall

then demonstrate that a successful protocol negotiation can be performed with the key.

The test case in FIA_PSK_EXT in the test report demonstrates that the TOE has the ability

to use IPsec Preshared keys. The evaluator configured the TOE to require Preshared Key

IP action rule and to use the IKEv1 keying method. The IPsec transport mode was set to

Transport Mode with a SHA-1 hash. The test included examining the protocol connectivity.

5.15 FMT_MOF.1 Management of security functions behavior


The evaluator shall check to ensure that the TSS contains a description of the

management functions that the TOE provides as well as user roles that are permitted to

manage the functions, which is consistent with the definition of the SFR.

The evaluator shall check to ensure that the TSS identifies interfaces to operate the

management functions.

Section 6.1.4 of the [ST], describes the management functions listed in Table 13 and that

these functions are only usable by the System Administrator. Table 13 states that the

System Administrator could enable, disable, determine behavior or modify behavior,

which is consistent with the SFR. The Management Functions include, but are not limited

to, Enable/Disable/Determining Behavior of Immediate Image Overwrite, Smart Card Use,

and Disk Encryption.


The evaluator shall check to ensure that the administrator guidance describes the

operation methods for users of the given roles defined in the SFR to operate the


The [SAG] describes the operation methods for all the management functions and

privileges that are accessible to the system administrator (U. ADMIN). The system

administrator can enable, disable, determine behavior or modify behavior, of all

management features of the TOE, including all security features. (See table provided in

FMT_SMF.1).

The [SAG] contains instructions about management functions and privileges that are

restricted and identify those functions that are accessible to the privileged user.

The [UG] identifies the functionalities accessible to the normal user (U. NORMAL), and

includes notes and references to the System Administrator Guide for privileges functions

that are configurable or managed by the system administrator.



1. The evaluator shall check to ensure that users of the given roles defined in the SFR

can operate the management functions in accordance with the operation methods

specified in the administrator guidance.

2. The evaluator shall check to ensure that the operation results are appropriately

reflected.

3. The evaluator shall check to ensure that U. NORMAL is not permitted to operate the


The Test Report includes test case in Management of Security Function Behavior, which

tests the management capabilities provided and restricted by the FMT requirements defined

in the ST. The evaluator created multiple users and performed actions on the device to

verify that management of password policy, security functions, certificates, and of users

that are all restricted based on user roles.

5.16 FMT_MSA.1 Management of security attributes


The evaluator shall check to ensure that the TSS contains a description of possible

operations for security attributes and given roles to those securities attributes, which is

consistent with the definition of the SFR.

The [ST] (Section 6.1.4) states that the administrator during initial configuration of the

TOE must modify the configuration of access to the different types of jobs at the local user

interface. Initial values are initially permissive to unauthenticated users and the

administrator must set more restrictive access to prevent unauthenticated users to access.


The evaluator shall check to ensure that the administrator guidance contains a

description of possible operations for security attributes and given roles to those security

attributes, which is consistent with the definition of the SFR.

The evaluator shall check to ensure that the administrator guidance describes the timing

of modified security attributes.

The [SIG], page 2, states that System Administrator authentication is required when

accessing the security features and administrator functions of the device.

In the [SAG], page 94, it describes how to configure the user roles and permissions based

on their role. For example, in the [SAG], page 95, it describes how to allow users who

require the ability to send secure print jobs.




can perform operations to the security attributes in accordance with the operation

methods specified in the administrator guidance.


reflected as specified in the administrator guidance. 3. The evaluator shall check to

ensure that a user that is not part of an authorized role defined in the SFR is not

permitted to perform operations on the security attributes.

The test report contains a test case in FMT_MSA.1 that demonstrates that print, copy,

scan, fax and stored jobs cannot be modified by another user who did not create the job.

5.17 FMT_MSA.3 Static attribute initialization


The evaluator shall check to ensure that the TSS describes mechanisms to generate

security attributes which have properties of default values, which are defined in the SFR.

Section 6.1.4 of the [ST] it states that the administrator during initial configuration of the

TOE must modify the configuration of access to the different types of jobs at the local user

interface. Initial values are initially permissive to unauthenticated users and the

administrator must set more restrictive access to prevent unauthenticated users to access.


N/A


If U. ADMIN is selected, then testing of this SFR is performed in the tests of FDP_ACF.1.

As stated in MFT_MSA.3 this test is tested as part of the FDP_ACF.1, FDP_ACC.1, and

FMT_MSA.1. As jobs are created by users as noted by FDP_ACF.1, the jobs are restricted

to the users who created the job and administrators. Once a job is created, the attributes

cannot be modified as noted FMT_MSA.1 accept for document user lists for stored jobs

and fax in jobs.

5.18 FMT_MTD.1 Management of TSF data


N/A

Section 6.1.4 [ST] states that Table 12 specifies the management of TSF data and what

each role is permitted to do for the TSF data. Table 12 includes the user roles, the operations

that each role is permitted to do for the TSF data. Only the Security Administrator is

allowed to modify, query or delete TSF data.


The evaluator shall check to ensure that the administrator guidance identifies the

management operations and authorized roles consistent with the SFR.

The evaluator shall check to ensure that the administrator guidance describes how the

assignment of roles is managed.

The evaluator shall check to ensure that the administrator guidance describes how

security attributes are assigned and managed.

The evaluator shall check to ensure that the administrator guidance describes how the

security-related rules (. e.g., access control rules, timeout, number of consecutive logon

failures,) are configured.

It states in the [SIG], page 2, that System Administrator authentication is required when

accessing the security features and administrator functions of the device. Only the SA is

allowed to modify, query or delete TSF data

The [SAG] (page 80 Setting Access Rights) describes how to set up the access control to

apps and features of the TOE by configuring authentication, personalization and

authorization. The [SAG], Page 92, describes how to control access by configuring the

authorization settings for device. The User Permissions describes (page 93) how to restrict

access to copy, email, fax or settings on the Embedded Web server. The [SAG] (page.

127) describes how to configure the system timeout.

The [SIG] (Section III) states that the device has an automatic 5-minute lockout that will

disable the ability of anyone who enters three unsuccessful incorrect authentication

credentials at the local user interface or Web user interface. This lockout period is fixed

and cannot be altered.


The evaluator shall perform the following tests:


can perform operations to TSF data in accordance with the operation methods specified

in the administrator guidance.


reflected as specified in the administrator guidance.

3. The evaluator shall check to ensure that no users other than users of the given roles

defined in the SFR can perform operations to TSF data.

The Test Report includes test case in Management of TSF Data, which tests the

management capabilities of the security functions of the device. The tests verified that the

administrator could configure and determine behaviour of the security features of the TOE.

5.19 FMT_SMF.1 Specification of Management Functions


The evaluator shall check the TSS to ensure that the management functions are

consistent with the assignment in the SFR.

The [ST], Section 6.1.4, lists the management functions, which are consistent with the SFR.

It states that Table 13 describes the management functions permitted by the TOE. Below

is a sampling of the management functions in Table 13 of the [ST], which satisfies the SFR.

Management Functions Enable Disable Determine

Behavior

Modify

Behavior

Enable/disable Immediate Image

Overwrite (IIO)

X X X

Enable/disable and configure smart card

use

X X X

Configure users, roles, privileges and

passwords

X X X X

Configure network authentication X X X

Enable/disable Disk Encryption X X X


The evaluator shall check the guidance documents to ensure that management functions

are consistent with the assignment in the SFR, and that their operation is described.

The table below demonstrates that the [SIG]and the [SAG] describes the management

functions and operation descriptions, which are consistent with this SFR.

Management

Functions

Enable/Disable Determine Behavior Modify Behavior

Enable/disable

Immediate Image

Overwrite (IIO)

SAG (Pg. 130) Section

Enabling Immediate

Image Overwrite

describes the steps for

enablement.

SAG (Pg. 130) contains

instructions for determining

the status of the Immediate

Image Overwrite security

feature.

Enable/disable and

configure smart card use

SAG (Pg. 80) states to

use Smart Card

Authentication method

users must insert a pre-

programmed card reader

at control panel. Also, a

smart card reader must

be installed and

purchased.

SAG (Pg. 81) describes

how to set and enable the

login method to smart

SAG (Pg. 80-81) provides

instructions for understand

the settings for the smart

card reader.

Management

Functions


card. To enable, the

option of Smart Card

must be chosen.

Configure the Workflow

Scanning Repository

SAG (pg. 177) describes the

workflow scanning file

repository settings.

Manage receive fax

(job) passcodes


Fax Receive and how to

determine settings.

Configure WebUI and

LUI session timeout

SAG (pg. 127) describes

how to enable the

session timeout at LUI

and WebUI.


program session inactivity

time, which is the time

before the device logs a user

out of the touch screen due

to inactivity

SAG (pg. 127)

describes how to

modify the time in

which the device

logs a user out of

touch screen

(WebUI and LUI).

also, how to

display a warning

message to user.

Configure users, roles,

privileges and

passwords

SAG (pg. 83) states that

the user database stores

user credential

information

(passwords). (Pg. 83)

describes how to specify

password requirements.

SAG (Pg. 94) describes

how to create user roles.

SAG (Pgs. 94 -97)

describes how to set

privileges (permissions

).

SAG (pg. 83) the user

database stores user

credential information

(passwords).

SAG (Pg. 94) user roles to

see which roles and users

are set up.

SAG (Pgs. 94 -97)

privileges (permissions ).

SAG (Pg. 83)

describes how to

modify password

requirements.

SAG (pg. 90)

describes how you

can add or edit an

existing user.

Section

Authorization in

SIG states

to follow the same

instructions to

add/delete user

role, to change the

roles users are

assigned to or to

change what access

permissions each

role has

Configure network

authentication


how to configure

network authentication

SAG (pg. 84) network

authentication

You determine network

authentication for Kerberos,

SMB and for LDAP.

Enable/disable Disk

Encryption

SAG Stored Data

Encryption (pg.104) it

SIG (Section Data

Encryption) states that data

encryption is enabled by

Management

Functions


describes how to enable

the disk encryption.

default at the factory.

Before enabling make sure it

is not in diagnostic mode

and there are no active or

pending jobs.

Configure (specify the

IP address and/or IP

address range, port and

port range for remote

trusted IT products

(presumed) allowed to

connect to the TOE via

the network interface) IP

filtering

SIG (11. IP Filtering)


the IP filtering to create

IP filter rules by

following the

instructions provided in

Section 4 IP Filtering in

the SAG.


how to add an IP Filter,

set the IP address range,

and port range.

SIG (h.) warns to not

create an IP Filtering rule

that rejects incoming

traffic form all addresses

with source port set to

80; this will disable the

WebUI.

Also, to configure IP

filtering so that traffic to

open ports from external

users (specified by

subnet mask) is dropped

In addition, to ensure the

following ports are

closed; tcp 53202,

53303, 53404 and

tcp/udp port 3702.

Also, to ensure that the

entire access to the

device is not blocked by

defining a rule such as IP

address 0.0.0.0. with a

reject/drop action kept in

Position 1 in the list of IP

Filters.

SIG (11. IP Filtering)

describes how to determine

the IP Filtering rules which

are configured.

SIG (h.) provides additional

configuration IP Filtering

rules.

SAG (pg. 105) provides

instructions to configure the

IP Filtering rules, including

the port and port ranges.

SAG (pg. 105)

Provides the

instruction on

editing an IP Filter

Rule.

In addition, setting

the port and port

range.

Enable/disable and

configure IPsec

SAG (pg. 114) provides

instructions on how to

enable the IPsec function

SAG (pg. 115 – 118)

describes the setting

configurations, operations

and conditions to determine

the behavior.

SAG (pg. 115) how

to edit the protocol

groups (TCP) or

(UDP), configuring

manual keying

settings. Pgs. 116 -

Management

Functions


118 Configuring

Internet Key

Exchange,

Managing host

groups etc.

Enable/disable and

configure 802.1x

SIG (17. 802.1x Device

Authentication)


802.1x device

authentication.

SAG (pg. 125) detailed

instructions for enabling

802.1x device

authentication.

SIG (17. 802.1x Device

Authentication) describes

the 802.1x device

authentication and to

determine behavior.

SAG (pg. 125)

SIG (17. 802.1x

Device

Authentication)

describes how to

modify the 802.1x

device

authentication.

Create/upload/download

X.509 certificates


how to enable the X.509

certificates


how to find the key length

Enable/disable TLS There are specific

instructions on the

version to enable for

TLS in the SIG. Section

(e.) explains that the

when using in FIPS

mode the default TLS

1.x will bet

automatically set. In this

section, it is warned to

use TLS1.1 and TLS1.2.

Section (e.) and Section (8.)

Transport Layer Security

(TLS/Secure Sockets Layer

(SSL) in the SIG provide the

configuration settings for

TLS.

Configure email

addresses for audit

exhaustion warnings

SIG (pg.12) configure

alerts when audit log is

full.

SAG (pg. 232) set up e-

mail address to receive

alerts.

SAG (pg. 232) to

understand which e-mail

address is set to receive

alerts

Transfer the audit

records (if audit is

enabled) to a remote

trusted IT product

Section 12 – Audit Log

in SAG describes how to

enable audit log transfer

to a remote trusted

external IT product. It

must be supported by

SFTP protocol and only

be accessible to

authorized individuals.

Section Enabling the

Audit Log Transfer

(pg.107) describes how

to utilize SFTP and

enable protocol logs to

Section Enabling the Audit

Log Transfer (pg.107)

describes how to know if the

audit log transfer is to a

trusted remote IT product.

The path name, logon name

and password, as well as

SFTP and audit protocol

logs.

Management

Functions


ensure the secure audit

log transfer to a remote

Trusted IT product.

Configure SFTP In the SAG (pg. 47)


SFTP Filing.

In the SAG (pg. 47)

describes SFTP Filing and

whether it is enabled.

In the SAG (pg. 47)

it describes how to

modify SFTP

Filing

Enable/disable audit

function


how to enable the audit

log function.

SAG (pg. 107) Instructs

how to tell if Audit function

is enabled or disabled.

Create a recurrence

schedule for ODIO

SAG (pgs. 129 -130)


the schedule of routine

deletion of Image Data.

You can select daily,

weekly or monthly

image overwrites.

SAG (pgs. 129 -130)

describes how to know if the

On-Demand Image

Overwrite enabled and if so

is it configured to overwrite

daily, weekly or monthly.

Invoke ODIO SAG (pgs. 128 -130)


and invoke the On-

Demand Image

Overwrite.

Invoke data purge

function

SAG (pgs. 128 -130)


and invoke the On-

Demand Image

Overwrite.

Enable/disable USB

ports


how to enable/disable

the USB ports

Enable/disable and

configure fax

forwarding to email


how to enable the fax

forwarding by creating a

Fax Forward Rule.


how to understand the fax

forwarding by creating a

Fax Forward Rule.

Configure NTP SAG (pg. 64) describes

how to enable the NTP.

SAG (pg. 64) describes how

to understand the NTP

settings.

Configure SMTP over

TLS

SIG (pg. 9)

SAG (pg. 101)

SIG (pg. 9)

Enable/disable and

configure Enhanced

Device Security

SAG (pg. 111) McAfee

Enhanced Security level

is the default setting

SAG (pg. 111) McAfee

Enhanced Security level is

the default setting. Only set

the security level if

necessary. The options are

the default – Enhanced

Management

Functions


Device Security, Integrity

Control and Disabled.


N/A

Testing is for management functions is covered in FMT_MTD.1

5.20 FMT_SMR.1 Security roles


The evaluator shall check to ensure that the TSS contains a description of security

related roles that the TOE maintains, which is consistent with the definition of the SFR.

The [ST] (Section 6.1.4) states that the TOE maintains two roles; U.Normal and U.Admin.

Authenticated user roles and permissions can only be modified by a security administrator.

An authenticated user may only change their password. Access control rules for

authenticated users are assigned by the security administrator and can only be modified by

the security administrator. The roles that the TOE maintains are provided to satisfy this

SFR. Examples include that the System Administrator can enable/disable TLS, import

X509 certs and set IP filter rules.

Operational Guidance Activity

N/A

It states in the [SIG], page 2, that there are two roles U.ADMIN and U.NORMAL.


As for tests of this SFR, it is performed in the tests of FMT_MOF.1, FMT_MSA.1, and

FMT_MTD.1.

The Test Plan includes test cases in FMT_MOF.1, FMT_MSA.1 and FMT_MTD.1 to

satisfy this SFR test assurance activity.

5.21 FPT_KYP_EXT.1 Extended: Protection of Key and Key Material


The evaluator shall examine the Key Management Description (KMD) for a description

of the methods used to protect keys stored in nonvolatile memory. The evaluator shall

verify the KMD to ensure it describes the storage location of all keys and the protection

of all keys stored in nonvolatile memory.

It states in Section 10.1 (Hard Disk Key Storage) [KMD] that Atlantis writes/reads the hard

disk passphrase to/from the non-volatile BIOS memory on the device. Section 10.2 states

that since BIOS memory is not customer serviceable, the Common Criteria Certification

does not require it to have protection.

5.22 FPT_SKP_EXT.1 Extended: Protection of TSF Data


The evaluator shall examine the TSS to determine that it details how any pre-shared

keys, symmetric keys, and private keys are stored and that they are unable to be viewed

through an interface designed 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.

Section 6.1.5 of the [ST], states that all private and symmetric keys stored on the TOE

removable storage areas are encrypted by the AES 256 algorithm, either specifically, or as

a result of the hard drive partitions on which they reside being encrypted, or both. The TOE

does not allow the user, either of admin, or non-admin privileges, through any customer

provided interface to view, or obtain any pre-shared key, private key, or symmetric key.

5.23 FPT_STM.1 Reliable time stamps


The evaluator shall check to ensure that the TSS describes mechanisms that provide

reliable time stamps.

The TSS [ST] states in Section 6.1.2, that during initial device configuration the date and

time are set.

The TOE maintains the time and date to provide reliable time stamps.


The evaluator shall check to ensure that the guidance describes the method of setting the

time.

Section 2 – Initial Setup (Setting the Date and Time) of the [SAG] contains the instructions

for setting the time.



1. The evaluator shall check to ensure that the time is correctly set up in accordance

with the guidance or external network services (e.g., NTP).

2. The evaluator shall check to ensure that the time stamps are appropriately provided.

The Test Plan includes a test case that demonstrates the ability of the TOE to maintain the

correct time and date for audit log records.

The test included steps to modify the time and date of the TOE. The test steps then included

a series of events and then to verified the time and date of the MFP was consistent with the

changes made by the tester

5.24 FPT_TST_EXT.1 Extended: TSF testing


The evaluator shall examine the TSS to ensure that it details the self-tests that are run

by the TSF on start-up; 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). The evaluator shall ensure that

the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is

operating correctly.

Section 6.1.5 of the [ST], states that on invocation of the Mocana data encryption and IPsec

code a self-test is performed to ensure that the Mocana Crypto module has not been altered.

If altered, an error is indicated and the module aborts.

The McAfee embedded module test performs a startup test where if any whitelisted

executable has been modified by an extraneous method or non-updater, the device will

indicate an error and halt.

Furthermore, it states that on invocation of the Mocana data encryption and IPsec code a

self- test is performed to ensure that the Mocana crypto module has not been altered. If

altered, an error is indicated and the module aborts.


The evaluator shall also ensure that the operational guidance 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.

The [SAG], pg. 111, contains the instructions for configuring and setting the alerts for the

McAfee Embedded Control.

It states in the SIG (pg. 14) the possible errors that could occur and the resolutions that

should be taken. Included errors are the health failure check for the entropy sources, errors

with the failure of the encryption modules, and security alerts found in the McAfee

subsystem.


N/A

The Test Report includes test case in FPT_TST_EXT.1 that demonstrates the integrity of

the TOE security level.

The test performed verified that McAfee embedded control and the enhanced security

feature of the TOE.

5.25 FPT_TUD_EXT.1 Extended: Trusted Update


The evaluator shall check to ensure that the TSS contains a description of mechanisms

that verify software for update when performing updates, which is consistent with the


The evaluator shall check to ensure that the TSS identifies interfaces for administrators

to obtain the current version of the TOE as well as interfaces to perform updates.

Section 6.1.5 in the [ST], states that the Web UI provides the security administrator the

function to upgrade the software image. Moreover, the TSF performs an RSA 2048 with

SHA-256 signature verification of any software upgrade image. It also states that the TOE

provides a Web UI page that shows the Software Version, allows a print of the

Configuration Report which contains the Software Version and Local UI access to display

the Software Version.


The evaluator shall check to ensure that the administrator guidance contains

descriptions of the operation methods to obtain the TOE version as well as the operation

methods to start update processing, which are consistent with the description of the TSS.

The [SAG], in the Section labeled Software Upgrade, describes how to verify the software

version before and after upgrading. The instructions for the software upgrade are also

provided.



1. The evaluator shall check to ensure the current version of the TOE can be

appropriately obtained by means of the operation methods specified by the administrator

guidance.

2. The evaluator shall check to ensure that the verification of the data for updates of the

TOE succeeds using authorized data for updates by means of the operation methods

specified by the administrator guidance.

3. The evaluator shall check to ensure that only administrators can implement the

application for updates using authorized data for updates.

4. The evaluator shall check to ensure that the updates are correctly performed by

obtaining the current version of the TOE after the normal updates finish.

5. The evaluator shall check to ensure that the verification of the data for updates of the

TOE fails using unauthorized data for updates by means of the operation methods

specified by the administrator guidance. (The evaluator shall also check those cases

where hash verification mechanism and digital signature verification mechanism fail.)

The Test Report includes test case in Trusted Update. The test performed verified the

proper software version of the TOE that it is executing. Additionally, that upgrades can

execute successfully and ensure only administrators can execute the upgrade process.

Also, that the update fails with a bad upgrade file.

5.26 FTA_SSL.3 TSF-initiated termination


The evaluator shall check to ensure that the TSS describes the types of user sessions to

be terminated (e.g., user sessions via operation panel or Web interfaces) after a specified

period of user inactivity.

The [ST] (Section 6.1.1) describes the types of user sessions to be terminated after a

specified period of user inactivity. It states by default the local user interface will terminate

any session that has been inactive for 1 minute. The WebUI will terminate any session that

has been inactive for 60 minutes. The system administrator can configure both interface

session timeout periods.


The evaluator shall check to ensure that the guidance describes the default time interval

and, if it is settable, the method of setting the time intervals until the termination of the

session.

In the [SIG], Section Session Inactivity Timeout (14.), it states that the default session

timeout limits are 60 seconds for the Local User Interface and 60 minutes for the Web UI.

Section 4, System Timeout, of the [SAG], describes how to set the time interval of the

termination of the session due to inactivity.



1. If it is settable, the evaluator shall check to ensure that the time until the termination

of the session can be set up by the method of setting specified in the administrator

guidance.

2. The evaluator shall check to ensure that the session terminates after the specified time

interval.

3. The evaluator shall perform the tests 1 and 2 described above for all the user sessions

identified in the TSS.

The Test Report includes test case in FTA_SSL.3 that verifies that users are locked out of

TOE local user interface and Web user interface after a determined amount of time.

5.27 FTP_ITC.1 Inter-TSF trusted channel


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. The evaluator shall also

confirm that all protocols listed in the TSS are specified and included in the requirements

in the ST.

Section 6.1.7 [ST] states that the TOE supports the following secure communication

protocols: HTTPS/TLS for WebUI; TLS for document transfers to the remote file

depository; IPsec for communication over IPv4 and IPv6 and Kerberos and LDAP over

TLS for remote authentication.


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.

The [SIG], (8) Transport Layer Security (TLS)/Secure Sockets Layer (SSL), contains the

guidance for establishing allowed protocols. For example, it instructs to enable HTTPS by

following instructions for “Using SSL for all HTTPS” and to set the “Force Traffic over

SSL” option to “Yes”. It warns to disable SSLv3.0 in favor of TLSv1.x to avoid

vulnerabilities. When transferring the audit log to an IT product, it must support the SFTP

protocol.

The [SIG], page 15, states that should a connection between the device and another IT

product using one of the security protocols in the evaluated configuration be

unintentionally broken or terminated, in general the user does not have to take any action;

the connection will automatically be reestablished.

The only exception is that if the user is in the middle of a WebUI session and the HTTPS

connection is broken, HTTPS itself will automatically reconnect but the user will have to

reestablish the WebUI session between the browser being used and the WebUI to access

the device again.



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 operational guidance and ensuring that communication

is successful.

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.

3. The evaluator shall ensure, for each communication channel with an authorized IT

entity, the channel data are not sent in plaintext.

4. The evaluator shall ensure, 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.

Further assurance activities are associated with the specific protocols.

The Test Plan includes a test case in FTP_ITC.1 that demonstrates that TLS and SSH

protocols for the remote audit server.

Wireshark was used to observe the successful handshake between the TOE with the SSH

AES-128 CBC and HMAC SHA1 encryption.

5.28 FTP_TRP.1(a) Trusted path (for Administrators)


The evaluator shall examine the TSS to determine that the methods of remote TOE

administration are indicated, along with how those communications are protected. 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.

Section 6.1.7 [ST] states the TOE enforces communications over HTTPS for a secure

channel for administrators managing the TOE via the WebUI interface.

The communication channel is protected by the secure mechanisms of TLS.

The communication path is logically distinct from other communication paths and provides

assured identification of its end points and protection of the communicated data from

disclosure and detection of modification of the communicated data.



establishing the remote administrative sessions for each supported method.

The Authentication Section of the [SIG] instructs to establish network (remote)

authentication access to network accounts by following the “Configuring Network

Authentication Settings” instructions in Section 4 of the [SAG].

In the [SIG], Section Transport Layer Security, the detailed instructions are provided for

using TLS and HTTPS.



1. The evaluators shall ensure that communications using each specified (in the

operational guidance) remote administration method is tested during the course of the

evaluation, setting up the connections as described in the operational guidance and

ensuring that communication is successful.

2. For each method of remote administration supported, the evaluator shall follow the

operational guidance to ensure that there is no available interface that can be used by a

remote user to establish a remote administrative sessions without invoking the trusted

path.

3. The evaluator shall ensure, for each method of remote administration, the channel

data are not sent in plaintext. Further assurance activities are associated with the

specific protocols.

The Test Plan includes a test case in FTP_TRP (a) that demonstrates the HTTPS secure

communication via WebUI using the operational guidance in the [SIG] and [SAG].

Wireshark was used to observe the obfuscated data payloads using HTTPS over the

communication channel.

5.29 FTP_TRP.1(b) Trusted path (for Non-administrators)


The evaluator shall examine the TSS to determine that the methods of remote TOE access

for non-administrative users are indicated, along with how those communications are

protected.

The evaluator shall also confirm that all protocols listed in the TSS in support of remote

TOE access are consistent with those specified in the requirement, and are included in

the requirements in the ST.

It states in the [ST], Section 6.1.7, that for non-administrative TOE users the TOE uses

IPsec, TLS, and HTTPS to provide a trusted communications path. No other security

protocols are used.



establishing the remote user sessions for each supported method.

The [SIG], Section 8 (Transport Layer Security) provides the instructions for enabling the

HTTPS and using the secure version of TLS (TLS v1.x).

Section 13 of the [SIG], IPsec, provides the instructions for enabling and configuring IPsec.



1. The evaluators shall ensure that communications using each specified (in the

operational guidance) remote user access method is tested during the course of the

evaluation, setting up the connections as described in the operational guidance and

ensuring that communication is successful.

2. For each method of remote access supported, the evaluator shall follow the

operational guidance to ensure that there is no available interface that can be used by a

remote user to establish a remote user session without invoking the trusted path.

3. The evaluator shall ensure, for each method of remote user access, the channel data

are not sent in plaintext.

Further assurance activities are associated with the specific protocols.

The test plan includes a test case in FTP_TRP.1(b) that demonstrates the secure

communication using the operational guidance [SIG] and [SAG] using HTTPS.

Wireshark was used to verify that the packet data was obfuscated over the communication

channel.

6 SARs Assurance Activities for HCD_PP

6.1 ADV_FSP.1


The evaluator shall confirm identifiable external interfaces from guidance documents

and examine that TSS description identifies all the interfaces required for realizing SFR.

The evaluator shall confirm identification information of the TSFI associated with the

SFR described in the TSS and confirm the consistency with the description related to

each interface.

The evaluator shall check to ensure that the SFR defined in the ST is appropriately

realized, based on identification information of the TSFI in the TSS description as well

as on the information of purposes, methods of use, and parameters for each TSFI in the

guidance documents

The assurance activities specific to each SFR are described in Section 4, and also

applicable SFRs from Appendix B, Appendix C, and Appendix D, and the evaluator shall

perform evaluations by adding to this assurance component.

The TSS [ST] identifies the TOE external interfaces, the WebUI and external IT server for

utilizing the security features; audit log transfer, HTTPS LDAP, TLS, etc.

In addition, the LUI to display the software version.

The [SIG] and [SAG] confirms the identifiable external interfaces required for realizing

the SFR; WebUI and external IT server.

The SFRs defined in Section 5.2 of the ST are appropriate based on the TSFI descriptions

provided in the TSS, as well as the purposes, methods of use, and parameters for each TSFI

in the [SIG] and [SAG] for the TOE.

To demonstrate the table below is provided.

External Interfaces from Guidance Docs. to

Realize SFR

External Interface Descriptions in TSS Section to

Realize SFR

SIG (pg.4) Section 8 – Transport Layer Security FCS_HTTPS_EXT.1 (6.1.7) TOE can act as an

HTTPS client to connect to external servers using

HTTPS over TLS for LDAP and Kerberos

connections and the TOE acts as HTTPS Server for

browsers connections using HTTPS over TLS.

SIG (pg. 14) - Lockout Security

SAG (pg. 127)

FIA_AFL.1 WebUI Login (Lockout)

SIG (pg. 2) – Authentication (strong passwords)

SAG (pg. 83)

FIA_PMG_EXT.1- The valid character set for

setting up strong passwords for accounts

SIG (pg. 2) – Authentication

SAG (pg. 83)

FIA_ATD.1 TOE maintains username and

password.

SIG (pg3) – Authentication FIA_UAU.1, FIA_UID.1 -Web UI (browser based)

– uses a local information database for users


Realize SFR


Realize SFR

SAG (pg. 84) Network Authentication via an external

authentication service – uses LDAP, SMB,

Kerberos to identify and authenticate users

Smartcard Authentication – Smart Card pin

SIG (pg. 14) FIA_UAU.7 - When a user enters passwords at the

WebUI asterisks are displayed rather than the

entered character in order to obscure password

SIG (pg. 4) - Authorization FIA_USB.1 - The TOE implements a role based

access control system. The TOE ships with three

pre-configured roles; System Admin, Logged In

User, Accounting Admin. Plus, a fourth – Non-

Logged in User.

SIG (pg. 6) – Session Inactivity Timeout FTA_SSL.3 - By default, the Web UI will terminate

any session that has been inactive for 60 minutes.

SAG (pg. 106) Audit Log

SAG (pg. 282) Audit Log Events

FAU_GEN.1, FAU_GEN.2 - The TOE generates

audit logs, includes a timestamp. Table 9 audit

events.

SIG (pg. 5)


FAU_STG_EXT.1 - The TOE has the ability to be

transfer, or “push” the audit log file to a designated

file server in the IT environment.

SIG (pg. 5)


FAU_STG.1 - The audit log may be downloaded

from the MFP through the Web UI

SIG (pg. 5) Audit Log FAU_STG.4 - The TOE can store a maximum of

15,000 audit log entries. The TOE overwrites oldest

events first if the maximum is reached. When the

TOE reaches 13,500 entries (90% full) an email

warning is sent to a set of administrator defined

email addresses.

SAG (pg. 32) Setting Date and Time FPT_STM.1- During initial device configuration

the initial date and time are set. The TOE maintains

the date and time to provide reliable timestamps.

SAG (Authorization) (pg.92) FDP_ACC.1,

FDP_ACF.1 Users (U. NORMAL) require explicit

authorization from system administrators (U.

ADMIN (System Administrator)) to perform TOE

functions.

SIG (8-TLS) FTP_TRP.1(a) - The TOE enforces

communications over HTTPS for a secure channel

for administrators managing the TOE via the

WebUI interface.

See FMT_MOF.1 and FMT_SMF.1 Operational

Guidance table in Assurance Activity.

FMT_MOF.1,

FMT_SMF.1 the management functions permitted

by the TOE.


Realize SFR


Realize SFR

SAG (pg.92)

SIG – Authorization

FMT_MSA.1 – Copy (not included on LUI), Print,

Fax, Scan and their associated security features,

such as secure print.

See Table above in FMT_MTD Operational

Guidance Assurance Activity.

FMT_MSA.1, FMT_MTD.1,

FMT_SMR.1 - Table 12 specifies the management

of TSF data and what each role is permitted to do

for the TSF data.

SAG (pg.111) McAfee Integrity Control via

WebUI.

FPT_TST_EXT.1 - The McAfee embedded module

test performs a startup test. on OpenSSL invocation,

a self-test is performed to ensure that the OpenSSL

crypto module has not been altered. On invocation

of the Mocana data encryption and IPsec code a self-

test is performed to ensure that the Mocana crypto

module has not been altered. Before encryption can

be performed a Health Test is performed on entropy

SIG (pg. 10) Secure Acceptance of TOE by printing

configuration page via WebUI.

FPT_TUD_EXT.1 - The TOE provides a Web UI

page that shows the Software Version. The Web UI

provides a security administrator the function to

upgrade the software image.

SIG (pg. 5) TLS/SSL FTP_ITC.1 - HTTPS/TLS for Web UI; TLS for

document transfers to the remote file depository;

IPsec for communication over IPv4 and IPv6;

SMTP over TLS for email; and Kerberos and LDAP

over TLS for remote authentication.

SIG (pg. 4) TLS/SSL FTP_TRP.1(a) - HTTPS for a secure channel for

administrators managing the TOE via the WebUI

interface

SAG -IPsec (pg. 114), SIG (pg. 4) TLS/SSL FTP_TRP.1(b) -IPsec, TLS, and HTTPS

SIG (pg. 4) TLS/SSL FCS_HTTPS_EXT.1 - HTTPS for securing data

channels

SIG (pg. 5) IPsec

FCS_IPSEC_EXT.1 - IPsec Security Policy

Database (SPD) and allows configuration to

discard, bypass, and protect packets.

SIG (pg. 9) – Embedded Fax FDP_FXS_EXT.1

SAG, Security, Section 4(Overwriting Image Data) FDP_RIP.1(a) - Image overwrite security function

(using a three pass overwrite procedure consistent

with U.S. Department of Defense National

Industrial Security Program.

SIG, Section Erase Customer Data FDP_RIP.1(b) - Purge function is invoked manually

6.2 AGD_OPE.1


The contents of operational guidance are confirmed by the assurance activities in

Section 4, and applicable assurance activities in Appendix B, Appendix C, and Appendix

D, and the TOE evaluation in accordance with the CEM. The evaluator shall check to

ensure that the following guidance is provided: Procedures for administrators to

confirm that the TOE returns to its evaluation configuration after the transition from the

maintenance mode to the normal Operational Environment.

The [SIG], (q.) Section III, states that the device allows for the System Administrator to

disable functions, like the Image Overwrite Security feature, that are necessary for secure

operation. It is warned to periodically review the configuration of all installed machines

in your environment to verify that the proper evaluated configuration is maintained.

The [SIG] guidance there are specific sections; III – Secure Operation of Device

Services/Functions Part of the Evaluated Configuration and IV – Secure Operation of

Device Services/Functions Not Part of the Evaluated Configuration for the System

Administrator to understand the difference.

6.3 AGD_PRE.1


The evaluator shall check to ensure that the guidance provided for the TOE adequately

addresses all platforms claimed for the TOE in the ST.

The platforms claimed are the models; Xerox® AltaLink™

C8030/C8035/C8045/C8055/C8070 as identified in title page of both guidance documents

and the platforms in the [ST].

6.4 ALC_CMC.1


The evaluator shall check the ST to ensure that it contains an identifier (such as a

product name/version number) that specifically identifies the version that meets the

requirements of the ST. The evaluator shall ensure that this identifier is sufficient for an

acquisition entity to use in procuring the TOE (including the appropriate administrative

guidance) as specified in the ST. Further, the evaluator shall check the AGD guidance

and TOE samples received for testing to ensure that the version number is consistent

with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator

shall examine the information on the web site to ensure that the information in the ST is

sufficient to distinguish the product.

The evaluator checked the TOE made available for independent testing and ensures that it

includes the TOE name and version number and that these are consistent with the ST and

all guidance documents. The product name and version number is also consistent with the

vendor Website.

6.5 ALC_CMS.1


The “evaluation evidence required by the SARs” in this PP is limited to the information

in the ST coupled with the guidance provided to administrators and users under the AGD

requirements. By ensuring that the TOE is specifically identified and that this

identification is consistent in the ST and in the AGD guidance (as done in the assurance

activity for ALC_CMC.1), the evaluator implicitly confirms the information required by

this component.

Table 1 in the [ST], TOE identification and Table 3 in the [SAG] are consistent with the

actual documents and TOE.

It was confirmed that this information is consistent by printing out a configuration report

from the TOE and checking the documents to ensure the identification names, software

version numbers, dates were the same.

6.6 ATE_IND.1


The evaluator shall prepare a test plan and report documenting the testing aspects of

the system. The test plan covers all of the testing actions contained in the body of this

PP’s Assurance Activities. While it is not necessary to have one test case per test listed

in an Assurance Activity, the evaluators must document in the test plan that each

applicable testing requirement in the ST is covered.

The Test Plan identifies the product models to be tested, and for those product models

not included in the test plan but included in the ST, the test plan provides a justification

for not testing the models. This justification must address the differences between the

tested models and the untested models, 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. In case the ST describes multiple

models (product names) in particular, the evaluator shall consider the differences in

language specification as well as the influences, in which functions except security

functions such as a printing function, may affect security functions when creating this

justification. If all product models claimed in the ST are tested, then no rationale is

necessary.

The test plan describes the composition of each product model to be tested, and any

setup that is necessary beyond what is contained in the AGD documentation. It should

be noted that the evaluators are expected to follow the AGD documentation for

installation and setup of each model 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) is provided that the driver

or tool will not adversely affect the performance of the functionality by the TOE.

The test plan identifies high-level test objectives as well as the test procedures to be

followed to achieve those objectives. These procedures include the goal of the particular

procedure, the test steps used to achieve the goal, and the expected results. The test

report (which could just be an annotated 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; a fix installed; and then a successful re-run of the test, the report would show

a “fail” and “pass” result (and the supporting details), and not just the “pass” result.

The evaluator prepared a test plan and test report identifying each testing assurance

activity and mapping each to a test case; the test report identifies all aspect of the system

that was tested including the underlying platforms that the test ran on. All testing

configurations and testing tools are identified including a short description of the purpose

of each tool. Each test case description includes a test objective, test steps, expected test

results and actual test results. For each configuration. Where a test initially fails and

later is pass, the actual test results include both the fail and the pass results. The

evaluator following the installation guide and the CC-guide for installing and configuring

the TOE.

6.7 AVA_VAN.1


As with ATE_IND, the evaluator shall generate a report to document their findings with

respect to this requirement. This report could physically be part of the overall test report

mentioned in ATE_IND, or a separate document. The evaluator performs a search of

public information to determine the vulnerabilities that have been found in printing

devices and the implemented communication protocols in general, as well as those that

pertain to the particular TOE. The evaluator documents the sources consulted and the

vulnerabilities found in the report.

For each vulnerability found, the evaluator either provides a rationale with respect to

its non-applicability, or the evaluator formulates a test (using the guidelines provided in

ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing

the attack vector needed to take advantage of the vulnerability.

For example, if the vulnerability can be detected by pressing a key combination on boot-

up, for example, a test would be suitable at the assurance level of this PP. If exploiting

the vulnerability requires an electron microscope and liquid nitrogen, for instance, then

a test would not be suitable and an appropriate justification would be formulated.

The evaluator performed a search for vulnerabilities for the Xerox C8030, C8035, C8045,

C8055, C8070 product for vulnerabilities related to hard copy devices. The results of this

search can be found in the ETR in section AVA_VAN.1.2E.

7 Test Configuration

TOE Components

The TOE includes the following components:

Xerox MFP – AltaLink™ C8030 / C8035 / C8045 / C8055 / C8070 comprise the

whole TOE.

The evaluator ran the set of test cases on one TOE configuration corresponding to the TOE

supported environment described in the ST TOE Description. The AltaLink™ C8070 is

the model tested. The model tested is representative of all platforms included within the

scope of evaluation. All platforms run the same software/firmware build and processing

hardware. Differentiators between platforms consist of those hardware parts that generate

faster print speeds.

Customers gets a MFP delivered by a reputable delivery company directly from Xerox.

The TOE is installed per Security Installation Guide provided by Xerox.

Primary Test Environment

Email SMTP Test Environment

Specific environment for FTP_ITC.1 sending scan to email via TLS

Fax Separation Test Environment

Specifically used FDP_FXS.1 fax tests

Fax Testing Test Environment

Specifically used FDP_ACF.1 and FDP_DSK.1 tests related to faxes

IPSec RSA Certificate Environment

Environment for IPSec RSA certificates.

Smart Card Test Environment

Needed separate test set to use DoD issue CaC cards

LightShip on Kali Linux Test Environment

Environment set up with Kali Linux on Virtual machine to test TLS protocols and

SSH interruption test

IPSec Aggressive and Tunnel Mode Environment

Environment with GN3 virtual environment to run virtual router for IPSec Tunnel

and Aggressive modes

TOE Components

Xerox MFP – AltaLink™ C8070

Test Tools

Web Browsers

o IE version 11

o Google Chrome

o Mozilla Firefox

Notepad++ v7.4.2 (https://notepad-plus-plus.org/)

o Description: A free source code editor which supports several programming

languages running under the MS Windows environment.

o Testing Purpose: Used to modify Xerox DLM software upgrade files to create

a bad upgrade file.

https://notepad-plus-plus.org/

Wireshark v2.4.0(https://www.wireshark.org/#download)

o Description: A network analysis tool formerly known as Ethereal, captures

packets in real time and display them in human-readable format.

o Testing Purpose: Used to verify packets for network communications including

SSH, IPSec, and TLS.

WireEdit v1.10.118(https://omnipacket.com/downloads.html)

o Description: Used to edit a network packet at any stack layer from L2 to L7.

o Testing Purpose: Used to modify packets during network communications

including SSH, IPSec, and TLS.

Colasoft Packet Builder v2.0(http://www.colasoft.com/packet_builder/)

o Description: Enables creating custom network packets; users can use this tool

to check their network protection against attacks and intruders. Packet Builder

has a built-in sending packets feature, allows to send constructed packet to wire

directly without third part packet sending software.

o Testing Purpose: Used to replay modified packets during network

communications for IPSec.

Cerberus FTP server v8.0.12(https://www.cerberusftp.com/download/)

o Description: A commercially available solution to secure and reliable file

transfer solution.

o Testing Purpose: Used to modify what algorithms will be allowed in a SSH

connection and receive audit logs.

Hex Editor Neo (https://www.hhdsoftware.com/hex-editor)

o Description: A commercially available solution to view hex values of files.

o Testing purpose: Used to view files during disk encryption testing.

GNS3 (https://www.gns3.com/software)

o Description: GNS3 is used to design and build virtual networks.

o Testing Purpose: Used to verify aggressive and transport mode communication

for IPSec.

Lightship On-Premises Test utilities (https://lightshipsec.com/test-utilities)

o Description: Suite of certification test utilities that are commercially available

for all protocol suites..

o Testing Purpose: Used for TLS protocol testing and for SSH physical

interruption test.

hMail Server (https://www.hmailserver.com/download)

o Description: A free, open source, e-mail server for Microsoft Windows..

o Testing Purpose: Used for TLS interruption testing for FTP_ITC.1.

https://www.wireshark.org/#download

https://omnipacket.com/downloads.html

http://www.colasoft.com/packet_builder/

https://www.cerberusftp.com/download/

https://www.hhdsoftware.com/hex-editor

https://www.gns3.com/software

https://lightshipsec.com/test-utilities

https://www.hmailserver.com/download

Hyperterminal (https://www.hilgraeve.com/products/)

o Description: Enables communication with other computer systems, devices,

hardware, and pieces of equipment.

o Testing Purpose: Used for modem communications for FDP_FXS.1 testing.

Test Configuration

The TOE is connected to a hub, which, two Windows 7 machines, an Ubuntu machine,

and a Windows 2008 server machine is also connected.

The Windows 2008 Server functions as a Domain Controller, DNS Server, and File

Server and hosts an IIS server.

On the IIS server, the FTP service and certificate service are installed and enabled.

A share is created on the two Windows 7 machines for use by the TOE.

Set up in Evaluation Configuration

Use the Secure Installation and Operation User Guide to Set-up TOE in the Evaluated

Configuration.

Set up and configure TOE by using the following security protocols and functions in the

evaluated configuration by following the guidelines below to:

1. In General Set Up, print out a configuration report. Verify software version is the

same as the version in the ST.

2. In General Set up verify the time and date of TOE are correct. If not correct, then

change so date and time are current.

3. Very that the Immediate Image Overwrite is enabled. If not enabled, select enable.

4. Very that the On- Demand Image Overwrite is enabled. If not enabled, select

enable.

5. Very that Data Encryption is enabled. If it is not, select enable

6. Very that FIPS 140-2 Mode is enabled. If not enabled, perform the following steps;

i. Select the enabled button.

ii. Select the Run Configuration Check and Apply button.

iii. Select Change to 2048-bit button.

iv. In the next screen select the 2048 bit.

v. Select the Manage and Delete Certificates.

vi. Select 'Root/Intermediate Trusted Certificate(s)' tab.

vii. View and select the certificates that do not comply with the minimum key

length value of 2048. Now Click 'Delete Selected' button. Followed by [OK]

button to delete the selected certificates.

https://www.hilgraeve.com/products/

viii. Again, go to [Security] followed by [Encryption] → [FIPS 140-2]. Select

the [Enable] option and click [Run Configuration Check & Apply] button.

ix. Check the 'Enable non-FIPS 140-2 exception' option and click

'Acknowledge Kerberos Exception' button.

x. Select [Reboot Machine] button followed by [OK] button.

7. Verify that IP Filtering is enabled and IP Filtering (defaults to no rules defined).

8. Verify that Audit Log is enabled. If not enabled, select enable.

9. Enable HTTPS by performing the following steps;

i. From the properties menu, navigate to [Connectivity] → [Setup] →

[HTTP].

ii. Select the 'No (Requests can be made over HTTP and HTTPS)' option

button under 'Force Traffic over SSL' and then Click [Save].

iii. Select the 'Yes (All HTTP requests will be switched to HTTPS)' option

button under 'Force Traffic Over Secure Connection (HTTPS)' and ensure

the port number text box is set to 443, then click [Save].

iv. Log back into the TOE using HTTPS.

v. Select the 'Yes (All HTTP requests will be switched to HTTPS)' option

button under 'Force Traffic over Secure Connection (HTTPS)' and ensure

the port number text box is set to 443, then click [Save].

10. Ensure that TLS 1.1 is used on TOE by performing the following steps:

i. In Properties select Security>Encryption>TLS Encryption.

ii. Select TLS.1.1 and above.

iii. Apply to Save change.

11. Install a digital certificate on device by performing the following steps:

i. Click certificates and select Security Certificates.

ii. Select the Xerox Device Certificate tab

iii. Create a New Xerox Device Certificate

iv. Complete the requested form

v. Click Finish (may have to re logon and add exception)

12. Verify that IPsec is enabled. If not enabled, select enable.

13. Set Password Requirements. In Login/Permissions/Accounting go to Device User

Database and perform the following password requirement steps:

i. Select Password Settings tab

ii. Specify minimum of 8 characters and maximum length of 15

iii. Check Cannot contain Friendly Name, Contain User Name and Must

contain at least one number.

14. Set logon method. In Login/Permissions/Accounting go to Login Methods. Ensure

that Control Panel and Website Login methods are set to 'Validate on the Network'.

15. Create a User. In Login/Permissions/Accounting go to Device User Database and

perform the following Add New User steps:

i. Create a user name and friendly name

ii. Create password and retype password

iii. Save

16. Create User Permissions. In Login/Permissions/Accounting go to Device User

Database and Select permissions on user created and ensure Tools and Apps are

locked.

17. Ensure Session Inactivity Timeout is configured. In Security select Timeout &

Resume. For the User Interface System Timeout enter 6 minutes. For the Web

User Interface System Timeout enter 7 minutes.

18. TOE uses the primary LDAP server for authentication. No configuration is needed.

19. Enable 802.1x Device Authentication by performing the following steps:

i. Select [Connectivity], [Setup]. Click [Edit...] under Action for 'Wired

Connection'.

ii. Click 'Edit...' for 802.1x.

iii. Check the [Enable 802.1X] button. Set the Authentication Method to be

[EAP- TLS].

iv. Under "Server Validation - Validate server using" option, select the

uploaded Root Certificate.

v. Under "Device Certificate (TLS) - Authentication Certificate", Select the

Client Certificate which was approved by Certification Authority.

vi. Verify that it can authenticate and obtain network connectivity.

20. USB Port Security. (Both the front and rear USB Ports are enabled by default).

Ports can be disabled by unchecking boxes.

21. SFTP Filing (only for transfer of the audit log to an audit log server). Ensure SFTP

Filing (defaulted to passive mode).

22. Change admin password from 1111 to a secure password.