Document version: 1.0 November 2017

Transcription

1 For Xerox AltaLink C8030/C8035/C8045/C8055/C8070 Document version: 1.0 November 2017 Document prepared by

2 Table of Contents 1 Introduction Overview CC used for this evaluation Evaluation Documents SFRs Assurance Activities for HCD_PP FAU_GEN.1 Audit data generation FAU_GEN.2 User identity association FAU_STG.1 Protected audit trail storage FAU_STG.4 Prevention of audit data loss FAU_STG_EXT.1 Extended: External Audit Trail Storage FCS_CKM.1(a) Cryptographic Key Generation (for asymmetric keys) FCS_CKM.1(b) Cryptographic key generation (Symmetric Keys) FCS_CKM_EXT.4.1 Extended: Cryptographic key destruction FCS_CKM.4.1 Cryptographic Key Material Destruction FCS_COP.1(a) Cryptographic Operation (Symmetric encryption/decryption) FCS_COP.1(b) Crypt. Operation (for signature generation/verification) FCS_COP.1(d) Cryptographic operation (AES Data Encryption/Decryption) FCS_COP.1(g) Crypt. Operation (for keyed-hash message authentication) FCS_RBG_EXT.1 (a) Extended: Cryptographic Operation (Random Bit Generation) FCS_RBG_EXT.1 (b) Extended: Cryptographic Operation (Random Bit Generation) FCS_IPSEC_EXT.1 Extended: IPsec selected FCS_HTTPS_EXT.1 Extended: HTTPS selected FCS_TLS_EXT.1 Extended: TLS selected FCS_SSH_EXT.1 Extended: SSH selected FCS_KYC_EXT.1 Extended: Key Chaining FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based access control FDP_DSK_EXT.1 Extended: Protection of Data on Disk FDP_FXS_EXT.1 Extended: Fax separation FDP_RIP.1(a) Subset residual information protection FDP_RIP.1(b) Subset residual information protection... 59

3 5.7 FIA_AFL.1 Authentication failure handling FIA_ATD.1 User attribute definition FIA_PMG_EXT.1 Extended: Password Management FIA_UAU.1 Timing of authentication FIA_UAU.7 Protected authentication feedback FIA_UID.1 Timing of identification FIA_USB.1 User-subject binding FIA_PSK_EXT Extended: Pre-Shared Key Composition FMT_MOF.1 Management of security functions behavior FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialization FMT_MTD.1 Management of TSF data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FPT_KYP_EXT.1 Extended: Protection of Key and Key Material FPT_SKP_EXT.1 Extended: Protection of TSF Data FPT_STM.1 Reliable time stamps FPT_TST_EXT.1 Extended: TSF testing FPT_TUD_EXT.1 Extended: Trusted Update FTA_SSL.3 TSF-initiated termination FTP_ITC.1 Inter-TSF trusted channel FTP_TRP.1(a) Trusted path (for Administrators) FTP_TRP.1(b) Trusted path (for Non-administrators) SARs Assurance Activities for HCD_PP ADV_FSP AGD_OPE AGD_PRE ALC_CMC ALC_CMS ATE_IND AVA_VAN Test Configuration

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

5 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 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components September 2012 Version 3.1 Revision 4 Common Criteria for Information Technology Security Evaluation Part 3: 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

6 3 Evaluation Documents [ST] [SIG] Xerox Multi-Function Device Xerox AltaLink C8030/C8035/C8045/C8055/ C8070 Security Target, Version 0.21 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 SED Testing [TD0157] TD0157 FCS_IPSEC_EXT.1.1 Testing for SPDs [TD0219] TD0219 NIAP Endorsement of Errata for HCD PP v1.0 [KMD] [EAR] Xerox Key Management Description for Xerox Atlantis Multi-Function Device, Version 1.1 Xerox C8030/C8035/C8045/C8055/C8070 Entropy Assessment Report, Version 0.5

7 4 SFRs Assurance Activities for HCD_PP 4.1 FAU_GEN.1 Audit data generation 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 [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.

8 4.2 FAU_GEN.2 User identity association The Assurance Activities for FAU_GEN.1 address this SFR. Section [ST] states that the audit log tracks the user identification and authentication for the events/actions to logged in users.

9 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 [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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

10 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 [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 warning is sent to a set of administrator-defined addresses. If the audit log has not been cleared after 15,000 entries, subsequent warnings will be ed 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 definition of the SFR. Operational Guidance Assurance Activity 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 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 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 alerts to notify System Administrator. Testing Assurance Activity The evaluator shall also perform the following tests: 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 warning to the administrator when the audit log reaches 90% (13500 entries) and after entries thereafter. The test also verifies that the audit log was overwritten when it reached full capacity.

11 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 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 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 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 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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

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

13 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 A and/or B, depending on the selections made. This description shall indicate the sections in A and/or B 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 For the TOE-specific extensions in Section , 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, Operational Guidance Assurance Activity N/A The [PP] does not define Operational Guidance Assurance Activity for this SFR. Testing Assurance Activity The evaluator shall use the key pair generation portions of "The FIPS Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and The 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.

14 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 , 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

15 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 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. KMD Assurance Activity 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 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 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 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 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.

16 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. Testing Assurance Activity N/A

17 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 [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 [ST] also provides a list of the private keys or passphrases that are securely deleted when no longer needed for current or future use. Operational Guidance Assurance Activity N/A The [PP] defines no operational guidance assurance activity for this SFR. KMD Assurance Activity 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 (softwarebased key storage, BEVs, passwords, etc.) and its origin, storage location, and the method for destruction for each key.

18 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 Configuration Server Key Material - Disk Encryption Key Encryption Key - SSL/TLS key Key Origin Section in KMD (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. (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 Temporary Locations and Permanent Storage Location Section in KMD (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. (1.3.3) Mocana NanoSec Random. When NanoSEC computes keys it stores them in volatile memory. When Key Material Destroyed Section in KMD (2.4) Whenever the configuration server receives an update (Table 1.1) Atlantis Certificate Creation with RSA-Key Pair Key Destruction Procedure Section in KMD (2.4) The configuration server key material destruction description. Overwrite (Table 1.1) Atlantis Certificate Creation with RSA-Key Pair Overwrite

19 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 nonuser-serviceable BIOS/EFI memory. (10.4) Hard Disk Key Destruction. IPSEC Material - Ipsec key 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

20 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 Testing Assurance Activity 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.

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

22 4.10 FCS_COP.1(a) Cryptographic Operation (Symmetric encryption/decryption) : N/A The ST refers to the CMVP certificate number #2398 and CAVP AES certificate #3451. Operational Guidance Assurance Activity N/A The [PP] does not define Operational Guidance Assurance Activity for this SFR Testing Assurance Activity 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 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.

23 4.11 FCS_COP.1(b) Crypt. Operation (for signature generation/verification) Table 15 [ST] states the RSA Sig Gen/Ver CAVP RSA certificate #2690 is used for Signature generation/verification. Operational Guidance Assurance Activity N/A The [PP] does not define Operational Guidance Assurance Activity for this SFR Testing Assurance Activity 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.

24 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

25 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 bit keys, and the second set shall have 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 bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 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

26 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 nonzero 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.

27 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 (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.

28 4.13 FCS_COP.1(g) Crypt. Operation (for keyed-hash message authentication) : 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. Operational Guidance Assurance Activity N/A The [PP] does not define Operational Guidance Assurance Activity for this SFR Testing Assurance Activity 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. No actual testing was required, covered under Mocana CMVP certificate number #2859 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.

29 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). Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

30 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. No actual testing was required, covered under Mocana CMVP certificate number #2859 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 (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.

31 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). Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

32 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. No actual testing was required, covered under Mocana CMVP certificate number #2859 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 (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.

33 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 As noted in section 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. Operational Guidance Assurance Activity 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

34 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. Testing Assurance Activity 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).

35 It states [ST], Section 6.1.7, that both transport and tunnel mode are supported and are configuration options when configuring IPsec. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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 [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.

36 By default, any packet that does not fit any user defined security policy will be dropped (DISCARD). Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

37 Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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 of the [ST] states that IKEv1 is implemented. Operational Guidance Assurance Activity 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 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

38 specified, and if others are chosen in the selection of the requirement, those are included in the TSS discussion. In Section [ST] states the encryption algorithms supported are AES 128 and AES 256 when AES is selected as the encryption algorithm. Operational Guidance Assurance Activity 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 [ST] states that IKEv1 is implemented, with main mode being used in IKEv1 and no use of aggressive mode implemented. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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

39 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity Each of the following tests shall be performed for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection:

40 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 [ST] states that DH Groups 14 (2048-bit MODP) and 2 (1024-MODP) are configurable. Testing Assurance Activity 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 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.

41 The key that was used to encrypt with AES 256 is encrypted itself by use of a RSA bit private key. Testing Assurance Activity The evaluator shall also perform the following test: 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.

42 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 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. Operational Guidance Assurance Activity 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 Assurance Activity 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.

43 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 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_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_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_DHE_RSA_WITH_AES_256_CBC_ SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384] Operational Guidance Assurance Activity 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.

44 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_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_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_DHE_RSA_WITH_AES_256_CBC_ SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 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. Testing Assurance Activity 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

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

46 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). Testing Assurance Activity The evaluator shall also perform the following tests: 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 Testing Assurance Activity 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.

47 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 [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. Testing Assurance Activity The evaluator shall also perform the following test: 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 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

48 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 of the [ST]. It states in the [SIG] (pg. 7) that for SFTP the underlying SSH encryption algorithm (which SFTP uses) cannot be configured. Testing Assurance Activity The evaluator shall also perform the following test: 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. The Test Plan includes a test case in FCS_SSH_EXT.1.6 that demonstrates the SSH connection used for SSH2 encryption algorithm during the audit log transfer to the 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 Operational Guidance Assurance Activity 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 SFTP uses) cannot be configured. Stated in Section [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. Testing Assurance Activity The evaluator shall also perform the following test: 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. The Test Plan includes a test case in FCS_SSH_EXT.1.7 that demonstrates the SSH connection used for SSH2 encryption algorithm during the audit log transfer to the Cerberus Server.

49 Wireshark was used to observe the packets which proved that the TOE SSH2 Diffie- Hellman-group14-SHA1 authentication encryption 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 [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. KMD Assurance Activity 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.

50 5.1 FDP_ACC.1 Subset access control No separate assurance activity, refer to FDP_ACF.1.

51 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 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]. Operational Guidance Assurance Activity The evaluator shall check to ensure that the operational guidance contains a description 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 . 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. Testing Assurance Activity 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:

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

53 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]. Operational Guidance Assurance Activity 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. KMD Assurance Activity 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

54 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. Testing Assurance Activity 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.

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

56 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 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 ) 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 attachment and sent out through the network interface Operational Guidance Assurance Activity The evaluator shall check to ensure that the operational guidance contains a description 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. Testing Assurance Activity 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:

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

58 5.5 FDP_RIP.1(a) Subset residual information protection The evaluator shall examine the TSS to ensure that the description is comprehensive in 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. Operational Guidance Assurance Activity 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). Testing Assurance Activity 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.

59 5.6 FDP_RIP.1(b) Subset residual information protection The evaluator shall examine the TSS to ensure that the description is comprehensive in 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). Operational Guidance Assurance Activity 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]. Testing Assurance Activity 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.

60 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 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

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

62 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 definition of the SFR. Section 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. Operational Guidance Assurance Activity 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].

63 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 set and Unicode/UTF-8 set, #, $, %, ^, &, *, (, ), but not allowing the > character. Operational Guidance Assurance Activity 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 set and Unicode/UTF-8 set characters except >, and not to use common names or phrases etc. to ensure a strong password. Testing Assurance Activity 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.

64 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 definition of the SFR. 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 . The only operation permitted prior to successful identification and authentication is job requests can be received via printing protocols Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 1. The evaluator shall check to ensure that identification and authentication succeeds, enabling the access to the TOE when using authorized data.

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

66 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. Operational Guidance Assurance Activity N/A It states in the SIG (pg. 14) that all passwords on the (UI and WebUI) Control panel will obfuscated. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

67 5.12 FIA_UID.1 Timing of identification It is covered by assurance activities for FIA_UAU.1. The has been covered in FIA_UAU.1.

68 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

69 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 preshared 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], states that bit based pre-shared keys is not selected. Operational Guidance Assurance Activity 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 lower- case letters and digits. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

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

71 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 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. Operational Guidance Assurance Activity 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 management functions. 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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 management functions. 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

72 verify that management of password policy, security functions, certificates, and of users that are all restricted based on user roles.

73 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 1. The evaluator shall check to ensure that users of the given roles defined in the SFR can perform operations to the security attributes 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 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.

74 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 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. Operational Guidance Assurance Activity N/A Testing Assurance Activity 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.

75 5.18 FMT_MTD.1 Management of TSF data N/A Section [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. Operational Guidance Assurance Activity 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, , 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. Testing Assurance Activity The evaluator shall perform the following tests: 1. The evaluator shall check to ensure that users of the given roles defined in the SFR can perform operations to TSF data 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 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.

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

77 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) Enable/disable and configure smart card use X X X 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 Operational Guidance Assurance Activity 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 Immediate Overwrite (IIO) Image Enable/disable and configure smart card use Enable/Disable Determine Behavior Modify Behavior SAG (Pg. 130) Section Enabling Immediate Image Overwrite describes the steps for enablement. SAG (Pg. 80) states to use Smart Card Authentication method users must insert a preprogrammed 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. 130) contains instructions for determining the status of the Immediate Image Overwrite security feature. SAG (Pg ) provides instructions for understand the settings for the smart card reader.

78 Management Functions Configure the Workflow Scanning Repository Manage receive fax (job) passcodes Configure WebUI and LUI session timeout Configure users, roles, privileges and passwords Configure authentication Enable/disable Encryption network Disk Enable/Disable Determine Behavior Modify Behavior card. To enable, the option of Smart Card must be chosen. SAG (pg. 127) describes how to enable the session timeout at LUI and WebUI. 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 ) describes how to set privileges (permissions ). SAG (pg. 84) describes how to configure network authentication SAG Stored Data Encryption (pg.104) it SAG (pg. 177) describes the workflow scanning file repository settings. SAG (pg. 196) describes the Fax Receive and how to determine settings. SAG (pg. 127) describes the program session inactivity time, which is the time before the device logs a user out of the touch screen due to inactivity 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 ) privileges (permissions ). SAG (pg. 84) network authentication You determine network authentication for Kerberos, SMB and for LDAP. SIG (Section Data Encryption) states that data encryption is enabled by 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. SAG (Pg. 83) describes how to modify password requirements. SAG (pg. 90) describes how you can add or edit an existing user. Section Authorization SIG states in 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

79 Management Functions 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 Enable/disable configure IPsec and Enable/Disable Determine Behavior Modify Behavior describes how to enable the disk encryption. SIG (11. IP Filtering) describes how to enable the IP filtering to create IP filter rules by following the instructions provided in Section 4 IP Filtering in the SAG. SAG (pg. 105) describes 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, and tcp/udp port Also, to ensure that the entire access to the device is not blocked by defining a rule such as IP address with a reject/drop action kept in Position 1 in the list of IP Filters. SAG (pg. 114) provides instructions on how to enable the IPsec function default at the factory. Before enabling make sure it is not in diagnostic mode and there are no active or pending jobs. 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 ) describes the setting configurations, operations and conditions to determine the behavior. SAG (pg. 105) Provides the instruction on editing an IP Filter Rule. In addition, setting the port and port range. SAG (pg. 115) how to edit the protocol groups (TCP) or (UDP), configuring manual keying settings. Pgs

80 Management Functions Enable/disable configure 802.1x and Create/upload/download X.509 certificates Enable/Disable Determine Behavior Modify Behavior SIG ( x Device Authentication) describes how to enable 802.1x device authentication. SAG (pg. 125) detailed instructions for enabling 802.1x device authentication. SAG (pg. 123) describes how to enable the X.509 certificates 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. Configure addresses for audit exhaustion warnings Transfer the audit records (if audit is enabled) to a remote trusted IT product SIG (pg.12) configure alerts when audit log is full. SAG (pg. 232) set up e- mail address to receive alerts. 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 SIG ( x Device Authentication) describes the 802.1x device authentication and to determine behavior. SAG (pg. 125) SAG (pg. 123) describes how to find the key length Section (e.) and Section (8.) Transport Layer Security (TLS/Secure Sockets Layer (SSL) in the SIG provide the configuration settings for TLS. SAG (pg. 232) to understand which address is set to receive alerts 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. 118 Configuring Internet Key Exchange, Managing host groups etc. SIG ( x Device Authentication) describes how to modify the 802.1x device authentication.

81 Management Functions Enable/Disable Determine Behavior Modify Behavior ensure the secure audit log transfer to a remote Trusted IT product. Configure SFTP In the SAG (pg. 47) describes how to enable SFTP Filing. Enable/disable function audit Create a recurrence schedule for ODIO SAG (pg. 107) describes how to enable the audit log function. SAG (pgs ) describes how to enable the schedule of routine deletion of Image Data. You can select daily, weekly or monthly image overwrites. Invoke ODIO SAG (pgs ) describes how to enable and invoke the On- Demand Image Overwrite. Invoke data purge function Enable/disable ports USB Enable/disable and configure fax forwarding to Configure NTP Configure SMTP over TLS Enable/disable and configure Enhanced Device Security SAG (pgs ) describes how to enable and invoke the On- Demand Image Overwrite. SAG (pg. 132) describes how to enable/disable the USB ports SAG (pg. 199) describes how to enable the fax forwarding by creating a Fax Forward Rule. SAG (pg. 64) describes how to enable the NTP. SIG (pg. 9) SAG (pg. 101) SAG (pg. 111) McAfee Enhanced Security level is the default setting In the SAG (pg. 47) describes SFTP Filing and whether it is enabled. SAG (pg. 107) Instructs how to tell if Audit function is enabled or disabled. SAG (pgs ) describes how to know if the On-Demand Image Overwrite enabled and if so is it configured to overwrite daily, weekly or monthly. SAG (pg. 199) describes how to understand the fax forwarding by creating a Fax Forward Rule. SAG (pg. 64) describes how to understand the NTP settings. SIG (pg. 9) SAG (pg. 111) McAfee Enhanced Security level is the default setting. Only set the security level if necessary. The options are the default Enhanced In the SAG (pg. 47) it describes how to modify SFTP Filing

82 Management Functions Testing Assurance Activity N/A Enable/Disable Determine Behavior Modify Behavior Device Security, Integrity Control and Disabled. Testing is for management functions is covered in FMT_MTD.1

83 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. Testing Assurance Activity 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.

84 5.21 FPT_KYP_EXT.1 Extended: Protection of Key and Key Material KMD Assurance Activity 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.

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

86 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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

87 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 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity 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.

88 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 definition of the SFR. 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 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.)

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

90 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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

91 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 [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. Operational Guidance Assurance Activity 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

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

93 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 [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. Operational Guidance Assurance Activity The evaluator shall confirm that the operational guidance contains instructions for 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

94 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. Operational Guidance Assurance Activity The evaluator shall confirm that the operational guidance contains instructions for 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. Testing Assurance Activity The evaluator shall also perform the following tests: 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.

95 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 SIG (pg.4) Section 8 Transport Layer Security SIG (pg. 14) - Lockout Security SAG (pg. 127) SIG (pg. 2) Authentication (strong passwords) SAG (pg. 83) SIG (pg. 2) Authentication SAG (pg. 83) SIG (pg3) Authentication External Interface Descriptions in TSS Section to Realize SFR 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. FIA_AFL.1 WebUI Login (Lockout) FIA_PMG_EXT.1- The valid character set for setting up strong passwords for accounts FIA_ATD.1 TOE maintains username and password. FIA_UAU.1, FIA_UID.1 -Web UI (browser based) uses a local information database for users

96 External Interfaces from Guidance Docs. to Realize SFR External Interface Descriptions in TSS Section to Realize SFR SAG (pg. 84) Network Authentication via an external authentication service uses LDAP, SMB, Kerberos to identify and authenticate users SIG (pg. 14) SIG (pg. 4) - Authorization SIG (pg. 6) Session Inactivity Timeout SAG (pg. 106) Audit Log SAG (pg. 282) Audit Log Events SIG (pg. 5) SAG (pg. 106) Audit Log SIG (pg. 5) SAG (pg. 106) Audit Log SIG (pg. 5) Audit Log SAG (pg. 32) Setting Date and Time SAG (Authorization) (pg.92) Smartcard Authentication Smart Card pin FIA_UAU.7 - When a user enters passwords at the WebUI asterisks are displayed rather than the entered character in order to obscure password 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. FTA_SSL.3 - By default, the Web UI will terminate any session that has been inactive for 60 minutes. FAU_GEN.1, FAU_GEN.2 - The TOE generates audit logs, includes a timestamp. Table 9 audit events. 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. FAU_STG.1 - The audit log may be downloaded from the MFP through the Web UI 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 warning is sent to a set of administrator defined addresses. 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. 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.

97 External Interfaces from Guidance Docs. to Realize SFR SAG (pg.92) SIG Authorization See Table above in FMT_MTD Operational Guidance Assurance Activity. SAG (pg.111) McAfee Integrity Control via WebUI. SIG (pg. 10) Secure Acceptance of TOE by printing configuration page via WebUI. SIG (pg. 5) TLS/SSL SIG (pg. 4) TLS/SSL SAG -IPsec (pg. 114), SIG (pg. 4) TLS/SSL SIG (pg. 4) TLS/SSL External Interface Descriptions in TSS Section to Realize SFR FMT_MSA.1 Copy (not included on LUI), Print, Fax, Scan and their associated security features, such as secure print. 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. 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 selftest 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 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. 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 ; and Kerberos and LDAP over TLS for remote authentication. FTP_TRP.1(a) - HTTPS for a secure channel for administrators managing the TOE via the WebUI interface FTP_TRP.1(b) -IPsec, TLS, and HTTPS 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 SAG, Security, Section 4(Overwriting Image Data) SIG, Section Erase Customer Data FDP_FXS_EXT.1 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. FDP_RIP.1(b) - Purge function is invoked manually

98 6.2 AGD_OPE.1 Operational Guidance Assurance Activity 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.

99 6.3 AGD_PRE.1 Operational Guidance Assurance Activity 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].

100 6.4 ALC_CMC.1 Operational Guidance Assurance Activity 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.

101 6.5 ALC_CMS.1 Operational Guidance Assurance Activity 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.

102 6.6 ATE_IND.1 Testing Assurance Activity 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.

103 6.7 AVA_VAN.1 Testing Assurance Activity 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 bootup, 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.

104 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