National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
for
PP-Configuration for
Mobile Device Fundamentals (MDF) and Virtual Private
Network (VPN) Clients, Version 1.1, 05 January 2021
Report Number: CCEVS-VR-PP-0072
Dated: 28 September 2021
Version: 1.0
National Institute of Standards and Technology National Security Agency
Information Assurance Directorate
9800 Savage Road STE 6982
Fort George G. Meade, MD 20755-6982
Information Technology Laboratory
100 Bureau Drive
Gaithersburg, MD 20899
®
TM
ACKNOWLEDGEMENTS
Common Criteria Testing Laboratory
Base and Additional Requirements
Gossamer Security Solutions, Inc.
Columbia, MD
Table of Contents
1 Executive Summary................................................................................................................. 1
2 Identification............................................................................................................................ 2
3 CFG_MDF-VPNC_V1.1 Description ..................................................................................... 4
4 Security Problem Description and Objectives......................................................................... 5
4.1 Assumptions..................................................................................................................... 5
4.2 Threats.............................................................................................................................. 5
4.3 Organizational Security Policies...................................................................................... 8
4.4 Security Objectives .......................................................................................................... 8
5 Functional Requirements....................................................................................................... 11
6 Assurance Requirements ....................................................................................................... 13
7 Results of the Evaluation....................................................................................................... 14
8 Glossary................................................................................................................................. 15
9 Bibliography.......................................................................................................................... 16
1
1 Executive Summary
This report documents the assessment of the National Information Assurance Partnership (NIAP)
validation team of the evaluation of the PP-Configuration for Mobile Device Fundamentals (MDF)
and Virtual Private Network (VPN) Clients, Version 1.1 (CFG_MDF-VPNC_V1.1). This PP-
Configuration defines how to evaluate a TOE that claims conformance to the Protection Profile
for Mobile Device Fundamentals (MDF) (PP_MDF_V3.1) Base-PP and the PP-Module for Virtual
Private Network (VPN) Clients, Version 2.2 (MOD_VPN_CLI_V2.2). It presents a summary of
the CFG_MDF-VPNC_V1.1 and the evaluation results.
Gossamer Security Solutions, Inc., located in Columbia, Maryland, performed the evaluation of
the CFG_MDF-VPNC_V1.1 and MOD_VPN_CLI_V2.2 contained within the PP-Configuration,
concurrent with the first product evaluation against the PP-Configuration’s requirements. The
evaluated product was Samsung Electronics, Co., Ltd. Samsung Galaxy Devices on Android 11 –
Fall (Samsung Galaxy devices).
This evaluation addressed the base security functional requirements of MOD_VPN_CLI_V2.2 as
part of CFG_MDF-VPNC_V1.1. The PP-Module defines additional requirements, some of which
the Samsung Galaxy devices evaluation claimed. The PP_MDF_V3.1 Base-PP was previously
validated to ensure compliance with Common Criteria requirements. The results of that evaluation
were included in Validation Report Number CCEVS-VR-PP-0041, Version 1.0, dated 16
November 2017. The Validation Report (VR) author independently performed an additional
review of the PP-Configuration and PP-Module as part of the completion of this VR, to confirm
they meet the claimed ACE requirements.
The evaluation determined the CFG_MDF-VPNC_V1.1 is both Common Criteria Part 2 Extended
and Part 3 Extended. An accredited Information Technology Security Evaluation Facility (ITSEF)
evaluated the PP-Configuration and PP-Module identified in this VR using the Common
Methodology for IT Security Evaluation (Version 3.1, Release 5) for conformance to the Common
Criteria for IT Security Evaluation (Version 3.1, Release 5). The Security Target (ST) includes
material from both PP_MDF_V3.1 and MOD_VPN_CLI_V2.2; completion of the ASE work units
satisfied the ACE work units for this PP-Module, but only for the materials defined in this PP-
Module, and only when the PP-Module is in the defined PP-Configuration.
The evaluation laboratory conducted this evaluation in accordance with the provisions of the NIAP
Common Criteria Evaluation and Validation Scheme (CCEVS). The conclusions of the testing
laboratory in the evaluation technical report are consistent with the evidence given.
2
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards and
Technology (NIST) effort to establish commercial facilities to perform trusted product evaluations.
Under this program, security evaluations are conducted by commercial testing laboratories called
CCTLs. CCTLs evaluate products against Protection Profiles (PPs) and PP-Modules that have
Evaluation Activities, which are interpretations of the Common Methodology for Information
Technology Security Evaluation (CEM) v3.1 work units specific to the technology described by
the PP or PP-Module. Products may only be evaluated against PP-Modules when a PP-
Configuration is defined to include the PP-Module with at least one corresponding Base-PP.
In order to promote thoroughness and efficiency, the evaluation of the CFG_MDF-VPNC_V1.1
and MOD_VPN_CLI_V2.2 was performed concurrent with the first product evaluation to claim
conformance to the PP-Configuration. In this case, the Target of Evaluation (TOE) was Samsung
Galaxy Devices on Android 11 – Fall, performed by Gossamer Security Solutions, Inc. in
Columbia, MD.
This evaluation addressed the base security functional requirements of MOD_VPN_CLI_V2.2 as
part of CFG_MDF-VPNC_V1.1. The PP-Module defines additional requirements, some of which
the Samsung evaluation claimed.
MOD_VPN_CLI_V2.2 contains a set of base requirements that all conformant STs must include,
and additionally contains selection-based and objective requirements. Objective requirements are
not currently prescribed by this PP-Module but are expected to be included in future versions of
the PP-Module. Vendors planning on having evaluations performed against future products are
encouraged to plan for these objective requirements to be met. Selection-based requirements are
those that must be included based upon the selections made in other requirements and the
capabilities of the TOE.
The VR authors evaluated all discretionary requirements not claimed in the initial TOE evaluation
as part of the evaluation of the ACE_REQ work units performed against the PP-Module. When an
evaluation laboratory evaluates a TOE against any additional requirements not already referenced
in this VR through an existing TOE evaluation, the VR may be amended to include reference to
this as additional evidence that the corresponding portions of the CFG_MDF-VPNC_V1.1 were
evaluated.
The following identifies the PP-Module in the PP-Configuration evaluated by this VR. It also
includes supporting information from the initial product evaluation performed against this PP-
Module.
PP-Configuration
Base-PP
PP-Configuration for Mobile Device Fundamentals (MDF) and Virtual Private Network
(VPN) Clients, Version 1.1, 05 January 2021
Protection Profile for Mobile Device Fundamentals (PP_MDF_V3.1)
Module(s) in PP-
Configuration
PP-Module for Virtual Private Network (VPN) Clients, Version 2.2, 05 January 2021
(CFG_VPNC_V2.2)
ST (Base) Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 11 – Fall Security
Target, Version 0.1, 07 July 2021
CC Version Common Criteria for Information Technology Security Evaluation, Version 3.1, Release 5
Conformance Result CC Part 2 Extended, CC Part 3 Extended
3
CCTL Gossamer Security Solutions, Inc.
Columbia, MD
4
3 CFG_MDF-VPNC_V1.1 Description
CFG_MDF-VPNC_V1.1 is a PP-Configuration that combines the following:
 Protection Profile for Mobile Device Fundamentals, Version 3.1 (PP_MDF_V3.1)
 PP-Module for Virtual Private Network (VPN) Clients, Version 2.2
(MOD_VPN_CLI_V2.2)
This PP-Configuration is for a VPN Client installed on a self-contained mobile device that is
bundled with an operating system (e.g. Android, BlackBerry OS, iOS, Windows Mobile)
according to the requirements of the PP-Configuration.
A VPN Client is a piece of software that allows a computer to establish a VPN with a remote peer
or gateway. The VPN allows for confidentiality and integrity of the network traffic that passes
over it. Specifically, MOD_VPN_CLI_V2.2 defines IPsec as the mechanism used to implement a
VPN. In the context of CFG_MDF-VPNC_V1.1, the VPN Client is a software component of a
mobile operating system that is integrated with that operating system, with the operating system
as a whole being part of a standalone mobile device.
5
4 Security Problem Description and Objectives
4.1 Assumptions
Table 1 shows the assumptions defined in the individual components of CFG_MDF-VPNC_V1.1.
Table 1: Assumptions
Assumption Name Assumption Definition
From PP_MDF_V3.1
A.CONFIG It is assumed that the TOE’s security functions are configured
correctly in a manner to ensure that the TOE security policies will be
enforced on all applicable network traffic flowing among the attached
networks.
A.NOTIFY It is assumed that the mobile user will immediately notify the
administrator if the Mobile Device is lost or stolen.
A.PRECAUTION It is assumed that the mobile user exercises precautions to reduce the
risk of loss or theft of the Mobile Device.
From MOD_VPN_CLI_V2.2
A.NO_TOE_BYPASS Information cannot flow onto the network to which the VPN client's
host is connected without passing through the TOE.
A.PHYSICAL Physical security, commensurate with the value of the TOE and the
data it contains, is assumed to be provided by the environment.
A.TRUSTED_CONFIG Personnel configuring the TOE and its operational environment will
follow the applicable security configuration guidance.
4.2 Threats
Table 2 shows the threats defined in the individual components of CFG_MDF-VPNC_V1.1.
Table 2: Threats
Threat Name Threat Definition
From PP_MDF_V3.1
T.EAVESDROP An attacker is positioned on a wireless communications channel or
elsewhere on the network infrastructure. Attackers may monitor and
gain access to data exchanged between the Mobile Device and other
endpoints.
T.NETWORK An attacker is positioned on a wireless communications channel or
elsewhere on the network infrastructure. Attackers may initiate
communications with the Mobile Device or alter communications
between the Mobile Device and other endpoints in order to
compromise the Mobile Device. These attacks include malicious
software update of any applications or system software on the device.
These attacks also include malicious web pages or email attachments,
which are usually delivered to devices over the network.
T.PHYSICAL An attacker, with physical access, may attempt to access user data on
the Mobile Device including credentials. These physical access threats
may involve attacks, which attempt to access the device through
external hardware ports, impersonate the user authentication
mechanisms, through its user interface, and also through direct and
possibly destructive access to its storage media. Note: Defending
against device re-use after physical compromise is out of scope for this
protection profile.
6
Threat Name Threat Definition
T.FLAWAPP Applications loaded onto the Mobile Device may include malicious or
exploitable code. This code could be included intentionally or
unknowingly by the developer, perhaps as part of a software library.
Malicious apps may attempt to exfiltrate data to which they have
access. They may also conduct attacks against the platform’s system
software, which will provide them with additional privileges and the
ability to conduct further malicious activities. Malicious applications
may be able to control the device's sensors (GPS, camera, microphone)
to gather intelligence about the user's surroundings even when those
activities do not involve data resident or transmitted from the device.
Flawed applications may give an attacker access to perform network-
based or physical attacks that otherwise would have been prevented.
T.PERSISTENT Persistent presence on a device by an attacker implies that the device
has lost integrity and cannot regain it. The device has likely lost this
integrity due to some other threat vector, yet the continued access by
an attacker constitutes an on-going threat in itself. In this case, the
device and its data may be controlled by an adversary as well as by its
legitimate owner.
From MOD_VPN_CLI_V2.2
T.TSF_CONFIGURATION Configuring VPN tunnels is a complex and time-consuming process,
and prone to errors if the interface for doing so is not well-specified or
well-behaved. The inability to configure certain aspects of the
interface may also lead to the mis-specification of the desired
communications policy or use of cryptography that may be desired or
required for a particular site. This may result in unintended weak or
plaintext communications while the user thinks that their data are
being protected. Other aspects of configuring the TOE or using its
security mechanisms (for example, the update process) may also result
in a reduction in the trustworthiness of the VPN client.
T.UNAUTHORIZED_ACCESS This PP-Module does not include requirements that can protect against
an insider threat. Authorized users are not considered hostile or
malicious and are trusted to follow appropriate guidance. Only
authorized personnel should have access to the system or device that
contains the IPsec VPN client. Therefore, the primary threat agents are
the unauthorized entities that try to gain access to the protected
network (in cases where tunnel mode is used) or to plaintext data that
traverses the public network (regardless of whether transport mode or
tunnel mode is used).
The endpoint of the network communication can be both
geographically and logically distant from the TOE, and can pass
through a variety of other systems. These intermediate systems may be
under the control of the adversary, and offer an opportunity for
communications over the network to be compromised.
Plaintext communication over the network may allow critical data
(such as passwords, configuration settings, and user data) to be read
and/or manipulated directly by intermediate systems, leading to a
compromise of the TOE or to the secured environmental system(s) that
the TOE is being used to facilitate communications with. IPsec can be
used to provide protection for this communication; however, there are
myriad options that can be implemented for the protocol to be
compliant to the protocol specification listed in the RFC. Some of
these options can have negative impacts on the security of the
7
Threat Name Threat Definition
connection. For instance, using a weak encryption algorithm (even one
that is allowed by the RFC, such as DES) can allow an adversary to
read and even manipulate the data on the encrypted channel, thus
circumventing countermeasures in place to prevent such attacks.
Further, if the protocol is implemented with little-used or non-standard
options, it may be compliant with the protocol specification but will
not be able to interact with other, diverse equipment that is typically
found in large enterprises.
Even though the communication path is protected, there is a possibility
that the IPsec peer could be duped into thinking that a malicious third-
party user or system is the TOE. For instance, a middleman could
intercept a connection request to the TOE, and respond to the request
as if it were the TOE. In a similar manner, the TOE could also be duped
into thinking that it is establishing communications with a legitimate
IPsec peer when in fact it is not. An attacker could also mount a
malicious man-in-the-middle-type of attack, in which an intermediate
system is compromised, and the traffic is proxied, examined, and
modified by this system. This attack can even be mounted via
encrypted communication channels if appropriate countermeasures are
not applied. These attacks are, in part, enabled by a malicious attacker
capturing network traffic (for instance, an authentication session) and
“playing back” that traffic in order to fool an endpoint into thinking it
was communicating with a legitimate remote entity.
T.UNAUTHORIZED_UPDATE Since the most common attack vector used involves attacking
unpatched versions of software containing well-known flaws,
updating the VPN client is necessary to ensure that changes to threat
environment are addressed. Timely application of patches ensures that
the client is a “hard target”, thus increasing the likelihood that product
will be able to maintain and enforce its security policy. However, the
updates to be applied to the product must be trustable in some manner;
otherwise, an attacker can write their own “update” that instead
contains malicious code of their choosing, such as a rootkit, bot, or
other malware. Once this “update” is installed, the attacker then has
control of the system and all of its data.
Methods of countering this threat typically involve hashes of the
updates, and potentially cryptographic operations (e.g., digital
signatures) on those hashes as well. However, the validity of these
methods introduces additional threats. For instance, a weak hash
function could result in the attacker being able to modify the legitimate
update in such a way that the hash remained unchanged. For
cryptographic signature schemes, there are dependencies on
1) the strength of the cryptographic algorithm used to provide the
signature, and
2) the ability of the end user to verify the signature (which typically
involves checking a hierarchy of digital signatures back to a root of
trust (a certificate authority)).
If a cryptographic signature scheme is weak, then it may be
compromised by an attacker and the end user will install a malicious
update, thinking that it is legitimate. Similarly, if the root of trust can
be compromised, then a strong digital signature algorithm will not stop
8
Threat Name Threat Definition
the malicious update from being installed (the attacker will just create
their own signature on the update using the compromised root of trust,
and the malicious update will then be installed without detection).
T.USER_DATA_REUSE Data traversing the TOE could inadvertently be sent to a different user;
since these data may be sensitive, this may cause a compromise that is
unacceptable. The specific threat that must be addressed concerns user
data that is retained by the TOE in the course of processing network
traffic that could be inadvertently re-used in sending network traffic to
a user other than that intended by the sender of the original network
traffic.
T.TSF_FAILURE Security mechanisms of the TOE generally build up from a primitive
set of mechanisms (e.g., memory management, privileged modes of
process execution) to more complex sets of mechanisms. Failure of the
primitive mechanisms could lead to a compromise in more complex
mechanisms, resulting in a compromise of the TSF.
4.3 Organizational Security Policies
Table 3 shows the organizational security policies defined in the individual components of
CFG_MDF-VPNC_V1.1.
Table 3: Organizational Security Policies
OSP Name OSP Definition
From PP_MDF_V3.1
No OSPs defined in PP_MDF_V3.1.
From MOD_VPN_CLI_V2.2
No OSPs defined in MOD_VPN_CLI_V2.2.
4.4 Security Objectives
Table 4 shows the security objectives for the TOE defined in the individual components of
CFG_MDF-VPNC_V1.1.
Table 4: Security Objectives for the TOE
TOE Security Objective TOE Security Objective Definition
From PP_MDF_V3.1
O.COMMS To address the network eavesdropping (T.EAVESDROP) and network
attack (T.NETWORK) threats described in Section 3.1 [of
PP_MDF_V3.1], concerning wireless transmission of Enterprise and
user data and configuration data between the TOE and remote network
entities, conformant TOEs will use a trusted communication path. The
TOE will be capable of communicating using one (or more) of these
standard protocols: IPsec, DTLS, TLS, HTTPS, or Bluetooth. The
protocols are specified by RFCs that offer a variety of implementation
choices. Requirements have been imposed on some of these choices
(particularly those for cryptographic primitives) to provide
interoperability and resistance to cryptographic attack.
9
TOE Security Objective TOE Security Objective Definition
While conformant TOEs must support all of the choices specified in
the ST including any optional SFRs defined in this PP, they may
support additional algorithms and protocols. If such additional
mechanisms are not evaluated, guidance must be given to the
administrator to make clear the fact that they were not evaluated.
O.STORAGE To address the issue of loss of confidentiality of user data in the event
of loss of a Mobile Device (T.PHYSICAL), conformant TOEs will use
data-at-rest protection. The TOE will be capable of encrypting data
and keys stored on the device and will prevent unauthorized access to
encrypted data.
O.CONFIG To ensure a Mobile Device protects user and enterprise data that it may
store or process, conformant TOEs will provide the capability to
configure and apply security policies defined by the user and the
Enterprise Administrator. If Enterprise security policies are configured
these must be applied in precedence of user specified security policies.
O.AUTH To address the issue of loss of confidentiality of user data in the event
of loss of a Mobile Device (T.PHYSICAL), users are required to enter
an authentication factor to the device prior to accessing protected
functionality and data. Some non-sensitive functionality (e.g.,
emergency calling, text notification) can be accessed prior to entering
the authentication factor. The device will automatically lock following
a configured period of inactivity in an attempt to ensure authorization
will be required in the event of the device being lost or stolen.
Authentication of the endpoints of a trusted communication path is
required for network access to ensure attacks are unable to establish
unauthorized network connections to undermine the integrity of the
device.
Repeated attempts by a user to authorize to the TSF will be limited or
throttled to enforce a delay between unsuccessful attempts.
O.INTEGRITY To ensure the integrity of the Mobile Device is maintained conformant
TOEs will perform self-tests to ensure the integrity of critical
functionality, software/firmware and data has been maintained. The
user shall be notified of any failure of these self-tests. This will protect
against the threat T.PERSISTENT.
To address the issue of an application containing malicious or flawed
code (T.FLAWAPP), the integrity of downloaded updates to
software/firmware will be verified prior to installation/execution of the
object on the Mobile Device. In addition, the TOE will restrict
applications to only have access to the system services and data they
are permitted to interact with. The TOE will further protect against
malicious applications from gaining access to data they are not
authorized to access by randomizing the memory layout.
O.PRIVACY In a BYOD environment (use cases 3 and 4), a personally-owned
mobile device is used for both personal activities and enterprise data.
Enterprise management solutions may have the technical capability to
monitor and enforce security policies on the device. However, the
privacy of the personal activities and data must be ensured. In addition,
10
TOE Security Objective TOE Security Objective Definition
since there are limited controls that the enterprise can enforce on the
personal side, separation of personal and enterprise data is needed.
This will protect against the T.FLAWAPP and T.PERSISTENT
threats.
From MOD_VPNC_V2.1
No TOE Objectives defined in MOD_VPNC_V2.1 beyond those in the Base-PP.
Table 5 shows the security objectives for the Operational Environment defined in the individual
components of CFG_MDF-VPNC_V1.1.
Table 5: Security Objectives for the Operational Environment
Environmental Security Objective Environmental Security Objective Definition
From PP_MDF_V3.1
OE.CONFIG TOE administrators will configure the Mobile Device security
functions correctly to create the intended security policy.
OE.NOTIFY The Mobile User will immediately notify the administrator if the
Mobile Device is lost or stolen.
OE.PRECAUTION The Mobile User exercises precautions to reduce the risk of loss or
theft of the Mobile Device.
From MOD_VPN_CLI_V2.2
OE.NO_TOE_BYPASS Information cannot flow onto the network to which the VPN client's
host is connected without passing through the TOE.
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the
data it contains, is assumed to be provided by the environment.
OE.TRUSTED_CONFIG Personnel configuring the TOE and its operational environment will
follow the applicable security configuration guidance.
11
5 Functional Requirements
As indicated above, CFG_MDF-VPNC_V1.1 includes both PP_MDF_V3.1 and
MOD_VPN_CLI_V2.2. The functional requirements from PP_MDF_V3.1 were evaluated
separately so this section applies only to requirements of MOD_VPN_CLI_V2.2.
Requirements in the MOD_VPN_CLI_V2.2 are comprised of the “base” requirements, additional
requirements that are selection-based or objective, and additional requirements that are dependent
on the Base-PP that the PP-Module is used with. The following table contains the “base”
requirements that were validated as part of the Samsung evaluation activities referenced above as
well as the additional requirements that depend on the Base-PP that is claimed. In the case of the
Samsung evaluation, only those that apply when PP_MDF_V3.1 is the Base-PP were claimed by
the TOE; those associated with other Base-PPs did not apply and have been evaluated through
evaluation of the PP-Module work unites.
Table 6: TOE Security Functional Requirements
Requirement Class Requirement Component Verified By
Applicable when the Protection Profile for General Purpose Operating Systems is the Base-PP
FCS:
Cryptographic
Support
FCS_CKM.1/VPN: Cryptographic Key Generation
(IKE)
PP-Module Evaluation
FCS_CKM_EXT.2: Cryptographic Key Storage PP-Module Evaluation
FIA: Identification
and Authentication
FIA_X509_EXT.3: X.509 Certificate Use and
Management
PP-Module Evaluation
FTP: Trusted
Path/Channels
FTP_ITC.1: Inter-TSF Trusted Channel PP-Module Evaluation
Applicable when the Protection Profile for Mobile Device Fundamentals is the Base-PP
FCS:
Cryptographic
Support
FCS_CKM.1/VPN: Cryptographic Key Generation
(IKE)
Samsung Galaxy Devices on
Android 11 – Fall
Applicable when the Protection Profile for Application Software is the Base-PP
FCS:
Cryptographic
Support
FCS_CKM_EXT.2: Cryptographic Key Storage PP-Module Evaluation
FCS_CKM_EXT.4: Cryptographic Key Destruction PP-Module Evaluation
Applicable to all TOEs
FCS:
Cryptographic
Support
FCS_IPSEC_EXT.1: IPsec Samsung Galaxy Devices on
Android 11 – Fall
FDP: User Data
Protection
FDP_RIP.2: Full Residual Information Protection Samsung Galaxy Devices on
Android 11 – Fall
FMT: Security
Management
FMT_SMF.1/VPN: Specification of Management
Functions (VPN)
Samsung Galaxy Devices on
Android 11 – Fall
FPT: Protection of
the TSF
FPT_TST_EXT.1: TSF Self-Test Samsung Galaxy Devices on
Android 11 – Fall
The following table contains the “Optional” requirements contained in Appendix A, and an
indication of how those requirements were evaluated (from the list in the Identification section
above). If no completed evaluations have claimed a given optional requirement, the VR author has
evaluated it through the completion of the relevant ACE work units and has indicated its
verification through “Module Evaluation.”
12
Table 7: Optional Requirements
Requirement Class Requirement Component Verified By
The MOD_VPN_CLI_V2.2 does not define any additional optional requirements.
The following table contains the “Selection-Based” requirements contained in Appendix B, and
an indication of what evaluation those requirements were verified in (from the list in the
Identification section above). If no completed evaluations have claimed a given selection-based
requirement, the VR author has evaluated it through the completion of the relevant ACE work
units and has indicated its verification through “Module Evaluation.”
Table 8: Selection-Based Requirements
Requirement Class Requirement Component Verified By
FIA: Identification
and Authentication
FIA_PSK_EXT.1: Pre-Shared Key Composition Samsung Galaxy Devices on Android
11 – Fall
The following table contains the “Objective” requirements contained in Appendix C, and an
indication of what evaluation those requirements were verified in (from the list in the Identification
section above). If no completed evaluations have claimed a given selection-based requirement, the
VR author has evaluated it through the completion of the relevant ACE work units and has
indicated its verification through “PP-Module Evaluation.”
Table 9: Objective Requirements
Requirement Class Requirement Component Verified By
FAU: Security
Audit
FAU_GEN.1: Audit Data Generation PP-Module Evaluation
FAU_SEL.1: Selective Audit PP-Module Evaluation
FDP: User Data
Protection
FDP_IFC_EXT.1: Subset Information Flow
Control
Samsung Galaxy Devices on Android
11 – Fall
13
6 Assurance Requirements
The PP-Configuration defines its security assurance requirements as those required by
PP_MDF_V3.1. The SARs defined in that PP are applicable to MOD_ VPN_CLI_V2.1 as well as
CFG_MDF-VPNC_V1.1 as a whole.
14
7 Results of the Evaluation
Note that for ACE elements and work units identical to ASE elements and work units, the lab
performed the ACE work units concurrent to the ASE work units.
Table 10: Evaluation Results
ACE Requirement Evaluation Verdict Verified By
ACE_INT.1 Pass Module evaluation
ACE_CCL.1 Pass Module evaluation
ACE_SPD.1 Pass Module evaluation
ACE_OBJ.1 Pass Module evaluation
ACE_ECD.1 Pass Module evaluation
ACE_REQ.1 Pass Module evaluation
ACE_MCO.1 Pass Module evaluation
ACE_CCO.1 Pass Module evaluation
15
8 Glossary
The following definitions are used throughout this document:
• Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and
approved by the CCEVS Validation Body to conduct Common Criteria-based evaluations.
• Conformance. The ability to demonstrate unambiguously that a given implementation is
correct with respect to the formal model.
• Evaluation. An IT product’s assessment against the Common Criteria using the Common
Criteria Evaluation Methodology as the supplemental guidance, interprets it in the
MOD_VPN_CLI_V2.2 Evaluation Activities to determine whether the claims made are
justified.
• Evaluation Evidence. Any tangible resource (information) required from the sponsor or
developer by the evaluator to perform one or more evaluation activities.
• Target of Evaluation (TOE). A group of IT products configured as an IT system, or an IT
product, and associated documentation that is the subject of a security evaluation under the
CC.
• Validation. The process the CCEVS Validation Body uses that leads to the issuance of a
Common Criteria certificate.
• Validation Body. A governmental organization responsible for carrying out validation and for
overseeing the day-to-day operation of the NIAP Common Criteria Evaluation and Validation
Scheme.
16
9 Bibliography
The validation team used the following documents to produce this VR:
[1] Common Criteria Project Sponsoring Organizations. Common Criteria for Information
Technology Security Evaluation: Part 1: Introduction and General Model, Version 3.1,
Revision 5, dated: April 2017.
[2] Common Criteria Project Sponsoring Organizations. Common Criteria for Information
Technology Security Evaluation: Part 2: Security Functional Requirements, Version 3.1,
Revision 5, dated: April 2017.
[3] Common Criteria Project Sponsoring Organizations. Common Criteria for Information
Technology Security Evaluation: Part 3: Security Assurance Requirements, Version 3.1,
Revision 5, dated: April 2017.
[4] Common Criteria Project Sponsoring Organizations. Common Evaluation Methodology for
Information Technology Security, Version 3.1, Revision 5, dated: April 2017.
[5] PP-Module for Virtual Private Network (VPN) Clients, Version 2.2, 05 January 2021.
[6] Protection Profile for General Purpose Operating Systems, Version 3.1, 16 June 2017.
[7] PP-Configuration for Mobile Device Fundamentals (MDF) and Virtual Private Network
(VPN) Clients, Version 1.1, 05 January 2021.
[8] Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 11 – Fall Security
Target, Version 0.1, 07 July 2021