Assurance Activity Report (ASPP11/ASFEEP10) for · PDF fileAssurance Activity Report...

Document: AAR-VID10651 © 2015 Gossamer Security Solutions, Inc. All rights reserved.

www.GossamerSec.com

Assurance Activity Report (ASPP11/ASFEEP10) for CRC

Data at Rest Service (Native) Version 1.0.0 (Version Code 2)

Version 0.4

October 29, 2015

Prepared by: Gossamer Security Solutions

Accredited Security Testing Laboratory – Common Criteria Testing Catonsville, MD 21228

Prepared for: National Information Assurance Partnership

Common Criteria Evaluation and Validation Scheme

Version 0.4, October 21, 2015

GSS CCT Assurance Activity Report of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.

REVISION HISTORY

Revision Date Authors Summary

0.1 09/02/2015 Haley/Compton Initial draft

0.2 10/16/2015 Haley Validation comments

0.3 10/21/2015 Haley/Compton Validation comments

0.4 10/29/2015 Compton Validation comments

The TOE Evaluation was Sponsored by: CyberReliant Corporation 175 Admiral Cochrane Drive Suite 404 Annapolis. MD 21401

Evaluation Personnel:

Tammy Compton

Chris Keenan

Cornelius Haley Common Criteria Versions:

Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September 2012

Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012

Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012

Common Evaluation Methodology Versions:

Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012



TABLE OF CONTENTS

1. Introduction ........................................................................................................................................................... 5

1.1 References.................................................................................................................................................... 5

1.2 Equivalence .................................................................................................................................................. 5

2. Protection Profile SFR Assurance Activities ........................................................................................................... 7

2.1 Cryptographic support (FCS) ........................................................................................................................ 7

2.1.1 Cryptographic key generation (Password/Passphrase conditioning) (FCS_CKM_EXT.1(A)) ................... 7

2.1.2 Key Encrypting Key (KEK) Support (FCS_CKM_EXT.1) ............................................................................. 9

2.1.3 Cryptographic key generation (FEK) (FCS_CKM_EXT.2) ........................................................................ 12

2.1.4 Extended: Cryptographic Key Destruction (FCS_CKM_EXT.4) .............................................................. 14

2.1.5 Cryptographic operation (Data Encryption) (FCS_COP.1(1)) ................................................................ 16

2.1.6 Cryptographic Operation (Keyed-Hash Message Authentication) (FCS_COP.1(4)) .............................. 19

2.1.7 Cryptographic operation (Key Wrapping) (FCS_COP.1(5)) .................................................................... 20

2.1.8 Extended: Initialization Vector Generation (FCS_IV_EXT.1) ................................................................. 22

2.1.9 Key Chaining and Key Storage (FCS_KYC_EXT.1) .................................................................................. 23

2.1.10 Random Bit Generation Services (FCS_RBG_EXT.1) .............................................................................. 24

2.1.11 Storage of Secrets (FCS_STO_EXT.1) ..................................................................................................... 26

2.2 User data protection (FDP) ........................................................................................................................ 27

2.2.1 Encryption Of Sensitive Application Data (FDP_DAR_EXT.1) ................................................................ 28

2.2.2 Access to Platform Resources (FDP_DEC_EXT.1) .................................................................................. 29

2.2.3 Extended: Protection of Selected User Data (FDP_PRT_EXT.1) ............................................................ 33

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

2.3.1 User Authorization (FIA_AUT_EXT.1) .................................................................................................... 36

2.3.2 Extended: User Authorization with External Entity Authorization Factors (FIA_FCT_EXT.1(1)) ........... 37

2.4 Security management (FMT) ...................................................................................................................... 39

2.4.1 Secure by Default Configuration (FMT_CFG_EXT.1) ............................................................................. 40

2.4.2 Supported Configuration Mechanism (FMT_MEC_EXT.1) .................................................................... 41

2.4.3 Specification of Management Functions (FMT_SMF.1) ....................................................................... 43

2.5 Protection of the TSF (FPT) ........................................................................................................................ 44

2.5.1 AntiExploitation Capabilities (FPT_AEX_EXT.1)..................................................................................... 44



2.5.2 Use of Supported Services and APIs (FPT_API_EXT.1) .......................................................................... 49

2.5.3 File Encryption Key (FEK) Support (FPT_FEK_EXT.1) ............................................................................. 49

2.5.4 Extended: Protection of Key and Key Material (FPT_KYP_EXT) (FPT_KYP_EXT.1) ................................ 50

2.5.5 Use of Third Party Libraries (FPT_LIB_EXT.1) ........................................................................................ 51

2.5.6 Integrity for Installation and Update (FPT_TUD_EXT.1) ....................................................................... 51

2.6 Trusted path/channels (FTP) ...................................................................................................................... 54

2.6.1 Protection of Data in Transit (FTP_DIT_EXT.1) ..................................................................................... 54

3. Protection Profile SAR Assurance Activities ........................................................................................................ 56

3.1 Development (ADV) ................................................................................................................................... 56

3.1.1 Basic functional specification (ADV_FSP.1) ........................................................................................... 56

3.2 Guidance documents (AGD) ....................................................................................................................... 56

3.2.1 Operational user guidance (AGD_OPE.1).............................................................................................. 56

3.2.2 Preparative procedures (AGD_PRE.1) ................................................................................................... 57

3.3 Life-cycle support (ALC) .............................................................................................................................. 57

3.3.1 Labelling of the TOE (ALC_CMC.1) ........................................................................................................ 57

3.3.2 TOE CM coverage (ALC_CMS.1) ............................................................................................................ 57

3.3.3 Timely Security Updates (ALC_TSU_EXT.1) ........................................................................................... 58

3.4 Tests (ATE) .................................................................................................................................................. 58

3.4.1 Independent testing - conformance (ATE_IND.1) ................................................................................. 59

3.5 Vulnerability assessment (AVA) ................................................................................................................. 60

3.5.1 Vulnerability survey (AVA_VAN.1) ........................................................................................................ 60



1. INTRODUCTION

This document presents evaluations results of the CyberReliant Corp DaR Service (Native) ASPP11/ASFEEP10

evaluation. This document contains a description of the assurance activities and associated results as performed

by the evaluators.

1.1 REFERENCES

The following guidance documentation included material used to satisfy the Guidance assurance activities.

[ST] CyberReliant Corp. Data at Rest (DaR) Service (Native) (ASPP11/FEEP10) Security Target, Version

0.6, October 21, 2015.

[OM] CyberReliant Operations & Maintenance Manual Data at Rest (DaR), Version 1.0.2, October 27,

2015.

[ASPP11] Protection Profile for Application Software, Version: 1.1, 5 November 2014.

[FEEP10] Application Software Protection Profile Extended Package: File Encryption. Version 1.0,

11/10/2014.

1.2 EQUIVALENCE

This section presents the test environment and explains why the test subset was adequate to address all product

installations.

The Target of Evaluation (TOE) is CyberReliant Corporation’s (CRC) Data at Rest (DaR) Service (Native) Version 1.0.0

(Version Code 2) software application package residing on evaluated mobile devices running Android 4.4. The TOE

is a software solution providing the capability to handle file encryption on mobile devices. The TOE is tested on a

Samsung Galaxy Note 3. Below are the current evaluated platforms:

Samsung Galaxy S4, Note 3 and NotePRO tablet

Samsung Galaxy S5 & Note 10.1 2014 Edition

LG G3 Smartphone

Samsung Galaxy Note 4, Note Edge, Galaxy Alpha, Galaxy Tab S 8.4 LTE & 10.5 LTE

Samsung Galaxy S5 with KNOX 2

Samsung Galaxy Note 4, Note Edge, Alpha, Galaxy Tab S 8.4 LTE & 10.5 LTE, Galaxy Tab Active with KNOX 2

Samsung Galaxy Note Edge & Galaxy Tab Active



The TOE uses the Bouncy Castle keystore on the platform. For purposes of evaluation, the Bouncy Castle keystore

can be thought of as a flat filesystem. The added protections are minimal. When the TOE stores keys in the

Bouncy Castle keystore, those keys are encrypted. The encryption used is that from the CAVP certified algorithms

on the platform (not Bouncy Castle).



2. PROTECTION PROFILE SFR ASSURANCE ACTIVITIES

This section of the AAR identifies each of the assurance activities included in the claimed Protection Profile and

Extended Packages. This section also describes the findings for each activity.

The evidence identified in Section 1.1, References, was used to perform these Assurance Activities.

2.1 CRYPTOGRAPHIC SUPPORT (FCS)

2.1.1 CRYPTOGRAPHIC KEY GENERATION (PASSWORD/PASSPHRASE CONDITIONING)

(FCS_CKM_EXT.1(A))

2.1.1.1 FCS_CKM_EXT.1(A).1

TSS Assurance Activities: FCS_CKM_EXT.1.1(A): There are two aspects of this component that require evaluation:

passwords/passphrases of the length specified in the requirement (at least 64 characters) are supported, and that

the characters that are input are subject to the selected conditioning function. These activities are separately

addressed in the text below.

Support for minimum length: The evaluators shall check the TSS section to determine that it specifies that a

capability exists to accept passwords/passphrases with the minimum number of characters specified in the ST in

this assignment statement.

Support for Password/Passphrase length: The evaluators shall check to ensure that the TSS describes the allowable

ranges for password/passphrase lengths, and that at least 64 characters may be specified by the user.

Support for PBKDF: The evaluator shall examine the password hierarchy TSS to ensure that the formation of all

KEKs or FEKs (as decided in the FCS_CKM_EXT.1 selection) is described and that the key sizes match that described

by the ST author.

The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded

and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and

the evaluator shall verify that these are supported by the selections in this component as well as the selections

concerning the hash function itself. The evaluator shall verify that the TSS contains a description of how the output

of the hash function is used to form the submask that will be input into the function and is the same length as the

KEK as specified in FCS_CKM_EXT.4.

For the NIST SP 800-132-based conditioning of the password/passphrase, the required assurance activities will be

performed when doing the assurance activities for the appropriate requirements (FCS_COP.1.1(4)). If any



manipulation of the key is performed in forming the submask that will be used to form the FEK or KEK, that process

shall be described in the TSS.

No explicit testing of the formation of the submask from the input password is required.

Section 6.1 of [ST] claims support for all special characters identified by the SFR for use in passwords. Section 6.1

of [ST] indicates that the TOE enforces a minimum length for passwords of 6 characters. Section 6.1 of [ST] states

that the TOE can accept 74 character passwords.

Section 6.1 of [ST] states that the TOE encodes passwords using UTF-8 encoding prior to using the platform

provided Password-based Key Derivation Function (using HMAC-SHA-512).

Guidance Assurance Activities: None Defined

Testing Assurance Activities: None Defined

2.1.1.2 FCS_CKM_EXT.1(A).2

TSS Assurance Activities: FCS_CKM_1.2(A): The ST author shall provide a description in the TSS regarding the salt

generation. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1 (from

the AS PP).

Section 6.1 of [ST] provides a description of the salt generation.



Component TSS Assurance Activities: None Defined

Component Guidance Assurance Activities: The evaluators shall check the Operational Guidance to determine

that there are instructions on how to generate large passwords/passphrases, and instructions on how to configure

the password/passphrase length (and optional complexity settings) to provide entropy commensurate with the

keys that the authorization factor is protecting. This is important because many default settings for

passwords/passphrases will not meet the necessary entropy needed as specified in this EP.

The sections entitled “DaR Settings” and “Changing the User PIN/Passphrase” in [OM] contain notes suggesting

‘strong passwords’ be used for the user’s PIN/Password in section associated with the use and setting of this

password. A mixture of one upper case letter, one lower case letter, a special character and a number is

recommended, along with an indication that there are password complexity settings which can mandate specific

complexity metrics.



The section entitled “DaR Settings” in [OM] indicates that the possible values which can be specified as a password

length range from 6 to 74 characters.

Component Testing Assurance Activities:

Support for Password/Passphrase characteristics: In addition to the analysis above, the evaluator shall also

perform the following tests on a TOE configured according to the Operational Guidance:

Test 1: Ensure that the TOE supports passwords/passphrases of a minimum length of 64 characters.

Test 2: Ensure that the TOE does not accept more than the maximum number of characters specified in

FCS_CKM_EXT.1.1(A).

Test 3: Ensure that the TOE does not accept less than the minimum number of characters specified in

FCS_CKM_EXT.1.4(A). If the minimum length is settable by the administrator, the evaluator determines the

minimum length or lengths to test.

Test 4: Ensure that the TOE supports passwords consisting of all characters listed in FCS_CKM_EXT.1.2(A).

Iteration count: The evaluator shall verify that the iteration count for PBKDFs performed by the TOE comply with

NIST SP 800-132 by ensuring that the TSS contains a description of the estimated time required to derive key

material from passwords and how the TOE increases the computation time for password-based key derivation

(including but not limited to increasing the iteration count).

The Testing assurance activities shown above incorporate TD0067.

Test 1: The evaluator configured a password of 64 characters and demonstrated that it could be accepted.

Test 2: The evaluator configured a maximum password length of 74 characters, and attempted to create

passwords of length 74 and 75. Only passwords of length 74 were allowed.

Test 3: The evaluator configured a minimum value for the password. The evaluator then successfully set the

password to the minimum value. The evaluator then attempted to set the password to one character less than the

minimum. This attempt failed.

Test 4: The evaluator repetitively set the password using each of the characters in the ST. The evaluator was able

to successfully use each claimed character in a password.

2.1.2 KEY ENCRYPTING KEY (KEK) SUPPORT (FCS_CKM_EXT.1)

2.1.2.1 FCS_CKM_EXT.1.1

TSS Assurance Activities: None Defined





2.1.2.2 FCS_CKM_EXT.1.2




Component TSS Assurance Activities: The assurance activity for this component entails examination of the ST's

TSS to determine that the TOE's implementation of the requirements is documented. The evaluators shall first

examine the TSS section to ensure that the authorization factors specified in the ST are described. For

password/passphrase-based factors, the examination of the TSS section is performed as part of FCS_CKM_EXT.1(A)

assurance activities.

If external authorization factors are supported, then the evaluator will perform the following activities (these may

be performed in conjunction with those performed for FCS_COP.1(5) and FIA_FCT_EXT.1(1)). The evaluator checks

to ensure that the TSS describes the method used by the TSF to invoke the function used to protect the private key

of the user on the external entity. If this function is provided by the external entity itself and not by the TSF, then

the evaluator shall ensure the TSS describes the method by which the TSS can detect that the private key was

successfully accessed by the external entity.

The evaluator shall also check that the TSS describes how the TSF invokes either the RSA or ECC functionality in the

external entity; this must include a description of both an encryption and decryption scenario for the FEK. This

description shall include the manner in which the external entity is invoked to ensure that the requirements for the

FEK protection listed in FCS_COP.1(5) are met.

Section 6.1 of [ST], the FCS_CKM_EXT.1(A) bullet, discusses a DaR password, see the FCS_CKM_EXT.1(A) assurance

activities for a discussion of how this DaR password complies with FCS_CKM_EXT.1(A).

Section 6.1 of [ST] contains a new key hierarchy diagram. This diagram along with its supporting text describes the

key management activities performed by the TOE. These activities address the following Key Encryption Keys

(KEKs).

FEK The file encryption key (FEK) is not a KEK, but for completeness, it is

included in this list of keys used by the TOE. The FEK is generated

using the platform’s DRBG (see FCS_CKM_EXT.1 bullet in section 6.1 of

[ST]).



FE KEK The file encryption KEK (FEKEK) is a 256-bit AES encryption key used to

encrypt the FEK used by an application. The FEKEK is generated using

the Android API (KeyGenerator) (per FCS_CKM_EXT.1 bullet in section

6.1 of [ST]).

Applications’ RSA key pair The RSA keys belonging to the application. The Applications’ RSA key

pair is generated using the Android API (KeyGenerator). (See

FCS_CKM_EXT.1 bullet in section 6.1 of [ST]).

Mgmt App’s RSA key pair The RSA keys belonging to the Management Application of the TOE.

This key is used to wrap and unwrap the FEKEK. The Management

Application’s RSA key pair is generated using the Android API

(KeyGenerator). (See FCS_CKM_EXT.1 bullet in section 6.1 of [ST]).

PBKDF2 Derived Key A key derived from the DaR password provided by the user to the

Management Application. This derived key is created from a password

using PBKDF2 with 4096 iterations and HMAC-SHA-512 (See

FCS_CKM_EXT.1(A) bullet in section 6.1 of [ST]).

DaR User Password The DaR user password is provided by a user to the Management

Application. It is created by the user.

The TOE does not utilize external authorization factors.

Component Guidance Assurance Activities: The evaluator shall check the Operational Guidance to ensure that any

configuration of the TSF to support the authorization factors selected is present. For instance, if external entities

are to be used to decrypt/encrypt the FEK, instructions for setting up the TOE to recognize the external entities (if

needed) must be present. The evaluator shall also check the Operational Guidance to ensure that adequate

warning is given to users regarding the importance of having passwords/passphrases with strong entropy.

The only user interface to the file encryption KEKs is the password the user is required to enter prior to accessing

data. This is the Data-at-Rest password (a.k.a., DaR password).

The user’s DaR password is used by the TOE to derive the AES key used to wrap the FEKEK using PBKDF2.

The sections entitled “DaR Settings” and “Changing the User PIN/Passphrase” in [OM] contain notes suggesting

‘strong passwords’ be used for the user’s PIN/Password in section associated with the use and setting of this

password. A mixture of one upper case letter, one lower case letter, a special character and a number is

recommended, along with an indication that there are password complexity settings which can mandate specific

complexity metrics.

Component Testing Assurance Activities: The evaluators also perform the following assurance activities:



Test 1 [conditional]: If the TOE performs input validation on password/passphrase authorization factors (e.g.,

correct length of factor), perform tests to ensure the input validation routines identify malformed authorization

factors.

Test 2: An example ciphertext file generated via the TOE shall be provided to the evaluator with the accompanying

KEK and prerequisite authorization information used for encryption. The evaluator will use the TOE in conjunction

with a debugging or forensics utility to attempt a decrypt of the ciphertext file using the provided authorization

information. The evaluator will then terminate processing of the TOE and perform a search through non-volatile

memory using the provided KEK string. The evaluator must document each command, program or action taken

during this process, and must confirm that the KEK was never written to non-volatile memory. This test must be

performed three times to ensure repeatability. If during the course of this testing the evaluator finds that the KEK

was written to non-volatile memory, they should be able to identify the cause (i.e. the TOE wrote the KEK to disk,

the TOE platform dumped volatile memory as a page file, etc.), and document the reason for failure to comply with

the requirement.

Other testing is performed with the FIA_FCT_EXT.1, FCS_COP.1(5), and FDP_PRT_EXT.1 assurance activities.

Test 1 – The evaluator attempted to enter a password less than the required length. It was not accepted.

Test 2 – The evaluated created an encrypted file and captured the KEK. The evaluator then dumped the non-

volatile memory and searched for the KEK. The KEK was not found. The evaluator repeated this 2 more times and

never found the KEK.

2.1.3 CRYPTOGRAPHIC KEY GENERATION (FEK) (FCS_CKM_EXT.2)

2.1.3.1 FCS_CKM_EXT.2.1




2.1.3.2 FCS_CKM_EXT.2.2




2.1.3.3 FCS_CKM_EXT.2.3






Component TSS Assurance Activities: FCS_CKM_EXT.2.1: The evaluator shall review the TSS to determine that a

description covering how and when a FEK are generated exists. The description must cover all environments on

which the TOE is claiming conformance, and include any preconditions that must exist in order to successfully

generate the FEK. The TSS is checked to ensure that the description of how the FEK are generated is consistent

with the instructions in the AGD guidance, and any differences that arise from different platforms are taken into

account. This assurance activity may be combined with activities for FCS_COP.1(5) and FCS_CKM_EXT.2.1.

For the first selection, the evaluator shall review the TSS to determine that it describes how the functionality

described by FCS_RBG_EXT.1 (from the AS PP) is invoked to generate FEK. To the extent possible from the

description of the RBG functionality in FCS_RBG_EXT.1 (from the AS PP), the evaluator shall determine that the key

size being requested is identical to the key size and mode to be used for the decryption/encryption of the user

data (FCS_COP.1(1)).

For the second selection, password/passphrase-based factors, the examination of the TSS section is performed as

part of FCS_CKM_EXT.1(A) assurance activities.

FCS_CKM_EXT.2.2: The evaluator shall examine the TSS to determine that it describes how a FEK is created for a

protected resource and associated with that resource; protection of the FEK itself is covered by FIA_AUT_EXT.1

and FCS_COP.1(5). The evaluator confirms that – per this description – the FEK is unique per resource (file or set of

files) and that the FEK is created using the mechanisms specified in ).

FCS_CKM_EXT.2.3: The evaluator shall review the TSS to verify it details that the FEKs are generated on the client

machine and are not generated on an external server.

Section 6.1 of [ST] under the FCS_CKM_EXT.2 bullet indicates that the TOE generates File Encryption Keys (FEK)

using platform APIs (the KeyGenerator API). The ST also indicates that a FEK is created every time a new file is

going to be encrypted and that a hidden directory is created for each file using the file’s name in the name of the

hidden directory. . The TOE automatically generates a FEK (without user action) whenever the application

attempts to encrypt a new file.

Section 6.1 of [ST] provides a description of how a FEK is associated with a resource. Since Section 6.1 of [ST]

indicates that Android platform cryptographic APIs are used, the evaluator concluded that FEKs are generated on

the client machine and not on an external server.

Section 6.1 of [ST] indicates that the Android SP 900-90A AES-256 CTR DRBG is used to generate 256-bit keys by

using the Android platform cryptographic APIs.

The second selection offered by the PP was not included in the ST.



Component Guidance Assurance Activities: The evaluator shall review the instructions in the AGD guidance to

determine that any explicit actions that need to be taken by the user to create a FEK exist – taking into account any

differences that arise from different platforms – and are consistent with the description in the TSS.

The user’s password is used by the TOE to derive the AES key used to wrap the FEKEK using PBKDF2. Notes within

[OM] indicate that strong passwords be used. The notes recommend a passphrase with at least one uppercase

letter, lowercase letter, special character, and number. These constraints can also be forced using complexity

settings enforced by the TOE.

Component Testing Assurance Activities: None Defined

2.1.4 EXTENDED: CRYPTOGRAPHIC KEY DESTRUCTION (FCS_CKM_EXT.4)

2.1.4.1 FCS_CKM_EXT.4.1




Component TSS Assurance Activities: If the platform provides the key destruction, then the evaluator shall

examine the TSS to verify that it describes how the key destruction functionality is invoked.

If the application invokes key destruction, the evaluator shall check to ensure the TSS describes each of the secret

keys (keys used for symmetric encryption and/or data authentication), private keys, and CSPs used to generate

key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of

zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). 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 zeroization procedure in terms of the memory in which the data are stored (for example,

'secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on the internal

hard drive are zeroized by overwriting three times with a random pattern that is changed before each write').

The FCS_CKM_EXT.4 bullet in Section 6.1 indicates that the TOE relies upon the platform to perform key

destruction. It provides a table identifying the keys used by the TOE, indicating where they exist in cleartext form,

the API used to destroy the cleartext version of the key, and when the cleartext version of the key is destroyed.

The information in this bullet also discusses how protected keys (encrypted keys or keys stored in a keystore) are

destroyed. It states that the RSA key and the FEK are deleted by a factory reset, which causes the deletion of the

Android keystore. This prevents the double wrapped FEKEK from being unwrapped using the RSA key. However a

factory reset will delete all keys in all keystores. Therefore, the key destruction functionality for protected keys is

invoked through the factory reset mechanism of the platform.



Component Guidance Assurance Activities: None Defined

Component Testing Assurance Activities: These tests are only for key destruction provided by the application:

Test 1: For each type of authorization service, encryption mode and encryption operation, a known authorization

factor, FEK and KEK must be provided to the evaluator with an associated ciphertext data set (e.g. if a passphrase is

used to create a KEK, then the ciphertext containing the FEK as well as the KEK itself must be provided to the

evaluator. If a passphrase is used to generate a FEK, then the ciphertext file encrypted with the FEK as well as the

FEK must be provided to the evaluator.) The evaluator will use the TOE in conjunction with a debugging or

forensics utility to attempt to authorize themselves, resulting in the generation of a FEK or decryption of a FEK. The

evaluator will ascertain from the TSS what the vendor defines as 'no longer needed' and execute the sequence of

actions via the TOE to invoke this state. At this point, the evaluator should take a dump of volatile memory and

search the retrieved dump for the provided authorization credentials, KEKs or FEKs (e.g. if the password was

'PaSSw0rd', perform a string search of the forensics dump for 'PaSSw0rd'). The evaluator must document each

command, program or action taken during this process, and must confirm that no plaintext keying material resides

in volatile memory. The evaluator must perform this test three times to ensure repeatability. If during the course

of this testing the evaluator finds that keying material remains in volatile memory, they should be able to identify

the cause (i.e. execution of the grep command for 'PaSSw0rd' caused a false positive) and document the reason for

failure to comply with this requirement. The evaluator will repeat this same test, but looking for keying material in

non-volatile memory -- in some cases, the non-volatile memory testing may be satisfied by other assurance

activities (see FCS_CKM_EXT.1 and FPT_FEK_EXT.1).

Test 2: For each data authentication mechanism supported by the TOE, the evaluator must be provided known

keying material with the associated ciphertext file(s). The evaluator will attempt to authenticate the ciphertext

data using the known key. The evaluator will ascertain from the TSS what the vendor defines as 'no longer needed'

and execute the sequence of actions via the TOE to invoke this state. Once this state is attained, the evaluator shall

take a forensics dump of volatile memory and perform a search for the authentication keying material (i.e. if a FAK

is used as input to an HMAC, then the evaluator will look for the FAK string in the forensics dump). The evaluator

must document each command, program or action taken during this process, and must confirm that no plaintext

keying material resides in volatile memory. The evaluator must perform this test three times to ensure

repeatability. If during the course of this testing the evaluator finds that keying material remains in volatile

memory, they should be able to identify the cause and document the reason for failure to comply with this

requirement. The evaluator will repeat this same test, but looking for keying material in non-volatile memory -- in

some cases, the non-volatile memory testing may be satisfied by other assurance activities (see FCS_CKM_EXT.4).

Tests – This test is not applicable for the RSA keys that are written to the Android Keystore as the TOE calls the

platform to perform the key destruction.

For the keys managed by the TOE (FEK, FEKEK, Application unwrapped FEKEK, and PBKDF2 derived key), the TOE

releases them as described in Section 6.1 of the ST, Table 5. In all cases, the TOE relies on the Java garbage

collection from the TOE platform. As such, the evaluator is citing TD65 (https://www.niap-

ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=68) as related since in both cases, the TOE cannot

https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=68

https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=68



predict when the platform will actually clear the key. The TSS describes the key clearing process and the evaluator

extrapolates that description as consistent with TD position.

2.1.5 CRYPTOGRAPHIC OPERATION (DATA ENCRYPTION) (FCS_COP.1(1))

2.1.5.1 FCS_COP.1(1).1




Component TSS Assurance Activities: Requirement met by the platform

If the platform provides the AES symmetric encryption/decryption, then the evaluator shall examine the TSS to

verify that it describes how the key destruction encryption/decryption is invoked.

Requirement met by the TOE

If multiple modes are supported, the evaluator examines the TSS and guidance documentation to determine how a

specific mode/key-size is chosen by the end user. The evaluator then tests each mode/key size combination in the

manner found in the following sections, as appropriate.

Bullet FCS_COP.1(1) in Section 6.1 of [ST] indicates that the TOE invokes the Android platform’s cryptographic APIs

for AES CBC. The TOE uses 256-bit AES CBC to encrypt user files with the FEK (as stated at the end of the

description in the FCS_KYC_EXT.1 bullet of section 6.1 in [ST].

The FCS_COP.1(1) bullet in section 6.1 of [ST] also indicates that the android routines Cipher.getInstance(),

Cipher.inti() and Cipher.doFinal() are invoked to perform the encryption and decryption operations.

Furthermore, the table showing CAVS certificates for AES shows that it is being used by the TOE in 256-bit CBC

mode, which corresponds to a valid use as defined by the referenced CAVS certificate. The certificates shown in

the table correspond to all currently available Android 4.4 evaluated platforms (which are identified in section 1.3

of [ST]).

Note: The [ST] corrected an error in FCS_COP.1(1) in [FEEP10] contains an error, FCS_COP.1(1) in [ST] indicates

that the TOE “invokes platform-provided AES encryption”. (The [FEEP10] error is that its version of the

requirement says the application shall “implement platform-provided AES encryption”. The application does not

“implement” something that is “platform-provided”. This was confirmed by NIAP during the synch meeting.)

The TSS and the SFR are consistent in claiming to provide support for 256-bit AES.




Component Testing Assurance Activities: These tests are only for data encryption provided by the application:

AES-CBC Tests

AES-CBC Known Answer Tests

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

shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying

the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall

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

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

obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all

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

shall be encrypted with a 256-bit all-zeros key.

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

ciphertext values as input and AES-CBC decryption.

KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 key values and obtain the

ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV

of all zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys.

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

zero ciphertext value as input and AES-CBC decryption.

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

below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key

value and an IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second set shall have 256 256-

bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N].

To test the decrypt functionality of AES-CBC, the evaluator shall supply the two

sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC

decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs

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

key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i

in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted

with its corresponding key.

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

described below and obtain the two ciphertext values that result from AES-CBC encryption of the given plaintext

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



zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits

be zeros, for i in [1,128].

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

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

AES-CBC Multi-Block Message Test

The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i <=10. The evaluator

shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be

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

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

The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i

<=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message,

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

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

AES-CBC Monte Carlo Tests

The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these

shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-

tuple, 1000 iterations shall be run as follows:

# Input: PT, IV, Key

for i = 1 to 1000:

if i == 1:

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

PT = IV

else:

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

PT = CT[i-1]

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

compared to the result of running 1000 iterations with the same values using a known good implementation.

The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and

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

XTS-AES Monte Carlo Test



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

lengths:

256 bit (for AES-128) and 512 bit (for AES-256) keys

Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128

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

unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.

using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results

from XTS-AES encrypt.

The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports

it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert

to a tweak value internally.

The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext

values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.

Test - This test has been met by the CAVP certificate #1884

2.1.6 CRYPTOGRAPHIC OPERATION (KEYED-HASH MESSAGE AUTHENTICATION)

(FCS_COP.1(4))

2.1.6.1 FCS_COP.1(4).1




Component TSS Assurance Activities: Requirement met by the TOE

For all cases where the output of the HMAC following the hash calculation is truncated, the evaluator shall ensure

that the TSS states for what operation this truncation takes place; the size of the final output; and the standard to

which this truncation complies.

The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function:

key-length, hash function used, block size, and output MAC length used.

Requirement met by the Platform



The evaluator shall examine the TSS to verify that it describes how the keyed hash function algorithm is invoked.

The SFR claims that the application shall “invoke platform provided functionality”. Section 6.1 of [ST] describes that the TOE uses the platform’s HMAC-SHA-384, HMAC-SHA-512 and DRBG.

The table showing CAVS certificates for Keyed-hash message authentication shows that the Keyed-hash message

authentications being used by the TOE, correspond to the valid uses as defined by the referenced CAVS certificate.

The certificates shown in the table correspond to all currently available Android 4.4 evaluated platforms (which are

identified in section 1.3 of [ST]).


Component Testing Assurance Activities: Requirement met by the TOE

For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist

of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The

resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a

known good implementation.

Test - This test has been met by the CAVP certificate #1126

2.1.7 CRYPTOGRAPHIC OPERATION (KEY WRAPPING) (FCS_COP.1(5))

2.1.7.1 FCS_COP.1(5).1




Component TSS Assurance Activities:

Requirement met by the platform

If the platform provides the FEK encryption/decryption, then the evaluator shall examine the TSS to verify that it

describes how the FEK encryption/decryption is invoked.


The evaluator shall examine the TSS to ensure there is a high-level description of how the FEK is protected.



Bullet FCS_COP.1(5) in section 6.1 of [ST] indicates that the TOE utilizes platform provided cryptographic APIs. The

evaluator examined the list of APIs associated with FPT_API_EXT.1 and found APIs in the required list that provided

AES and RSA key wrapping and unwrapping operations (i.e., cipher.wrap and cipher.unwrap).

The table showing CAVS certificates for AES shows that AES is being used by the TOE for 256-bit AES key

wrapping. This corresponds to a valid use as defined by the referenced CAVS certificate. The certificates shown in

the table correspond to all currently available Android 4.4 evaluated platforms (which are identified in section 1.3

of [ST]).


Component Testing Assurance Activities: These tests are only for data encryption provided by the application:

Test 1: The evaluator shall use platform tools (such as a debugger) to generate a FEK to be generated and capture

the value of the FEK. The evaluator shall then continue with the TOE operation which will result in an encrypted

resource, as well as an encrypted FEK being associated with the resource as described in the TSS. The evaluator

shall then examine the encrypted FEK to determine that it is different than the value of the unencrypted FEK. The

evaluator shall then use the information provided in the ST and TSS to determine that the unencrypted FEK - when

wrapped according to the algorithm and parameters used by the TOE as described - produces the value observed

for the encrypted FEK.

AES Key Wrap (with or without padding)

If AES Key Wrap is used to decrypt/encrypt the key, the evaluator shall examine the TSS to determine that it

specifies that the implementation conforms to SP 800-38F with the appropriate (with or without padding) Key

Wrap section using AES.

The evaluator shall also perform the verification procedures outlined in the testing methodology, “The Key Wrap

Validation System”. (http://csrc.nist.gov/groups/STM/cavp/documents/mac/KWVS.pdf)

RSA

The evaluator shall check the TSS to ensure it describes the various values used for the RSA-OAEP encryption and

decryption scheme described in NIST SP 800-56B, section 7.2.2 and other referenced sections.

The evaluator shall also perform the validation procedures outlined in http://www.emc.com/emc-plus/rsa-

labs/standards-initiatives/pkcs-rsa-cryptography-standard.htm.

ECC CDH

The evaluator shall verify a TOE's implementation of the ECC DH key agreement scheme using the following

Function and Validity tests. These validation tests verify that a TOE has implemented the components of the key

agreement scheme according to the specifications in the Recommendation. These components include the

calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material

(DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that



the components of key confirmation have been implemented correctly, using the test procedures described below.

This includes the parsing of the DKM, the generation of MAC data and the calculation of MAC tag.

Function Test

The Function test verifies the ability of the TOE to implement the key agreement scheme correctly. To conduct this

test, the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported

schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if

supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test

vectors. The data set consists of one NIST approved curve per 10 sets of ephemeral public keys. The evaluator shall

obtain the DKM, the corresponding TOE‘s public keys, the MAC tag(s), and any inputs used in the KDF, such as the

Other Information field OI and TOE id fields. The evaluator shall verify the correctness of the TSF‘s implementation

of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying

material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported,

the TSF shall perform the above for each implemented approved MAC algorithm.

Validity Test

The Validity test verifies the ability of the TOE to recognize another party‘s valid and invalid key agreement results

with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting

cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the

TOE should be able to recognize. The evaluator generates a set of 30 test vectors consisting of data sets including

the selected NIST approved curves, the evaluator‘s public keys, the TOE‘s ephemeral public/private key pairs,

MACTag, and any inputs used in the KDF, such as the other info and TOE id fields.

The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement

results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information

field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial public key

validation, the evaluator will also individually inject errors in the static public keys, the ephemeral public keys and

the TOE‘s ephemeral private key to assure the TOE detects errors in the public key validation function and/or the

partial key validation function. At least two of the test vectors shall remain unmodified and therefore should result

in valid key agreement results (they should pass).

The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding

parameters. The evaluator shall compare the TOE‘s results with the results using a known good implementation

verifying that the TOE detects these errors.

This test has been met by the CAVP certificate #1884

2.1.8 EXTENDED: INITIALIZATION VECTOR GENERATION (FCS_IV_EXT.1)



2.1.8.1 FCS_IV_EXT.1.1




Component TSS Assurance Activities:


If the platform provides the IV generation, then the evaluator shall examine the TSS to verify that it describes how

the IV generation is invoked.


The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is

described and the formation of the IVs for any data encrypted by the same key meets FCS_IV_EXT.1.

Section 6.1 of [ST] describes that IVs are used for the encryption and decryption of user data using the File

Encryption Key (FEK). The TOE uses 256-bit AES , or the platform APIs associated with the TOE using the platform

to generate an IV (via the SecureRandom() API)..



2.1.9 KEY CHAINING AND KEY STORAGE (FCS_KYC_EXT.1)

2.1.9.1 FCS_KYC_EXT.1.1




Component TSS Assurance Activities: Requirement met by the TOE

The evaluator shall verify the TSS* describes a high level description of the key hierarchy for all authorizations

methods selected in FIA_AUT_EXT that are used to protect the KEK or FEK. The evaluator shall examine the TSS 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 that meet FCS_COP.1(5).

The evaluator shall verify the TSS* 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. A high-level description should 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 knowledge of the KEK or FEK and the effective strength of the FEK is

maintained throughout the Key Chain.

*if necessary, this information could be contained in a proprietary document and not appear in the TSS.


If the platform provides the IV generation, then the evaluator shall examine the TSS to verify that it describes how

the IV generation is invoked.

The FCS_KYC_EXT.1 bullet in section 6.2 of [ST] provides a key hierarchy diagram (Figure 6-1). The relationship of

the keys used by the TOE is described in by several of the bullets in section 6.2 including FCS_COP.1(4) and

FCS_CKM_EXT.1.

The Figure 6-1 Key Hierarchy Diagram, of [ST] shows that keys are protected when stored in non-volatile memory

using either platform provided protected storage mechanisms (Android keystore) or AES 256-bit wrapping. The

only exception to this is the storage of an ephemeral key which resides in the application’s BouncyCastle keystore.

This ephemeral key exists in the keystore only for as long as the DaR password timer allows. It is protectected

using an RSA 2048-bit key wrapping. The developer choose to pass this key between the Management service and

the TOE library within the application using the RSA key wrapping and BouncyCastle keystore; rather than passing

a cleartext key in memory.



2.1.10 RANDOM BIT GENERATION SERVICES (FCS_RBG_EXT.1)

2.1.10.1 FCS_RBG_EXT.1.1






Component TSS Assurance Activities: If implement DRBG functionality is selected, the evaluator shall ensure that

additional FCS_RBG_EXT.2 elements are included in the ST.

The operation in this requirement indicates the TOE uses the platform DRBG functionality, so FCS_RBG_EXT.2 need

not be included in [ST].

Component Guidance Assurance Activities: If use no DRBG functionality is selected, the evaluator shall inspect the

application and its developer documentation and verify that the application needs no random bit generation

services.

The operation in FCS_RBG_EXT.1.1 makes the selection “invoke platform provided DRBG functionality. Therefore,

this assurance activity does not apply.

Component Testing Assurance Activities: If invoke platform provided DRBG functionality is selected, the

evaluation activities will be performed as stated in the following requirements. The evaluator shall verify that the

TSS identifies the calls used in acquiring random from each instantiation of the RBG used for the application's

cryptographic functionality. The evaluator shall ensure that random bits are acquired properly from the platform.

This varies on a per-platform basis:

For BlackBerry: The evaluator shall verify that the application invokes Security Builder Crypto GSE.

For Android: The evaluator shall verify that the application uses at least one of javax.crypto.KeyGenerator class or

the java.security.SecureRandom class or /dev/random or /dev/urandom.

For Windows: The evaluator shall verify that BCryptGenRandom or CryptGenRandom API is used for classic

desktop applications. The evaluator shall verify that the System.Random API is used for Windows Store

Applications. In future versions of this document, CryptGenRandom may be removed as an option as it is no longer

the preferred API per vendor documentation.

For iOS: The evaluator shall verify that the application invokes SecRandomCopyBytes or uses /dev/random directly

to acquire random.

For Linux: The evaluator shall verify that the application collects random from /dev/random or /dev/urandom.

For Solaris: The evaluator shall verify that the application collects random from /dev/random.

For Mac OS X: The evaluator shall verify that the application uses /dev/random to acquire random.

If invocation of platform-provided functionality is achieved in another way, the evaluator shall ensure the TSS

describes how this is carried out, and how it is equivalent to the methods listed here (e.g. higher-level API invokes

identical low-level API).

The TSS indicated that both KeyGenerator and SecureRandom were used by the TOE. KeyGenerator is used for the

generation of RSA and AES keys, while SecureRandom is used for generation of salt and IV values.



Bullet FCS_CKM_EXT.1(A) of section 6.1 in [ST] indicates that salts are obtained using the platform’s

java.security.SecureRandom cryptographic API.

Bullet FCS_CKM_EXT.1 of section 6.1 in [ST] indicates that all RSA and AES keys are generated using generated

using the Android platform’s KeyGenerator API

Bullet FCS_IV_EXT.1 of section 6.1 in [ST] indicates that the TOE calls the platform’s SecureRandom() API to

generate a 128-bit (16-byte) initialization vector for use when encrypting/decrypting user data with the FEK.

2.1.11 STORAGE OF SECRETS (FCS_STO_EXT.1)

2.1.11.1 FCS_STO_EXT.1.1




Component TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists all persistent

credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of

these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored.

Figure 6-1, depicts the keys shown in the first column of the following table. The remaining columns indicate the

purpose and storage location for each key, along with a reference to the location in the ST where the information

can be found.

Key Usage Storage Location File Encryption Key (FEK)

Use to perform AES encryption and decryption of user data (files)

Stored encrypted by the FEKEK in flash in a hidden directory named after the file it encrypts.

FCS_KYC_EXT.1, FCS_COP.1(1) and FCS_IV_EXT.1 bullets in section 6.1 of [ST]

FCS_CKM_EXT.2 bullet and FCS_STO_EXT.1 bullet in section 6.1 of [ST], FDP_PRT_EXT.1 bullet I section 6.2 of [ST].

FEKEK The FEKEK is used to wrap the FEK.

The FEKEK is never stored in cleartext form outside of memory. It is only stored on flash when wrapped by other keys as follows: a) It is stored in the application’s BouncyCastle Key

store when wrapped by the application’s RSA key for only as long as password timer allows.

b) It is stored in the management service’s Bouncy Castle key store when double wrapped by the management service’s RSA key AND the PBKDF2 derived AES key.



FCS_KYC_EXT.1 bullet in section 6.1 of [ST]

FCS_CKM_EXT.4, and FCS_KYC_EXT.1 bullets in section 6.1 of [ST]

Application’s RSA key pair

Used to wrap the FEKEK during the time that it is available to the application.

The Application’s RSA key pair is stored in the platform provided Android keystore belonging to the application.


FCS_STO_EXT.1 bullet in section 6.1 of [ST]

Management Service’s RSA key pair

Used to wrap the FEKEK (the inner wrapping of the double wrap)

The Management Service’s RSA key pair is stored in the platform provided Android keystore belonging to the Management Service.


FCS_STO_EXT.1 bullet in section 6.1 of [ST]

PBKDF2 derived AES key

Used to wrap/unwrap the FEKEK that is wrapped by the management service’s RSA key.

The PBKDF2 derived AES key is not stored outside of memory. It exists in memory only while needed to wrap or unwrap the FEKEK.


FCS_CKM_EXT.4 bullet in section 6.1 of [ST]


Component Testing Assurance Activities: For all credentials for which the application invokes platform-provided

functionality, the evaluator shall perform the following actions which vary per platform.

For BlackBerry: The evaluator shall verify that the application uses the BlackBerry KeyStore and Security Builder

APIs to store credentials.

For Android: The evaluator shall verify that the application uses the Android KeyStore to store certificates.

For Windows: The evaluator shall verify that all certificates are stored in the Windows Certificate Store. The

evaluator shall verify that other secrets, like passwords, are stored in the Windows Credential Manager or stored

using the Data Protection API (DPAPI). For Windows Store Apps, the evaluator shall verify that the application is

using the ProtectData class and storing credentials in IsolatedStorage.

For iOS: The evaluator shall verify that all credentials are stored within a Keychain.

For Linux: The evaluator shall verify that all keys are stored using Linux keyrings.

For Solaris: The evaluator shall verify that all keys are stored using Solaris Key Management Framework (KMF).

For Mac OS X: The evaluator shall verify that all credentials are stored within Keychain.

Test: The evaluator verified the TSS states the implementation uses the Android keystore for certificates.

2.2 USER DATA PROTECTION (FDP)



2.2.1 ENCRYPTION OF SENSITIVE APPLICATION DATA (FDP_DAR_EXT.1)

2.2.1.1 FDP_DAR_EXT.1.1






Component Testing Assurance Activities: The evaluator shall inventory the filesystem locations where the

application may write data. The evaluator shall run the application and attempt to store sensitive data. The

evaluator shall then inspect those areas of the filesystem to note where data was stored (if any), and determine

whether it has been encrypted.

If not store any sensitive data is selected, the evaluator shall inspect the TSS and ensure that it describes how

sensitive data cannot be written to nonvolatile memory. The evaluator shall also ensure that this is consistent with

the filesystem test above.

If implement functionality to encrypt sensitive data is selected, then evaluation is required against the Application

Software Protection Profile Extended Package: File Encryption. The evaluator shall ensure that such evaluation is

underway.

If leverage platform-provided functionality is selected, the evaluation activities will be performed as stated in the

following requirements, which vary on a per-platform basis:

For BlackBerry: The evaluator shall inspect the TSS and ensure that it describes how the application uses the

Advanced Data at Rest Protection API and how the application uses the appropriate domain to store and protect

each data file.

For Android: The evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are

stored with the MODE_PRIVATE flag set.

For Windows: The Windows platform currently does not provide Data-at-rest encryption services which depend

upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes

the need to activate platform encryption, such as BitLocker or Encrypting File System (EFS), clear to the end user.

For iOS: The evaluator shall inspect the TSS and ensure that it describes how the application uses the Complete

Protection, Protected Unless Open, or Protected Until First User Authentication Data Protection Class for each data

file stored locally.



For Linux: The Linux platform currently does not provide Data-at-rest encryption services which depend upon

invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the

need to activate platform encryption clear to the end user.

For Solaris: The Solaris platform currently does not provide data-at-rest encryption services which depend upon

invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the

need to activate platform encryption clear to the end user.

For Mac OS X: The Mac OS X platform currently does not provide Data-at-rest encryption services which depend

upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes

the need to activate platform encryption clear to the end user.

Test – The evaluator created an encrypted file and took an inventory of where it stored its data. The evaluator

then ensured those areas where encrypted.

2.2.2 ACCESS TO PLATFORM RESOURCES (FDP_DEC_EXT.1)

2.2.2.1 FDP_DEC_EXT.1.1



Testing Assurance Activities: The evaluator shall install and run the application and inspect its user

documentation to verify that the user is informed of any need to access hardware resources. The method of doing

so varies per platform.

For BlackBerry: The evaluator shall install the application and run it for the first time. The evaluator shall verify that

the application displays all platform resources it would like to access. Note: If the user goes to: App permissions >

Settings > Security and Privacy > Application Permissions > Select application in question, it will list which platform

resource are approved/denied and can be changed.

For Android: The evaluator shall install the application and verify that the application displays the platform

resources it would like to access. This includes permissions such as ACCESS_COARSE_LOCATION,

ACCESS_FINE_LOCATION, BLUETOOTH, CAMERA, INTERNET, NFC, READ_EXTERNAL_STORAGE, RECORD_AUDIO.

A complete list of Android permissions can be found at:

http://developer.android.com/reference/android/Manifest.permission.html

http://developer.android.com/reference/android/Manifest.permission_group.html



For Windows: For Windows Store Apps the evaluator shall check the WMAppManifest.xml file for a list of required

hardware capabilities. The evaluator shall verify that the user is made aware of the required hardware capabilities

when the application is first installed. This includes permissions such as ID_CAP_ISV_CAMERA, ID_CAP_LOCATION,

ID_CAP_NETWORKING, ID_CAP_MICROPHONE, ID_CAP_PROXIMITY and so on. A complete list of Windows App

permissions can be found at:

http://msdn.microsoft.com/enUS/library/windows/apps/jj206936.aspx

For Windows Desktop Applications the evaluator shall verify that either the application or the documentation

provide the user with a list of the required hardware resources.

For iOS: The evaluator shall verify that either the application or the documentation provide the user with a list of

the required hardware resources.

For Linux: The evaluator shall verify that either the application software or its documentation provides the user

with a list of the required hardware resources.

For Solaris: The evaluator shall verify that either the application software or its documentation provides the user

with a list of the required hardware resources.

For Mac OS X: The evaluator shall verify that either the application software or its documentation provides the

user with a list of the required hardware resources.

The TOE claims access is needed to the a USB and network connectivity in FDP_DEC_EXT.1.1. The permissions

obtained and displayed after the application is installed are shown in Table 2-1 DaR Manifest Permissions, below.

These permissions correspond to this claim.

2.2.2.2 FDP_DEC_EXT.1.2

TSS Assurance Activities: The evaluator shall ensure that the selection captures all sensitive information

repositories which the application is intended to access.

The TOE accesses the SD card, this Is identified by either the 1st

or 2nd element of this SFR.


Testing Assurance Activities: The evaluator shall install and run the application software and inspect its user

documentation to verify that the user is informed of any need to access these repositories. The method of doing so

varies per platform.

For BlackBerry: The evaluator shall install the application and run it for the first time. The evaluator shall verify that

the application displays all platform resources it would like to access.

For Android: The evaluator shall install the application and verify that the application displays the permissions used

to access system-wide repositories. This includes permissions such as READ_CALENDAR, READ_CALL_LOG,



READ_CONTACTS, READ_EXTERNAL_STORAGE, READ_LOGS. A complete list of Android permissions can be found

at:


http://developer.android.com/reference/android/Manifest.permission_group.html

For Windows: For Windows Store Apps the evaluator shall check the WMAppManifest.xml file for a list of required

capabilities. The evaluator shall verify that the user is made aware of the required information repositories when

the application is first installed. This includes permissions such as

ID_CAP_CONTACTS,ID_CAP_APPOINTMENTS,ID_CAP_MEDIALIB and so on. A complete list of Windows App

permissions can be found at:

http://msdn.microsoft.com/enUS/library/windows/apps/jj206936.aspx

For Windows Desktop Application the evaluator shall verify that either the application software or its

documentation provides the user with a list of the required sensitive information repositories.

For iOS: The evaluator shall verify that either the application software or its documentation provides provides the

user with a list of the required sensitive information repositories.

For Linux: The evaluator shall verify that either the application software or its documentation provides the user

with a list of required sensitive information repositories.

For Solaris: The evaluator shall verify that either the application software or its documentation provides the user

with a list of required sensitive information repositories.

For Mac OS X: The evaluator shall verify that either the application software or its documentation provides the

user with a list of required sensitive information repositories.

Test – The valuator installed the application and inspected the CRC DaR Service screen on the device. That screen

showed that the TOE had the access shown in the following table.

Table 2-1 DaR Manifest Permissions

TOE Permission Statement Android manifest permission Modify or delete the contents of your USB storage

WRITE_EXTERNAL_STORAGE

Read the contents of your USB storage

READ_EXTERNAL_STORAGE

Use Accounts on the device USE_CREDENTIALS (

Full network access INTERNET

Reorder running apps REORDER_TASKS

Retrieve running apps GET_TASKS

Run at startup RECEIVE_BOOT_COMPLETED


http://developer.android.com/reference/android/Manifest.permission.html#READ_EXTERNAL_STORAGE



The FDP_DEC_EXT.1.2 element indicates that the TOE will access “no sensitive information repository “. Since

none of these permissions implies access to a sensitive information repository, the claim in FDP_DEC_EXT.1.2 is

accurate.

2.2.2.3 FDP_DEC_EXT.1.3


Guidance Assurance Activities: The evaluator shall review documentation provided by the application developer

and for each resource which it requests access to, identify the justification as to why access is required.

Section 6.2 of the [ST], the FDP_DEC_EXT.1 requirement and Appendix A of [OM] all indicate that the only

hardware resources used by the TOE are those associated with use of the SD card. All of these locations are

consistent, and describe the use of the SD Card as a storage location where user data will be protected. The

“System Operations” section in [OM] indicates that the TOE will read/write data in directories that reside in either

internal SD Card or in expandable memory.


2.2.2.4 FDP_DEC_EXT.1.4



Testing Assurance Activities: The evaluator shall perform the following tests:

Test 1: The evaluator shall run the application. While the application is running, the evaluator shall sniff network

traffic ignoring all non-application associated traffic and verify that any network communications witnessed are

documented in the TSS or are user-initiated.

Test 2: The evaluator shall run the application. After the application initializes, the evaluator shall run network port

scans to verify that any ports opened by the application have been captured in the ST for the third selection and its

assignment. This includes connection-based protocols (e.g. TCP, DCCP) as well as connectionless protocols (e.g.

UDP).

Test 1 – The evaluator sniffed the network to capture traffic while the TOE was running. The TOE did not produce

any network traffic as expected.

Test 2- The evaluator performed a port scan and verified that the TOE does not open any ports.



2.2.2.5 FDP_DEC_EXT.1.5



Testing Assurance Activities: The evaluator shall inspect the TSS documentation to identify functionality in the

application where PII can be transmitted, and perform the following tests.

Test 1: The evaluator shall run the application and exercise the functionality responsibly for transmitting PII and

verify that user approval is required before transmission of the PII.

Test 1 – The TOE does not transmit PII so this test is not applicable.




2.2.3 EXTENDED: PROTECTION OF SELECTED USER DATA (FDP_PRT_EXT.1)

2.2.3.1 FDP_PRT_EXT.1.1

TSS Assurance Activities: FDP_PRT_EXT.1.1: The evaluator shall examine the TSS to determine that it lists each

type of resource that can be encrypted (e.g., file, directory) and what 'encrypted' means in terms of the resource

(e.g., 'encrypting a directory' means that all of the files contained in the directory are encrypted, but the data in

the directory itself (which are filenames and pointers to the files) are not encrypted). The evaluator shall also

confirm that the TSS describes how each type of resource listed is encrypted and decrypted by the TOE. The

evaluator shall ensure that this description includes the case where an existing file or set of files is encrypted for

the first time; a new file or set of files is created and encrypted; an existing file or set of files is re-encrypted (that

is, it had been initially encrypted; it was decrypted (by the TOE) for use by the user, and is then subsequently re-

encrypted); and corresponding decryption scenarios. If other scenarios exist due to product

implementation/features, the evaluator shall ensure that those scenarios are covered in the TSS as well.

The FDP_PRT_EXT.1 bullet in section 6.2 of [ST] describes that the TOE encrypts and decrypts files. A detailed

description is provided of the TOE’s approach to minimizing the amount of data that must be decrypted to support

random reads within a file. This approach involves breaking the file into 10MB ‘chunks’. While these are not

temporary files, they are locations containing encrypted portions of the file which are kept in non- volatile

memory. These ‘chunks’, and the IV are cleared using the same approach as is used to clear the FEK (see

FCS_CKM_EXT.4 bullet in section 6.1).



The FDP_PRT_EXT.1 bullet in section 6.2 of [ST] describes that files are encrypted and decrypted using AES-CBC

mode with the 256-bit FEK. This material also describes the chunking process when a file is encrypted and

decrypted. Encrypting a cleartext file results in no changes to the original file being and the creation of a similarly

named directory structure. Decrypting the entire file results in the creation of a new cleartext file and the no

changes to the directory structure of the encrypted representation.

This discussion also explains that data from the chunks of an encrypted file can be read and written by the

application through the TOE. The TOE decrypts, modifies and re-encrypts the data of a given chunk(s) as needed

to perform the application’s requested operation.

Guidance Assurance Activities: If the TOE creates temporary objects and these objects can be protected through

administrative measures (e.g., the TOE creates temporary files in a designated directory that can be protected

through configuration of its access control permissions), then the evaluator shall check the Operational Guidance

to ensure that these measures are described.

If there are special measures necessary to configure the method by which the file or set of files are encrypted (e.g.,

choice of algorithm used, key size, etc.), then those instructions shall be included in the Operational Guidance and

verified by the evaluator. In these cases, the evaluator checks to ensure that all non-TOE products used to satisfy

the requirements of the ST that are described in the Operational Guidance are consistent with those listed in the

ST, and those tested by the assurance activities of this EP.

Section 6.2 of [ST] (the FDP_PRT_EXT.1 bullet) describes the implementation of the TOE, including the temporary

and hidden data storage used to encrypt files. Based upon this description, the evaluator concluded that there is

no need for a user to take action to eliminate these files. Thus there is no need for the guidance document [OM]

to contain instructions or to describe special measures.

Testing Assurance Activities: The evaluator shall also perform the following tests. All instructions for configuring

the TOE and each of the environments must be included in the Operational Guidance and used to establish the test

configuration.

For each resource and decryption/encryption scenario listed in the TSS, the evaluator shall ensure that the TSF is

able to successfully encrypt and decrypt the resource using the following methodology:

Monitor the temporary resources being created (if any) and deleted by the TSF. The tools used to perform the

monitoring (e.g., procmon for a Windows system) shall be identified in the test report. The evaluator shall ensure

that these resources are consistent with those identified in the TSS, and that they are protected as specified in the

Operational Guidance and are deleted when the decryption/encryption operation is completed.

Test - The TOE does not create temporary resources. The evaluator ran a process monitor on the device and did

not observe any temporary resources being created. The evaluator also took a file inventory and did not notice any

temporary files.



2.2.3.2 FDP_PRT_EXT.1.2

TSS Assurance Activities: The evaluator shall examine the TSS to ensure there is a description of how the FEK is

protected. The evaluator shall examine the TSS to ensure that it describes all temporary files/resources created or

memory used during the decryption/encryption process and when those files/resources or memory is no longer

needed. The TSS shall describe how the TSF or TOE platform deletes the non-volatile memory (for example, files)

and volatile memory locations after the TSF is done with its decryption/encryption operation.

The FDP_PRT_EXT.1 bullet of Section 6.2 of [ST] discusses the encryption/decryption process for files. The

description of the key wrapping involved to protect the FEK is described in the FCS_KYC_EXT.1 bullet of section 6.1.

The TOE does not utilize temporary files during encryption and decryption.

Key protection during storage (including protection of the FEK) is discussed in the FCS_STO_EXT.1 bullet in Section

6.1. Section 6.2 states the TOE programmatically destroys all cleartext data blocks, IVs and the FEK from volatile

memory by calling Android’s Arrays.fill method, which relies upon Java Garbage Collection in order to clear

memory used by the TOE.


Testing Assurance Activities: These tests are only for application provided functionality:

For each type of encryption mode and encryption operation, a known plaintext file, ciphertext file and the

associated keying material must be supplied to the evaluator. The evaluator will use the TOE in conjunction with a

debugging or forensics utility to attempt to encrypt the plaintext and decrypt the ciphertext. The evaluator will

ascertain from the TSS what the vendor defines as 'no longer needed' for plaintext information and execute the

sequence of actions via the TOE to invoke this state. At this point, the evaluator should take a dump of volatile

memory and search the retrieved dump for any plaintext information. The evaluator must document each

command, program or action taken during this process, and must confirm that no sensitive data resides in volatile

memory. The evaluator must perform this test three times to ensure repeatability. If during the course of this

testing the evaluator finds that plaintext material remains in volatile memory, they should be able to identify the

cause and document the reason for failure to comply with this requirement. The evaluator will repeat this same

test, but looking for sensitive data in non-volatile memory.

Test - This test is not applicable as the TOE relies on the platform for the destruction of sensitive data






2.3 IDENTIFICATION AND AUTHENTICATION (FIA)

2.3.1 USER AUTHORIZATION (FIA_AUT_EXT.1)

2.3.1.1 FIA_AUT_EXT.1.1




Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it describes how user

authentication is performed. The evaluator shall verify that the authorization methods listed in the TSS are

specified and included in the requirements in the ST.


Nothing additional.


The evaluator shall examine the TSS to ensure a description is included for how the TOE is invoking the platform

functionality and how it is getting an authorization value that has appropriate entropy.

Section 6.3 of [ST] indicates that the TOE provides a password based authorization factor that is used to

authenticate an application and load its bouncy castle keystore.

Component Guidance Assurance Activities: The evaluator shall verify that the operational guidance includes

instructions for configuring the selected authorization method.

There is only a single, password/passphrase based authorization method offered by the TOE. The “Configuring

DaR” section of [OM] describes the process used to initially configure the TOE, including initializing the user’s

password/passphrase as well as configuring password complexity and length settings. The [OM] indicates that

once configured, it is necessary for the TOE’s service to be started, before encryption and decryption features are

available. The section entitled “Starting the Service” in [OM] describes that it is necessary to start the service and

that the user must authenticate prior to the service being able to encrypt and decrypt files.

Component Testing Assurance Activities: The evaluator shall ensure that authorization using each selected

method is tested during the course of the evaluation, setting up the method as described in the operational

guidance and ensuring that authorization is successful.



Test - This has been tested as a side effect of many other tests. The authorization factor is required to use the TOE.

The correctness of the authorization factor was tested in FCS_CKM_EXT.1(A).

2.3.2 EXTENDED: USER AUTHORIZATION WITH EXTERNAL ENTITY AUTHORIZATION FACTORS

(FIA_FCT_EXT.1(1))

2.3.2.1 FIA_FCT_EXT.1(1).1




2.3.2.2 FIA_FCT_EXT.1(1).2




2.3.2.3 FIA_FCT_EXT.1(1).3




2.3.2.4 FIA_FCT_EXT.1(1).4




Component TSS Assurance Activities: The evaluator shall check the TSS section to confirm that it describes, for

each type of external entity authorization factor supported by the TOE, how a request for each type of supported



resource (file or set of files, etc.) to be encrypted/decrypted is captured by the TOE; and how the TSF interacts with

the external entity to obtain a FEK with which to perform the desired operation. Scenarios to be covered should

include initial creation of the FEK, and using a FEK to decrypt/encrypt an existing resource as well as to encrypt a

resource for the first time. If different resource types require different behavior by the TSF in terms its interactions

with external entities in unwrapping the FEK, then the evaluator shall check to ensure that these cases are

described as well.

12 Since cryptographic functions may be implemented in the Operational Environment to perform the wrapping

and unwrapping of the FEK, the evaluator shall check the TSS to ensure it describes--for each platform and external

entity identified in the ST--the interface(s) used by the TOE to invoke this functionality. This must include the

interfaces used (if supported by the TOE) for entry of credentials used to decrypt the private key, as well as the

interfaces for passing the (encrypted or unencrypted, as dictated by the implementation) FEK to the external entity

and status from external entity in terms of the validity of the authorization factors/FEKs. If the interface conforms

to a standard (e.g., PKCS #11), then it is sufficient for the evaluator to ensure that the TSS describes how the TOE

uses the standard interfaces, and that each external entity claims to support that standard. Other interfaces must

be described at the level of an API call (for instance, a 'man page' entry for *IX systems). For each mode of FEK

encryption used by the external entity, the evaluator shall check that the TSS identifies (using the information

contained in FCS_COP.1(4)) the algorithms supported by each external entity, and any functionality implemented

by the TSS to ensure that that functionality is invoked.

The evaluator shall check to ensure that the TSS states that multiple users are able to invoke the TOE, each with

their own authorization factor.

The evaluator shall check to ensure that the TSS describes the method by which a user attempting to decrypt a file

for which they do not have the correct FEK is detected and dis-allowed. If this operation is performed by the TSF,

then the method by which an incorrect FEK is detected shall be described in detail, including the information used

in detected incorrect FEKs. If this operation is performed by the external entity, then the evaluator checks to

ensure that the TSS describes the information that the TSF must present to the external entity in order for this

determination to be made, and how the response from the external entity is indicated to the TSF.

The TOE does not utilize external authorization factors.

The FIA_FCT_EXT.1 bullet in Section 6.3 of [ST] indicates that only a single user is allowed to use the TOE. The text

goes on to describe why only a valid password results in the FEKEK being successfully unwrapped and the contents

of the file being decrypted.

Component Guidance Assurance Activities: The evaluator shall ensure that any configuration needed to be

performed on the TSF to support the external entities listed in the ST (e.g., entry of private-key-credentials,

algorithms to use to encrypt FEK) shall be contained in the Operational Guidance. The evaluator shall also verify

that the Operational Guidance contains instructions on using each external entity authorization factor claimed in

the ST for each platform, and describes any error indicators that may be returned in response to elements

FIA_FCT_EXT.1.2(1) and FIA_FCT_EXT.1.4(1).



There is only a single, password/passphrase based authorization method offered by the TOE. The section entitled

“Configuring DaR” in [OM] indicates that the user’s PIN/passphrase must be provided prior to the setting the DaR

configuration, selecting other apps affected by the CRC DaR file encryption or changing the PIN/passphrase.

The guidance documentation explicitly states that the user’s password must be provided prior to a configured

application gaining access to protected files. All reference to a password or passphrase contained in [OM] refer to

only the single user password, indicating that all applications use the same user authentication password

regardless of the applications configured to use the CRC DaR file encryption.

Component Testing Assurance Activities: The evaluator shall perform the following tests (these tests may be

conducted in concert with those specified for FDP_PRT_EXT.1):

Test 1: For each external entity listed in the ST and resource type supported by the TOE (file (or set of files)),

ensure that correctly using the external entity results in access to the protected resource. This activity must be

performed using all cryptographic FEK protection algorithms and private-key-entry options identified in the TSS for

each external entity. This activity must also be performed for first-time encryption of a resource, as well as

encryption and decryption of an existing resource.

Test 2: Choose (and describe the rationale in the test report) a representative sample of different authorization

factors (either instantiation of a single authorization factor, or multiple different authorization factors), and

demonstrate that they can be used to protect different resource types on the same platform using the TOE.

Test 3: For each external entity listed in the ST and resource type supported by the TOE (file (or set of files)),

ensure that incorrect entry of the credential protecting the private key results in a notification from the TOE that

an incorrect authorization has been provided.

Test 4: For each external entity and platform combination that is valid as listed in the ST, and resource type

supported by the TOE (file (or set of files)), ensure that an attempt to decrypt a protected resource is not

associated with the user requesting access results in a notification from the TOE that an incorrect authorization has

been provided.

Test 1 - The evaluator configured the DaR Service. A password is required when configuring. The configuration also

has a usage timeout. This timeout requires the end user to re-enter the password each time the timeout expires.

Once the user enters the password, it remains valid for the usage period. The user can encrypt and decrypt files

while the password is valid.

Test 2 – The evaluator demonstrated that correct authorization factors can be used to encrypt files.

Test 3 - The evaluator demonstrated that incorrect authorization factors result in no access.

Test 4 - The evaluator demonstrated that correct authorization factors can be used to dencrypt files.

2.4 SECURITY MANAGEMENT (FMT)



2.4.1 SECURE BY DEFAULT CONFIGURATION (FMT_CFG_EXT.1)

2.4.1.1 FMT_CFG_EXT.1.1



Testing Assurance Activities: The evaluator shall check the TSS to determine if the application requires any type of

credentials and if the applications installs with default credentials. If the application uses any default credentials

the evaluator shall run the following tests.

Test 1: The evaluator shall install and run the application without generating or loading new credentials and verify

that only the minimal application functionality required to set new credentials is available.

Test 2: The evaluator shall attempt to clear all credentials and verify that only the minimal application functionality

required to set new credentials is available.

Test 3: The evaluator shall run the application, establish new credentials and verify that the original default

credentials no longer provide access to the application.

Test - These tests are not applicable as the TOE does not have any default credentials

2.4.1.2 FMT_CFG_EXT.1.2



Testing Assurance Activities: The evaluator shall install and run the application. The evaluator shall inspect the

filesystem of the platform (to the extent possible) for any files created by the application and ensure that their

permissions are adequate to protect them. The method of doing so varies per platform.

For BlackBerry: The evaluator shall run ls -alR|grep -E '$.......(r|-w|--x)' inside the application's data directories to

ensure that all files are not world-accessible (either read, write, or execute). The command should not print any

files. The evaluator shall also verify that no sensitive data is written to external storage which could be

read/modified by any other application.

For Android: The evaluator shall run ls -alR|grep -E '$....... (r|-w|--x)' inside the application's data directories to

ensure that all files are not world-accessible (either read, write, or execute). The command should not print any

files. The evaluator shall also verify that no sensitive data is written to external storage as this data can be



read/modified by any application containing the READ_EXTERNAL_STORAGE and/or WRITE_EXTERNAL_STORAGE

permissions.

For Windows: The evaluator shall run the SysInternals tools, Process Monitor and Access Check (or tools of

equivalent capability, like icacls.exe) for Classic Desktop applications to verify that files written to disk during an

applications installation have the correct file permissions, such that a standard user cannot modify the application

or its data files. For Windows Store Apps the evaluator shall consider the requirement met because of the

AppContainer sandbox.

For iOS: The evaluator shall determine whether the application leverages the appropriate Data Protection Class for

each data file stored locally.

For Linux: The evaluator shall run the command find . -perm /007 inside the application's data directories to ensure

that all files are not world-accessible (either read, write, or execute). The command should not print any files. For

Solaris: The evaluator shall run the command find . - perm -001 -o -perm -002 -o -perm -004 inside the

application's data directories to ensure that all files are not worldaccessible (either read, write, or execute). The

command should not print any files.

For Mac OS X: The evaluator shall run the command find . -perm +007 inside the application's data directories to

ensure that all files are not worldaccessible (either read, write, or execute). The command should not print any

files.

Test - The evaluator ran ls -alR|grep -E '$....... (r|-w|--x)' inside the application's data directories to ensure that all

files are not world-accessible (either read, write, or execute). The command did not print any files. The evaluator

also verified that no sensitive data was written to external storage.




2.4.2 SUPPORTED CONFIGURATION MECHANISM (FMT_MEC_EXT.1)

2.4.2.1 FMT_MEC_EXT.1.1








Component Testing Assurance Activities: The evaluator shall review the TSS to identify the application's

configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms

supported by the platform. The method of doing so varies per platform.

For BlackBerry: The evaluator shall run the application and make security-related changes to its configuration. The

evaluator shall check that at least one file in the app folder of the application working directory was modified to

reflect the change made.

For Android: The evaluator shall run the application and make security-related changes to its configuration. The

evaluator shall check that at least one XML file at location /data/data/package/shared_prefs/ reflects the changes

made to the configuration to verify that the application used Shared-Preferences and/or Preference-Activity

classes for storing configuration data, where package is the Java package of the application.

For Windows: The evaluator shall determine and verify that Windows Store App applications use either the

Windows.UI.ApplicationSettings namespace or the IsolatedStorageSettings namespace for storing application

specific settings. For Classic Desktop applications, the evaluator shall run the application while monitoring it with

the SysInternal tool ProcMon and make changes to its configuration. The evaluator shall verify that ProcMon logs

show corresponding changes to the the Windows Registry.

For iOS: The evaluator shall verify that the app uses the user defaults system or key-value store for storing all

settings.

For Linux: The evaluator shall run the application while monitoring it with the utility strace. The evaluator shall

make security related changes to its configuration. The evaluator shall verify that strace logs corresponding

changes to configuration files that reside in /etc (for system-specific configuration) or in the user's home directory

(for user-specific configuration).

For Solaris: The evaluator shall run the application while monitoring it with the utility dtrace. The evaluator shall

make security-related changes to its configuration. The evaluator shall verify that dtrace logs corresponding

changes to configuration files that reside in /etc (for system-specific configuration) or in the user's home

directory(for userspecific configuration).

For Mac OS X: The evaluator shall verify that the application stores and retrieves settings using the NSUserDefaults

class.

Test - The evaluator ran the application and made security relevant changes. The Shared-Preferences xml file was

updated as a result.



2.4.3 SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1)

2.4.3.1 FMT_SMF.1.1




Component TSS Assurance Activities: Conditional Activities: The evaluator shall examine the TSS to ensure that it

describes the sequence of activities that take place from an implementation perspective when this activity is

performed (for example, how it determines which resources are associated with the KEK, the decryption and re-

encryption process), and ensure that the KEK and FEK are not exposed during this change.

Cryptographic Configuration: None for this requirement.

Disable Key Recovery: If the TOE supports key recovery, this must be stated in the TSS. The TSS shall also describe

how to disable this functionality. This includes a description of how the recovery material is provided to the

recovery holder. The guidance for disabling this capability shall be described in the AGD documentation.

The TOE only supports only one management function: the ability to change passwords/passphrases.

Component Guidance Assurance Activities: Conditional Activities: The evaluator shall examine the Operational

Guidance to ensure that it describes how the password/passphrase-based authorization factor is to be changed.

Cryptographic Configuration: The evaluator shall determine from the TSS for other requirements (FCS_*,

FDP_PRT_EXT, FIA_AUT_EXT) what portions of the cryptographic functionality are configurable. The evaluator shall

then review the AGD documentation to determine that there are instructions for manipulating all of the claimed

mechanisms.

Section 6.4 of [ST] claims that the TOE includes only one management function: the ability to change

passwords/passphrases. While the other configuration actions that are available on the TOE’s configuration menu

might correspond to functionality addressed by Common Criteria requirements (e.g., timeouts and authentication

failure limits), the ASPP11 and FEEP10 do not include these requirements. Thus, these mechanisms are not

security features that must be included in FMT_SMF.1.

Component Testing Assurance Activities: Conditional Activities: The evaluator shall set all length and complexity

settings offered by the TOE. The evaluator shall then attempt to enter values that violate those settings and ensure

they are not accepted.



Disable Key Recovery: If the TOE provides key recovery capability, then the evaluator shall devise a test that

ensures that the key recovery capability has been or can be disabled following the guidance provided by the

vendor.

Cryptographic Configuration: Testing for this activity is performed for other components in this EP.

Test - The evaluator set each password complexity option one at a time to ensure each was enforced. Password

length enforcement was tested in FCS_CKM_EXT.1(A). The four complexity options tested were: require special

character, require lowercase character, require uppercase number, and require number.

There are no functions for key recovery and cryptographic configuration.

2.5 PROTECTION OF THE TSF (FPT)

2.5.1 ANTIEXPLOITATION CAPABILITIES (FPT_AEX_EXT.1)

2.5.1.1 FPT_AEX_EXT.1.1

TSS Assurance Activities: The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR

when the application is compiled.

The FPT_AEX_EXT.1 bullet in section 6.5 of [ST] describes the use of random bits as a way of varying the location of

any user-space memory mapping operation.


Testing Assurance Activities: The evaluator shall perform either a static or dynamic analysis to determine that no

memory mappings are placed at an explicit and consistent address. The method of doing so varies per platform.

For BlackBerry: The evaluator shall run the same application on two different BlackBerry systems and run a tool

that will list all memory mapped addresses for the application. The evaluator shall then verify the two different

instances share no mapping locations.

For Android: The evaluator shall run the same application on two different Android systems. Connect via ADB and

inspect /proc/PID/maps. Ensure the two different instances share no mapping locations.

For Windows: The evaluator shall run the same application on two different Windows systems and run a tool that

will list all memory mapped addresses for the application. The evaluator shall then verify the two different

instances share no mapping locations. The Microsoft sysinternals tool, VMMap, could be used to view memory

addresses of a running application. The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to

confirm that the application has ASLR enabled.



For iOS: The evaluator shall perform a static analysis to search for any mmap calls (or API calls that call mmap), and

ensure that no arguments are provided that request a mapping at a fixed address

For Linux: The evaluator shall run the same application on two different Linux systems. The evaluator shall then

compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.

For Solaris: The evaluator shall run the same application on two different Solaris systems. The evaluator shall then

compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.

For Mac OS X: The evaluator shall run the same application on two different Mac OS X systems. The evaluator shall

then compare their memory maps using vmmap PID to ensure the two different instances share no mapping

locations.

Test – The evaluator ran the app on two devices. The evaluator collected a /proc/PID/maps from each device and

compared the results. The mappings were different between the devices.

2.5.1.2 FPT_AEX_EXT.1.2



Testing Assurance Activities: The evaluator shall verify that no memory mapping requests are made with write and

execute permissions. The method of doing so varies per platform.

For BlackBerry: The evaluator shall perform static analysis on the application to verify that mmap is never invoked

with both the PROT_WRITE and PROT_EXEC permissions, and mprotect is never invoked.

For Android: The evaluator shall perform static analysis on the application to verify that mmap is never invoked

with both the PROT_WRITE and PROT_EXEC permissions, and mprotect is never invoked.

For Windows: The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the

application passes the NXCheck. The evaluator may also ensure that the /NXCOMPAT flag was used during

compilation to verify that DEP protections are enabled for the application.

For iOS: The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with

the PROT_EXEC permission.

For Linux: The evaluator shall perform static analysis on the application to verify that both mmap is never be

invoked with both the PROT_WRITE and PROT_EXEC permissions, and mprotect is never invoked with the

PROT_EXEC permission.



For Solaris: The evaluator shall perform static analysis on the application to verify that both mmap is never be

invoked with both the PROT_WRITE and PROT_EXEC permissions, and mprotect is never invoked with the

PROT_EXEC permission.

For Mac OS X: The evaluator shall perform static analysis on the application to verify that mprotect is never

invoked with the PROT_EXEC permission.

Test - The evaluator decompiled the DaR Management Service and File Browser apks. After the decompilation, the

evaluator performed a search for the mmap, mprotect permissions on the entire implementation of the

application. In both searches there were no matching results and therefore the evaluator confirmed that neither is

invoked within the implementation of the TOE.

2.5.1.3 FPT_AEX_EXT.1.3



Testing Assurance Activities: The evaluator shall configure the platform in the ascribed manner and carry out one

of the prescribed tests:

For BlackBerry: The evaluator shall ensure that the application can successfully run on the latest version of the

BlackBerry OS.

For Android: The evaluator shall ensure that the application can run with SE for Android enabled and enforcing. For

Windows: For both classic desktop and Windows Store applications, the evaluator shall configure the latest version

of Microsoft's Enhanced Mitigation Experience Toolkit (EMET) to protect the application. The evaluator shall then

run the application and verify that the application does not crash while protected by EMET.

For iOS: The evaluator shall ensure that the application can successfully run on the latest version of iOS. For Linux:

The evaluator shall ensure that the application can successfully run on a system with SELinux enabled and

enforcing. For Solaris: The evaluator shall ensure that the application can run with Solaris Trusted Extensions

enabled and enforcing. For Mac OS X: The evaluator shall ensure that the application can successfully run on the

latest version of OS X.

Test – The evaluator demonstrated TOE was running on a platform with SE for Android enabled.

2.5.1.4 FPT_AEX_EXT.1.4





Testing Assurance Activities: The evaluator shall run the application and determine where it writes its files. For

files where the user does not choose the destination, the evaluator shall check whether the destination directory

contains executable files. This varies per platform:

For BlackBerry: The evaluator shall consider the requirement met because the platform forces applications to write

all data within the application working directory (sandbox).

For Android: The evaluator shall run the program, mimicking normal usage, and note where all files are written.

The evaluator shall ensure that there are no executable files stored under /data/data/package/ where package is

the Java package of the application.

For Windows: For Windows Store Apps the evaluator shall consider the requirement met because the platform

forces applications to write all data within the application working directory (sandbox). For Windows Desktop

Applications the evaluator shall run the program, mimicking normal usage, and note where all files are written. The

evaluator shall ensure that there are no executable files stored in the same directories to which the application

wrote and no data files in the application's install directory.

For iOS: The evaluator shall consider the requirement met because the platform forces applications to write all

data within the application working directory (sandbox).

For Linux: The evaluator shall run the program, mimicking normal usage, and note where all files are written. The


wrote.

For Solaris: The evaluator shall run the program, mimicking normal usage, and note where all files are written. The


wrote.

For Mac OS X: The evaluator shall run the program, mimicking normal usage, and note where all files are written.

The evaluator shall ensure that there are no executable files stored in the same directories to which the

application wrote.

Test – The evaluator used the app to encrpt and decrypt files. The evaluator then searched the

/data/data/package/ to ensure no executables were stored there.

2.5.1.5 FPT_AEX_EXT.1.5

TSS Assurance Activities: The evaluator shall ensure that the TSS section of the ST describes the compiler flag used

to enable stack-based buffer overflow protection in the application.



The FPT_AEX_EXT.1 bullet of section 6.5 in [ST] identifies the compiler flag used to enable stack-based buffer

overflow protection.


Testing Assurance Activities: The evaluator shall perform a static analysis to verify that stackbased buffer overflow

protection is present. The method of doing so varies per platform:

For BlackBerry: The evaluator shall ensure that the fstackprotectorstrong or fstackprotectorall flags are used. The

fstackprotectorall flag is preferred but fstackprotectorstrong is acceptable.

For Android: Applications that are entirely Java run in the Java machine and do not need traditional stack

protection. For applications using Java Native Interface (JNI), the evaluator shall ensure that the -fstack-protector-

strong or -fstackprotectorall flags are used. The -fstack-protector-all flag is preferred but -fstack-protector-strong

is acceptable.

For Windows: The evaluator shall review the TSS and verify that the /GS flag was used during compilation. The

evaluator shall run a tool, like BinScope, that can verify the correct usage of /GS

For iOS: If the application is compiled using GCC or Xcode, the evaluator shall ensure that the -fstack-protector-

strong or - fstack-protector-all flags are used. The -fstack-protectorall flag is preferred but -fstack-protector-strong

is acceptable. If the application is built using any other compiler, then the evaluator shall determine that

appropriate stackprotection has been used during the build process.

For Linux: If the application is compiled using GCC, the evaluator shall ensure that the -fstack-protector-strong or -

fstackprotectorall flags are used. The -fstack-protector-all flag is preferred but -fstack-protector-strong is

acceptable. If the application is built using clang, it must be compiled and linked with the -fsanitize=address flag. If

the application is built using any other compiler, then the evaluator shall determine that appropriate

stackprotection has been used during the build process.

For Solaris: If the application is compiled using GCC, the evaluator shall ensure that the -fstack-protector-strong or

-fstackprotectorall flags are used. The -fstack-protector-all flag is preferred but -fstack-protector-strong is

acceptable. If the application is built using clang, it must be compiled and linked with the -fsanitize=address flag. If

the application is built using any other compiler, then the evaluator shall determine that appropriate

stackprotection has been used during the build process.

For Mac OS X: If the application is compiled using GCC or Xcode, the evaluator shall ensure that the -fstack-

protector-strong or - fstack-protector-all flags are used. The -fstack-protectorall flag is preferred but -fstack-

protector-strong is acceptable. If the application is built using any other compiler, then the evaluator shall

determine that appropriate stackprotection has been used during the build process.

Test – The TSS states the -fstack-protector-all compiler flag is used.






2.5.2 USE OF SUPPORTED SERVICES AND APIS (FPT_API_EXT.1)

2.5.2.1 FPT_API_EXT.1.1




Component TSS Assurance Activities: The evaluator shall verify that the TSS lists the platform APIs used in the

application.

Section 6.5 of [ST] references the [OM for a list of the platform APIs that are used by the TOE.

Component Guidance Assurance Activities: The evaluator shall then compare the list with the supported APIs

(available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS

are supported.

Section 6.5 of [ST] references the [OM for a list of the platform APIs that are used by the TOE. Appendix B of [OM]

contains a list of approximately 90 Java .crypto and .security APIs, along with 4 API provided by the Bouncy Castle

package and used by the TOE. The evaluator examined the list that was provided in [OM] and compared the APIs

in the list to the publically documented Android and Bouncy Castle APIs. Of these API all were located in the

Android Developer Reference documentation or (when appropriate) the Bouncy Castle Cryptography Library Class

reference. Thus, every API identified by the vendor was found in the public Android documentation.


2.5.3 FILE ENCRYPTION KEY (FEK) SUPPORT (FPT_FEK_EXT.1)

2.5.3.1 FPT_FEK_EXT.1.1






Component TSS Assurance Activities: In TOEs where the FEK is protected with a KEK, the FEK will need to be

encrypted and stored in non-volatile memory when not being used to decrypt/encrypt a file. (Typically, the

encrypted FEK is stored in the meta-data of the encrypted file(s).) The evaluator shall examine the TSS to ensure

that it describes how the FEK is encrypted, both after its initial creation and after it has been decrypted for use

(note that in the entirely likely possibility that the FEK is not re-encrypted, then this case must be indicated in the

TSS and the description for FCS_CKM_EXT.4 will cover disposal of the plaintext FEK). The evaluator shall further

check to ensure that the TSS describes how the FEK and any other associated meta-data necessary to decrypt the

file or set of files are associated with the resource. This description can be combined with the description required

for FCS_COP.1(5).

Section 6.5 of [ST] indicates that a FEK is stored in non-volatile memory conformant with FPT_KYP_EXT.1.


Component Testing Assurance Activities: Test 1: An example ciphertext file generated via the TOE shall be

provided to the evaluator with the accompanying FEK and prerequisite authorization information used for

encryption. The evaluator will use the TOE in conjunction with a debugging or forensics utility to attempt a decrypt

of the ciphertext file using the provided authorization information. The evaluator will then terminate processing of

the TOE and perform a search through non-volatile memory using the provided FEK string. The evaluator must

document each command, program or action taken during this process, and must confirm that the FEK was never

written to non-volatile memory. This test must be performed three times to ensure repeatability. If during the

course of this testing the evaluator finds that the FEK was written to non-volatile memory, they should be able to

identify the cause (i.e. the TOE wrote the FEK to disk, the TOE platform dumped volatile memory as a page file,

etc), and document the reason for failure to comply with the requirement.

Test - The evaluated created an encrypted file and captured the FEK. The evaluator then dumped the non-volatile

memory and searched for the KEK. The KEK was not found. The evaluator repeated this 2 more times and never

found the FEK.

2.5.4 EXTENDED: PROTECTION OF KEY AND KEY MATERIAL (FPT_KYP_EXT)

(FPT_KYP_EXT.1)

2.5.4.1 FPT_KYP_EXT.1.1






Component TSS Assurance Activities: The evaluator shall verify the TSS for a high level description of method used

to protect keys stored in non-volatile memory.

The evaluator shall verify the TSS to ensure it describes the storage location of all keys and the protection of all

keys stored in non-volatile memory. The description of the key chain shall be reviewed to ensure FCS_COP.1(5) is

followed for the storage of wrapped or encrypted keys in non-volatile memory and plaintext keys in non-volatile

memory meet one of the criteria for storage.

The FPT_KYP_EXT.1 bullet in Section 6.5 of [ST] indicates the storage and protections for keys stored in non-

volatile memory are described in the material in the FCS_STO_EXT.1 bullet of section 6.1.



2.5.5 USE OF THIRD PARTY LIBRARIES (FPT_LIB_EXT.1)

2.5.5.1 FPT_LIB_EXT.1.1






Component Testing Assurance Activities: The evaluator shall install the application and survey its installation

directory for dynamic libraries. The evaluator shall verify that libraries found to be packaged with or employed by

the application are limited to those in the assignment.

Test – The evaluator installed the application and searched for its dynamic libraries. The evaluator found

libcryptopp.so which matched the ST.

2.5.6 INTEGRITY FOR INSTALLATION AND UPDATE (FPT_TUD_EXT.1)



2.5.6.1 FPT_TUD_EXT.1.1



Testing Assurance Activities: The evaluator shall check for an update using procedures described in the

documentation and verify that the application does not issue an error. If it is updated or if it reports that no update

is available this requirement is considered to be met.

Test – The evaluator used the app to check its version. The app reported it was up to date.

2.5.6.2 FPT_TUD_EXT.1.2



Testing Assurance Activities: The evaluator shall verify that application updates are distributed in the format

supported by the platform. This varies per platform:

For BlackBerry: The evaluator shall ensure that the application is packaged in the Blackberry (BAR) format.

For Android: The evaluator shall ensure that the application is packaged in the Android application package (APK)

format.

For Windows: The evaluator shall ensure that the application is packaged in the Standard Windows Installer (MSI)

format or the Windows App Store package (APPX) format.

For iOS: The evaluator shall ensure that the application is packaged in the IPA format.

For Linux: The evaluator shall ensure that the application is packaged in the format of the package management

infrastructure of the chosen distribution. For example, applications running on Red Hat and Red Hat derivatives

should be packaged in RPM format. Applications running on Debian and Debian derivatives should be packaged in

deb format.

For Solaris: The evaluator shall ensure that the application is packaged in the PKG format.

For Mac OS X: The evaluator shall ensure that application is packaged in the DMG format, the PKG format, or the

MPKG format.

Test – The evaluator verified that the application is packaged in the Android application package (APK) format.



2.5.6.3 FPT_TUD_EXT.1.3



Testing Assurance Activities: The evaluator shall record the path of every file on the entire filesystem prior to

installation of the application, and then install and run the application. Afterwards, the evaluator shall then

uninstall the application, and compare the resulting filesystem to the initial record to verify that no files, other

than configuration, output, and audit/log files, have been added to the filesystem.

Test – The evaluator recorded every file on the filesystem prior to installation of the application, and then installed

and ran the application by performing several encryption and decrypting operations. The evaluator then

uninstalled the application and compared the resulting filesystem to the initial record. The only differences that

were seen were related to things not attributable to the TOE or files added as a result of the encryption and

decrypting operations.

2.5.6.4 FPT_TUD_EXT.1.4



Testing Assurance Activities: The evaluator shall verify that the application's executable files are not changed by

the application. The evaluator shall complete the following test:

Test 1: The evaluator shall install the application and then locate all of its executable files. The evaluator shall then,

for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application

and exercise all features of the application as described in the TSS. The evaluator shall then compare each

executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these

are identical.

Test 1 – The evaluator installed the application and saved off a copy of its executables. The evaluator then ran the

application by performing several encryption and decrypting operations. The evaluated then compared the

current executable with the saved executable and they were the same.

2.5.6.5 FPT_TUD_EXT.1.5





Testing Assurance Activities: The evaluator shall query the application for the current version of the software

according to the operational user guidance (AGD_OPE.1) and shall verify that the current version matches that of

the documented and installed version.

Test – The evaluator verified the installed and documented versions are the same.

2.5.6.6 FPT_TUD_EXT.1.6

TSS Assurance Activities: The evaluator shall verify that the TSS identifies how the application installation package

and updates to it are signed by an authorized source. The definition of an authorized source must be contained in

the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate

updates are obtained.

Section 6.5 of [ST] indicates that the TOE checks for updates by selecting the check current version option on its

menu. If an update is needed, CRC shall deliver, via email or other agreed upon method, an updated application.

The TOE’s software is digitally signed by CyberReliant. Each update is accompanied by documentation outlining

changes to the overall service, as well as compatible versions of the CRC API.






2.6 TRUSTED PATH/CHANNELS (FTP)

2.6.1 PROTECTION OF DATA IN TRANSIT (FTP_DIT_EXT.1)

2.6.1.1 FTP_DIT_EXT.1.1








Component Testing Assurance Activities: The evaluator shall perform the following tests.

Test 1: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to

remote systems or websites) while capturing packets from the application. The evaluator shall verify from the

packet capture that the traffic is encrypted with HTTPS, TLS or DTLS in accordance with the selection in the ST.

Test 2: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to

remote systems or websites) while capturing packets from the application. The evaluator shall review the packet

capture and verify that no sensitive data is transmitted in the clear.

Test 3: The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are

transmitted the evaluator shall set the credential to a known value. The evaluator shall capture packets from the

application while causing credentials to be transmitted as described in the TSS.

The evaluator shall perform a string search of the captured network packets and verify that the plaintext credential

previously set by the evaluator is not found.

Test – The TOE does not transmit any sensitive data so this test is not applicable. The evaluator performed a

packet capture while using the TOE in the FDP_DEC_EXT.1.4 test. The packet capture demonstrates the TOE does

not transmit sensitive data.



3. PROTECTION PROFILE SAR ASSURANCE ACTIVITIES

The following sections address assurance activities specifically defined in the claimed Protection Profile that

correspond with Security Assurance Requirements.

3.1 DEVELOPMENT (ADV)

3.1.1 BASIC FUNCTIONAL SPECIFICATION (ADV_FSP.1)

The information about the TOE is contained in the guidance documentation available to the end user as well as the

TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the

TSS as it relates to the functional requirements. The Assurance Activities contained in Section 5.1 of [ASPP11]

should provide the ST authors with sufficient information to determine the appropriate content for the TSS

section.

The assurance activities from section 5.1 of [ASPP11] have been performed and the analysis of the evaluator is

documented in the previous sections of this document.

3.2 GUIDANCE DOCUMENTS (AGD)

3.2.1 OPERATIONAL USER GUIDANCE (AGD_OPE.1)

Some of the contents of the operational guidance will be verified by the assurance activities in Section 5.1 of

[ASPP11] and evaluation of the TOE according to the [CEM]. The following additional information is also required.

If cryptographic functions are provided by the TOE, the operational guidance shall contain instructions for

configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a

warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC

evaluation of the TOE. The documentation must describe the process for verifying updates to the TOE by verifying

a digital signature – this may be done by the TOE or the underlying platform.

The evaluator shall verify that this process includes the following steps: Instructions for obtaining the update itself.

This should include instructions for making the update accessible to the TOE (e.g., placement in a specific

directory). Instructions for initiating the update process, as well as discerning whether the process was successful

or unsuccessful. This includes generation of the hash/digital signature. The TOE will likely contain security

functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it

clear to an administrator which security functionality is covered by the evaluation activities.



No user configuration is available for the cryptographic features of the TOE.

Appendix C of [OM] discusses the topic of a security update procedure. The library component of the TOE that is

part of other applications is delivered to customers for their integration. Updates to the TOE (i.e., CRC

Management Service) are provided via an APK which must be obtained from CRC and manually installed (or

installed via an MDM).

The guidance includes a reference to the Security Target for a description of the security features that are covered

by the Common Criteria evaluation.

3.2.2 PREPARATIVE PROCEDURES (AGD_PRE.1)

As indicated in the introduction to [FEEP10], there are significant expectations with respect to the

documentation—especially when configuring the operational environment to support TOE functional

requirements. 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 Introduction in [OM] indicates that the TOE runs on a Samsung Galaxy Note 4 with Android 4.4+.

3.3 LIFE-CYCLE SUPPORT (ALC)

3.3.1 LABELLING OF THE TOE (ALC_CMC.1)

The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number)

that specifically identifies the version that meets the requirements of the ST. 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.

Guidance documents identify a specific version of the TOE for which they are relevant.

3.3.2 TOE CM COVERAGE (ALC_CMS.1)

The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the

guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is

specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the

assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.

Lifecycle support is targeted aspects of the developer’s lifecycle and instructions to providers of applications for

the developer’s devices, rather than an indepth examination of the TSF manufacturer’s development and

configuration management process. This is not meant to diminish the critical role that a developer’s practices play

in contributing to the overall trustworthiness of a product; rather, it’s a reflection on the information to be made

available for evaluation.



The evaluator shall ensure that the developer has identified (in guidance documentation for application developers

concerning the targeted platform) one or more development environments appropriate for use in developing

applications for the developer’s platform. For each of these development environments, the developer shall

provide information on how to configure the environment to ensure that buffer overflow protection mechanisms

in the environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also

includes an indication of whether such protections are on by default, or have to be specifically enabled. The

evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and

that documentation provided by the developer in association with the requirements in the ST is associated with

the TSF using this unique identification.

The Introduction in [OM] indicates that he TOE is built to run on an Android 4.4+ mobile device (i.e., the

development environment).

Guidance documents identify a specific version of the TOE for which they are relevant.

3.3.3 TIMELY SECURITY UPDATES (ALC_TSU_EXT.1)

The evaluator shall verify that the TSS contains a description of the timely security update process used by the

developer to create and deploy security updates. The evaluator shall verify that this description addresses the

entire application. The evaluator shall also verify that, in addition to the TOE developer’s process, any third-party

processes are also addressed in the description. The evaluator shall also verify that each mechanism for

deployment of security updates is described.

The evaluator shall verify that, for each deployment mechanism described for the update process, the TSS lists a

time between public disclosure of a vulnerability and public availability of the security update to the TOE patching

this vulnerability, to include any third-party or carrier delays in deployment. The evaluator shall verify that this

time is expressed in a number or range of days.

The evaluator shall verify that this description includes the publicly available mechanisms (including either an email

address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description

of this mechanism includes a method for protecting the report either using a public key for encrypting email or a

trusted channel for a website.

The [ST] Section 6.5 states if a security vulnerability was found by a user, then the user must report it to CRC’s

email at [email protected]. In the case that the vulnerability impacts the CRC DaR API: CRC will deliver

updated API Code, as well as additional developers documentation outlining any potential changes in the

implementation. In order to deliver the final resolution to the end-user, the partner developer or customer will

need to implement the updated code into their target applications. The time for final delivery will be dependent

on their ability to update the end-user application, and to distribute to users via Mobile Device Management

Service, application store, or other delivery mechanism.

3.4 TESTS (ATE)



3.4.1 INDEPENDENT TESTING - CONFORMANCE (ATE_IND.1)

The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any

application crashes during testing. The evaluator shall determine the root cause of any application crashes and

include that information in the report. The test plan covers all of the testing actions contained in the [CEM] and 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 evaluator must

document in the test plan that each applicable testing requirement in the ST is covered. The test plan identifies the

platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan

provides a justification for not testing the platforms. This justification must address the differences between the

tested platforms and the untested platforms, and make an argument that the differences do not affect the testing

to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be

provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the

composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD

documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation

and setup of each platform either as part of a test or as a standard pretest condition. This may include special test

drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or

tool will not adversely affect the performance of the functionality by the TOE and its platform.

This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms

implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated

(IPsec, TLS, SSH). The test plan identifies high-level test objectives as well as the test procedures to be followed to

achieve those objectives. These procedures include 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 rerun of the test,

the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.

The evaluator created a proprietary Detailed Test Report (DTR) to address all aspects of this requirement. The DTR

discusses the test configuration, test cases, expected results, and test results. The evaluator used the following

test configuration:



3.5 VULNERABILITY ASSESSMENT (AVA)

3.5.1 VULNERABILITY SURVEY (AVA_VAN.1)

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 find vulnerabilities that have been found in similar applications with a

particular focus on network protocols the application uses and document formats it parses. The evaluator shall

also run a virus scanner with the most current virus definitions against the application files and verify that no files

are flagged as malicious. 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 nonapplicability, 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. If exploiting

the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable

and an appropriate justification would be formulated.

The vulnerability analysis is in the proprietary Detailed Test Report (DTR) prepared by the evaluator. The

vulnerability analysis includes a public search for vulnerabilities.

Assurance Activity Report (ASPP11/ASFEEP10) for · PDF fileAssurance Activity Report...

Documents

Transcript of Assurance Activity Report (ASPP11/ASFEEP10) for · PDF fileAssurance Activity Report...