assurance activity report (aspp11/asfeep10) for · pdf fileassurance activity report...
TRANSCRIPT
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 Page 2 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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 3 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 4 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 5 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 6 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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).
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 7 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 8 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 9 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 10 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.1.2.2 FCS_CKM_EXT.1.2
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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]).
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 11 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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:
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 12 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.1.3.2 FCS_CKM_EXT.2.2
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.1.3.3 FCS_CKM_EXT.2.3
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 13 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 14 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 15 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 16 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 17 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Component Guidance Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 18 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 19 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 20 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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 Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Requirement met by the TOE
The evaluator shall examine the TSS to ensure there is a high-level description of how the FEK is protected.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 21 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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 Guidance Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 22 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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)
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 23 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.1.8.1 FCS_IV_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Component TSS Assurance Activities:
Requirement met by the platform
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.
Requirement met by the TOE
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)..
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
2.1.9 KEY CHAINING AND KEY STORAGE (FCS_KYC_EXT.1)
2.1.9.1 FCS_KYC_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 24 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Requirement met by the platform
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.
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
2.1.10 RANDOM BIT GENERATION SERVICES (FCS_RBG_EXT.1)
2.1.10.1 FCS_RBG_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 25 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 26 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 27 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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_KYC_EXT.1 bullet in section 6.1 of [ST]
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_KYC_EXT.1 bullet in section 6.1 of [ST]
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_KYC_EXT.1 bullet in section 6.1 of [ST]
FCS_CKM_EXT.4 bullet in section 6.1 of [ST]
Component Guidance Assurance Activities: None Defined
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)
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 28 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.2.1 ENCRYPTION OF SENSITIVE APPLICATION DATA (FDP_DAR_EXT.1)
2.2.1.1 FDP_DAR_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 29 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 30 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Guidance Assurance Activities: None Defined
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,
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 31 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.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
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 32 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
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.
Testing Assurance Activities: None Defined
2.2.2.4 FDP_DEC_EXT.1.4
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 33 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.2.2.5 FDP_DEC_EXT.1.5
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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.
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
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).
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 34 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 35 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Guidance Assurance Activities: None Defined
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
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 36 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.3 IDENTIFICATION AND AUTHENTICATION (FIA)
2.3.1 USER AUTHORIZATION (FIA_AUT_EXT.1)
2.3.1.1 FIA_AUT_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Requirement met by the TOE
Nothing additional.
Requirement met by the platform
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 37 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.3.2.2 FIA_FCT_EXT.1(1).2
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.3.2.3 FIA_FCT_EXT.1(1).3
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
2.3.2.4 FIA_FCT_EXT.1(1).4
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 38 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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).
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 39 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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)
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 40 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.4.1 SECURE BY DEFAULT CONFIGURATION (FMT_CFG_EXT.1)
2.4.1.1 FMT_CFG_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 41 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
2.4.2 SUPPORTED CONFIGURATION MECHANISM (FMT_MEC_EXT.1)
2.4.2.1 FMT_MEC_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 42 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 43 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.4.3 SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1)
2.4.3.1 FMT_SMF.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 44 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 45 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 46 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 47 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Guidance Assurance Activities: None Defined
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
evaluator shall ensure that there are no executable files stored in the same directories to which the application
wrote.
For Solaris: 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.
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 48 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
The FPT_AEX_EXT.1 bullet of section 6.5 in [ST] identifies the compiler flag used to enable stack-based buffer
overflow protection.
Guidance Assurance Activities: None Defined
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 -fstackprotector- all 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 -
fstackprotector- all 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
-fstackprotector- all 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.
Component TSS Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 49 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
2.5.2 USE OF SUPPORTED SERVICES AND APIS (FPT_API_EXT.1)
2.5.2.1 FPT_API_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
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.
Component Testing Assurance Activities: None Defined
2.5.3 FILE ENCRYPTION KEY (FEK) SUPPORT (FPT_FEK_EXT.1)
2.5.3.1 FPT_FEK_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 50 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Testing Assurance Activities: None Defined
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 Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 51 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
2.5.5 USE OF THIRD PARTY LIBRARIES (FPT_LIB_EXT.1)
2.5.5.1 FPT_LIB_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
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)
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 52 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.5.6.1 FPT_TUD_EXT.1.1
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 53 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
2.5.6.3 FPT_TUD_EXT.1.3
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 54 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Component TSS Assurance Activities: None Defined
Component Guidance Assurance Activities: None Defined
Component Testing Assurance Activities: None Defined
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
TSS Assurance Activities: None Defined
Guidance Assurance Activities: None Defined
Testing Assurance Activities: None Defined
Component TSS Assurance Activities: None Defined
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 55 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
Component Guidance Assurance Activities: None Defined
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 56 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 57 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 58 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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)
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 59 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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:
Version 0.4, October 21, 2015
GSS CCT Assurance Activity Report Page 60 of 60 © 2015 Gossamer Security Solutions, Inc. Document: AAR-VID10651 All rights reserved.
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.