Samsung Z VPN on v2.3 with Qualcomm Processors Common Criteria Evaluation Security Target

ST Version: 1.0 August 21, 2015

Samsung Electronics Co., Ltd. 416 Maetan-3dong, Yeongtong-gu, Suwon-si Gyeonggi-do 443-742 South Korea

Prepared By:

Cyber Assurance Testing Laboratory 900 Elkridge Landing Road, Suite 100 Linthicum, MD 21090 Security Target Samsung Z VPN on Tizen 2.3

1 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Table of Contents 1 Security Target Introduction ...... 6 1.1 ST Reference ...... 6 1.1.1 ST Identification ...... 6 1.1.2 Document Organization ...... 6 1.1.3 Terminology ...... 7 1.1.4 Acronyms ...... 8 1.1.5 Reference ...... 9 1.2 TOE Reference ...... 9 1.3 TOE Overview ...... 9 1.4 TOE Type ...... 10 2 TOE Description ...... 11 2.1 Evaluated Components of the TOE ...... 11 2.2 Components and Applications in the Operational Environment ...... 11 2.3 Physical Boundary ...... 11 2.4 Logical Boundary ...... 12 2.4.1 Cryptographic Support ...... 12 2.4.2 User Data Protection ...... 12 2.4.3 Identification and Authentication ...... 12 2.4.4 Security Management ...... 12 2.4.5 Protection of the TSF ...... 12 2.4.6 Trusted Path/Channels ...... 13 3 Conformance Claims ...... 14 3.1 CC Version ...... 14 3.2 CC Part 2 Conformance Claims ...... 14 3.3 CC Part 3 Conformance Claims ...... 14 3.4 PP Claims ...... 14 3.5 Package Claims ...... 14 3.6 Package Name Conformant or Package Name Augmented ...... 14 3.7 Conformance Claim Rationale ...... 14 4 Security Problem Definition ...... 15

2 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

4.1 Threats...... 15 4.2 Assumptions ...... 15 4.3 Security Objectives ...... 15 4.3.1 TOE Security Objectives ...... 15 4.3.2 Operational Environment Objectives ...... 16 4.4 Security Problem Definition Rationale ...... 16 5 Extended Components Definition ...... 17 5.1 Extended Security Functional Requirements ...... 17 5.2 Extended Security Assurance Requirements ...... 17 6 Security Functional Requirements ...... 18 6.1 Conventions ...... 18 6.2 Security Functional Requirements Summary...... 18 6.3 Security Functional Requirements ...... 20 6.3.1 Class FCS: Cryptographic Support ...... 20 6.3.2 Class FDP: User Data Protection (FDP) ...... 23 6.3.3 Class FIA: Identification and Authentication ...... 23 6.3.4 Class FMT: Security Management ...... 24 6.3.5 Class FPT: Protection of the TSF ...... 25 6.3.6 Class FTP: Trusted Path/Channels ...... 25 6.4 Statement of Security Functional Requirements Consistency ...... 25 7 Security Assurance Requirements ...... 27 7.1 Class ADV: Development ...... 27 7.1.1 Basic Functional Specification (ADV_FSP.1) ...... 27 7.2 Class AGD: Guidance Documentation ...... 28 7.2.1 Operational User Guidance (AGD_OPE.1) ...... 28 7.2.2 Preparative Procedures (AGD_PRE.1) ...... 29 7.3 Class ALC: Life Cycle Support ...... 29 7.3.1 Labeling of the TOE (ALC_CMC.1) ...... 29 7.3.2 TOE CM Coverage (ALC_CMS.1) ...... 30 7.4 Class ATE: Tests ...... 30 7.4.1 Independent Testing - Conformance (ATE_IND.1) ...... 30

3 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

7.5 Class AVA: Vulnerability Assessment ...... 31 7.5.1 Vulnerability Survey (AVA_VAN.1) ...... 31 8 TOE Summary Specification ...... 32 8.1 Cryptographic Support ...... 32 8.1.1 FCS_CKM.1(1): ...... 34 8.1.2 FCS_CKM.1(2): ...... 34 8.1.3 FCS_CKM_EXT.2:...... 34 8.1.4 FCS_CKM_EXT. 4:...... 34 8.1.5 FCS_COP.1(1): ...... 34 8.1.6 FCS_COP.1(2): ...... 35 8.1.7 FCS_COP.1(3): ...... 35 8.1.8 FCS_COP.1(4): ...... 35 8.1.9 FCS_IPSEC_EXT.1: ...... 35 8.1.10 FCS_RBG_EXT.1: ...... 35 8.2 User Data Protection ...... 35 8.2.1 FDP_RIP.2: ...... 35 8.3 Identification and Authentication ...... 35 8.3.1 FIA_PSK_EXT.1: ...... 35 8.3.2 FIA_X509_EXT.1: ...... 35 8.3.3 FIA_X509_EXT.2: ...... 36 8.4 Security Management ...... 36 8.4.1 FMT_SMF.1: ...... 36 8.5 Protection of the TSF ...... 37 8.5.1 FPT_TST_EXT.1: ...... 37 8.5.2 FPT_TUD_EXT.1: ...... 37 8.6 Trusted Path/Channels ...... 37 8.6.1 FTP_ITC.1: ...... 37

Table of Tables Table 1-2: CC Specific Terminology ...... 8

4 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Table 1-3: Acronym Definition ...... 9 Table 2-1: Evaluated Components of the TOE ...... 11 Table 2-2: Evaluated Components of the Operational Environment ...... 11 Table 2-3: Operational Environment System Requirements ...... 12 Table 4-1: TOE Threats ...... 15 Table 6-1: Security Functional Requirements for the TOE ...... 19 Table 8-1: TOE Keys and Secrets ...... 34

5 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

1 Security Target Introduction This chapter presents the Security Target (ST) identification information and an overview. An ST contains the Information Technology (IT) security requirements of an identified Target of Evaluation (TOE) and specifies the functional and assurance security measures offered by the TOE.

1.1 ST Reference This section provides information needed to identify and control this ST and its Target of Evaluation. This ST targets strict compliance with the following Protection Profile (PP):  Protection Profile for IPsec Virtual Private Network (VPN) Client, version 1.4 In order to achieve exact compliance with these PPs, the ST targets Evaluation Assurance Level (EAL) 1.

1.1.1 ST Identification ST Title: Samsung Z VPN on Tizen v2.3 with Qualcomm Processors ST Version: 1.0 ST Publication Date: August 21, 2015 ST Author: Booz Allen Hamilton

1.1.2 Document Organization Chapter 1 of this document provides identifying information for the ST and TOE as well as a brief description of the TOE and its associated TOE type. Chapter 2 describes the TOE in terms of its physical boundary, logical boundary, exclusions, and dependent Operational Environment components. Chapter 3 describes the conformance claims made by this ST. Chapter 4 describes the threats, assumptions, objectives, and organizational security policies that apply to the TOE. Chapter 5 defines extended Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs). Chapter 6 describes the SFRs that are to be implemented by the TSF. Chapter 7 describes the SARs that will be used to evaluate the TOE. Chapter 8 provides the TOE Summary Specification, which describes how the SFRs that are defined for the TOE are implemented by the TSF.

6 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

1.1.3 Terminology This section defines the terminology used throughout this ST. The terminology used throughout this ST is defined in Table 1-1 and 1-2. These tables are to be used by the reader as a quick reference guide for terminology definitions. Term Definition Administrator A user that has administrative privilege to configure the TOE in privileged mode. Authentication An entity designed to facilitate the authentication of an entity (user or client) that Server (AS) attempts to access a protected network. Security related information, e.g. secret and private cryptographic keys, and Critical Security authentication data such as passwords and PINs, whose disclosure or Parameter (CSP) modification can compromise the security of a cryptographic module. This cryptographic function provides a seed for a random number generator by accumulating the outputs from one or more noise sources. The functionality Entropy Source includes a measure of the minimum work required to guess a given output and tests to ensure that the noise sources are operating properly. A security function (e.g., cryptographic algorithm, cryptographic key FIPS-approved management technique, or authentication technique) that is either: 1) specified in cryptographic a Federal Information Processing Standard (FIPS), or 2) adopted in a FIPS and function specified either in an appendix to the FIPS or in a document referenced by the FIPS. Private Network A network that is protected from access by unauthorized users or entities. A TOE operational mode that allows a user to perform functions that require IT Privileged Mode Environment administrator privileges.

A network that is visible to all users and entities and does not protect against Public Network unauthorized access (e.g. internet). Security Synonymous with Authorized Administrator. Administrator Security Assurance Requirement Description of how assurance is to be gained that the TOE meets the SFR. (SAR) Security Functional Translation of the security objectives for the TOE into a standardized language. Requirement (SFR) Security Target Implementation-dependent statement of security needs for a specific identified (ST) TOE. Target of Set of software, firmware and/or hardware possibly accompanied by guidance. Evaluation (TOE) For this PP the TOE is the VPN Client. An entity that tries to harm an information system through destruction, disclosure, Threat Agent modification of data, and/or denial of service. TOE Security Combined functionality of all hardware, software, and firmware of a TOE that Functionality must be relied upon for the correct enforcement of the SFRs. (TSF) TOE Summary A description of how the TOE satisfies all of the SFRs.

7 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Specification (TSS) Trusted Channel An encrypted connection between the TOE and a trusted remote server. An entity (device or user) who has not been authorized by an authorized Unauthorized User administrator to access the TOE or private network. A TOE operational mode that only provides VPN Client functions for the VPN Unprivileged Mode Client user. The TOE allows remote users to use client computers to establish an encrypted VPN Client IPsec tunnel across an unprotected public network to a private network VPN Client User A user operating the TOE in unprivileged mode. A component that performs encryption and decryption of IP packets as they cross VPN Gateway the boundary between a private network and a public network Table 1-1: CC Specific Terminology

1.1.4 Acronyms The acronyms used throughout this ST are defined in Table 1-3. This table is to be used by the reader as a quick reference guide for acronym definitions. Acronym Definition AES Advanced Encryption Standard AF Authorization factor AS Authorization subsystem CA Certificate Authority CLI Command Line Interface CMS Central Management System COTS Commercial Off-The-Shelf CMVP Cryptographic Module Validation Program DH Diffie-Hellman DN Distinguished Name DoD Department of Defense DRBG Deterministic Random Bit Generator ECDSA Elliptic Curve Digital Signature Algorithm ES Encryption Subsystem FIPS Federal Information Processing Standards GUI Graphical User Interface ID Identification IKE Internet Key Exchange ISSE Information System Security Engineers IT Information Technology MDM Mobile Device Manager OSP Organization Security Policy PP Protection Profile PSK Pre-shared Key RGB Random Bit Generator SA Security Association SAR Security Assurance Requirements

8 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

SCP Secure Copy SFR Security Functional Requirement SPD Security Policy Database SSH Secure Shell SSL Secure Sockets Layer ST Security Target TLS Transport Layer Security TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification TOE Target of Evaluation Table 1-2: Acronym Definition

1.1.5 Reference [1] Protection Profile for IPsec Virtual Private Network (VPN) Clients, version 1.4 [2] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-001 [3] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-002 [4] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-003 [5] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-004

1.2 TOE Reference The TOE is the VPN Client implemented as part of Samsung Z with Tizen Version 2.3. 1.3 TOE Overview The Target of Evaluation (TOE) is Samsung Z with Tizen 2.3, specifically the VPN Client system service (i.e., Native App) built into Tizen. This ST focuses on the IPsec VPN capabilities of the TOE. The IPSec VPN allows users the ability to have confidentiality, integrity, and protection of data in transit over a public or private network. The TOE is a mobile operating system based on 3.4 with modifications made to increase the level of security provided to end users and enterprises. The TOE is intended to be used as part of an enterprise data solution providing mobile staff with enterprise connectivity. The TOE includes a Common Criteria mode (or “CC mode”) that an administrator can invoke through the use of a Mobile Device Management (MDM) Server or through the installation and use of the administrative application. The TOE must be configured as follows in order for an administrator to transition the TOE to CC mode:  Require a screen lock password (swipe, PIN, pattern, or facial recognition screen locks are not allowed).  The maximum password failure retry policy should be less than or equal to ten.

9 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

 Device encryption must be enabled.  SDCard encryption must be enabled.  Revocation checking must be enabled. When CC mode has been enabled, the TOE behaves as follows:  The TOE restricts the available VPN configurations to those evaluated as part of this evaluation.  The TOE restricts the use of IKEv2/IPsec cipher suites to only those conformant with the requirements of the Protection Profile for IPsec Virtual Private Network (VPN) Clients.

The TOE combines with a MDM Server solution that enables the enterprise to watch, control, and administer all deployed mobile devices, across multiple mobile service providers as well as facilitate secure communications through a VPN. This partnership provides a secure mobile environment that can be managed and controlled by the environment and reduce the risks that can be introduced through a Bring-Your-Own-Device (BYOD) model. Data on the TOE is protected through the implementation of Samsung On-Device Encryption (ODE) which utilizes FIPS 140-2 certified cryptographic modules to encrypt device and SD card storage. This functionality is combined with a number of on-device policies including local wipe, remote wipe, password complexity, automatic lock and privileged access to security configurations to prevent unauthorized access to the device and stored data.

1.4 TOE Type The TOE type for Samsung Z VPN is VPN Client. A VPN provides a protected transmission of private data between VPN Clients and VPN Gateways. The TOE defined by this PP is the VPN Client, a component executing on a remote access client, using a platform API that enables the VPN Client application to interact with other applications and the TOE platform (part of the Operational Environment of the TOE). The VPN Client is intended to be located outside or inside of a private network and provides a secure tunnel to a VPN Gateway. The tunnel provides confidentiality, integrity, and data authentication for information that travels across the public or private network.

10 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

2 TOE Description This section provides a description of the TOE in its evaluated configuration. This includes the physical and logical boundaries of the TOE.

2.1 Evaluated Components of the TOE The following table describes the TOE components in the evaluated configuration: Component Definition VPN Client System service (i.e., Native App) installed on the TOE platform that allows Application encrypted communication between itself and a VPN Gateway. Table 2-1: Evaluated Components of the TOE 2.2 Components and Applications in the Operational Environment The following table lists components and applications in the environment that the TOE relies upon in order to function properly: Component Required Definition Certificate Yes A server in the operational environment that issues digital certificates. Authority A server in the operational environment that performs encryption and VPN Gateway Yes decryption of IP packets as they cross the boundary between a private network and a public network. The Samsung Z device and the Tizen version 2.3 software on which the TOE platform Yes TOE is installed. A server in the Operational Environment that is responsible for the MDM Server No administration of Mobile Devices. Table 2-2: Evaluated Components of the Operational Environment 2.3 Physical Boundary The physical boundary of the TOE includes the TOE platform on which the TOE is installed. This platform includes the Samsung Z (SM-Z910) Mobile Device with the MSM8974 model processor of the Snapdragon 800 chipset that has the following specifications: Component Details CPU Quad-core Krait 400 CPU at up to 2.3 GHz per core GPU Qualcomm® Adreno™ 330 GPU  Integrated 4G LTE Advanced World Mode, supporting LTE FDD, LTE TDD, WCDMA (DC-HSPA+, DC-HSUPA), CDMA1x, EV-DO Rev. B, Modem TD-SCDMA and GSM/EDGE  3rd generation integrated LTE modem, with support for LTE-Broadcast 4th generation LTE multimode transceiver with Qualcomm RF360™ Front End RF solution for world mode bands, lower power and PCB reduction USB USB 2.0 BT4.0 integrated digital core

11 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

WiFi 1-stream 802.11n/ac Integrated digital core LPDDR3 800MHz Dual-channel 32-bit (12.8GBps)/eMMC 5.0 SATA3 SD 3.0 Memory/Storage (UHS-I) Table 2-3: Operational Environment System Requirements 2.4 Logical Boundary The TOE is comprised of several security features. Each of the security features identified above consists of several security functionalities, as identified below: 1. Cryptographic Support 2. User Data Protection 3. Identification and Authentication 4. Security Management 5. Protection of the TSF 6. Trusted Path/Channels

2.4.1 Cryptographic Support The IPsec implementation is the primary function of the TOE. IPSec is used by the TOE to protect communication between itself and a VPN Gateway over an unprotected network. With the exception of the IPsec implementation, the TOE relies upon the underlying TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014) for the cryptographic services specified in this Security Target.

2.4.2 User Data Protection The TOE ensures that residual information is protected from potential reuse in accessible objects such as network packets by overwriting residual information in the buffer and padding packet payloads.

2.4.3 Identification and Authentication The TOE provides the ability to use, store, and protect X.509v3 certificates as defined by RFC 5280 and pre-shared keys that are used for IPsec Virtual Private Network (VPN) connections. The TOE also supports certificate revocation handling.

2.4.4 Security Management The TOE, TOE platform, and VPN Gateway provide all functionality to manage the security functions identified throughout this Security Target. In particular, the IPsec VPN is fully configurable by a combination of functions provided directly by the TOE and those available to the associated VPN Gateway.

2.4.5 Protection of the TSF The TOE relies upon its underlying platform to perform self-tests that cover the TOE as well as the functions necessary to securely update the TOE. It performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure that they are functioning correctly. The Samsung Security Manager service invokes the self-test of the OpenSSL module at startup to ensure that those cryptographic algorithms are working correctly. If the TOE platform fails its power-up tests, the TOE platform will not

12 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3 boot into a mode where the VPN client is accessible. Additionally, the Tizen OS on the TOE platform requires that all applications bear a valid signature before Tizen will install the application.

2.4.6 Trusted Path/Channels The TOE acts as a VPN Client using IPsec to established secure channels to corresponding VPN Gateways.

13 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

3 Conformance Claims

3.1 CC Version This ST is compliant with Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 4 September 2012.

3.2 CC Part 2 Conformance Claims This ST and Target of Evaluation (TOE) is Part 2 extended to include all applicable NIAP and International interpretations through 21 August 2015.

3.3 CC Part 3 Conformance Claims This ST and Target of Evaluation (TOE) is conformant to Part 3 to include all applicable NIAP and International interpretations through 21 August 2015.

3.4 PP Claims This ST claims exact conformance to the following Protection Profiles:  Protection Profile IPsec Virtual Private Network (VPN) Client, version 1.4

3.5 Package Claims The TOE claims exact conformance to a Protection Profile that is conformant with CC Part 3.

3.6 Package Name Conformant or Package Name Augmented This ST claims exact conformance with a Protection Profile. The ST is conformant to the claimed package.

3.7 Conformance Claim Rationale The PP states the following: “This document specifies Security Functional Requirements (SFRs) for a VPN Client. A VPN provides a protected transmission of private data between VPN Clients and VPN Gateways”. The TOE is a VPN Client on a mobile device. Therefore, the conformance claim is appropriate.

14 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

4 Security Problem Definition

4.1 Threats This section identifies the threats against the TOE. These threats have been taken from the PP. Threat Threat Definition Failure to allow configuration of the TSF may prevent its users T.TSF_CONFIGURATION from being able to adequately implement their particular security policy, leading to a compromise of user information. Security mechanisms of the TOE may fail, leading to a compromise T.TSF_FAILURE of the TSF. A user may gain unauthorized access to the TOE data. A malicious user, process, or external IT entity may masquerade as an authorized entity in order to gain unauthorized access to data or T.UNAUTHORIZED_ACCESS TOE resources. A malicious user, process, or external IT entity may misrepresent itself as the TOE to obtain identification and authentication data. A malicious party attempts to supply the end user with an update to T.UNAUTHORIZED_UPDATE the product that may compromise the security features of the TOE. User data may be inadvertently sent to a destination not intended by T.USER_DATA_REUSE the original sender because it is not rendered inaccessible after it is done being used. Table 4-1: TOE Threats 4.2 Assumptions These assumptions are made on the operational environment in order to be able to ensure that the security functionality specified in the PP can be provided by the TOE. If the TOE is placed in an operational environment that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality. Assumption Description of Assumption Information cannot flow onto the network to which the VPN A.NO_TOE_BYPASS Client's host is connected without passing through the TOE. Physical security, commensurate with the value of the TOE and the A.PHYSICAL data it contains, is assumed to be provided by the environment. Personnel configuring the TOE and its operational environment A.TRUSTED_CONFIG will follow the applicable security configuration guidance. Table 4-2: TOE Assumptions 4.3 Security Objectives This section identifies the security objectives of the TOE and its supporting environment. The security objectives identify the responsibilities of the TOE and its environment in meeting the security needs.

4.3.1 TOE Security Objectives This section identifies the security objectives of the TOE. These objectives have been taken from the Protection Profile for IPsec Virtual Private Network (VPN) Clients. The following table contains the objectives defined in the PP:

15 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Objective Objective Definition The TOE will provide a network communication channel protected O.VPN_TUNNEL by encryption that ensures that the VPN Client communicates with an authenticated VPN Gateway. O.RESIDUAL_INFORMATION The TOE will ensure that any data contained in a protected _CLEARING resource is not available when the resource is reallocated.

O.TOE_ADMINISTRATION The TOE will provide mechanisms to allow administrators to be able to configure the TOE. The TOE will provide the capability to test some subset of its O.TSF_SELF_TEST security functionality to ensure it is operating properly. The TOE will provide the capability to help ensure that any updates O.VERIFIABLE_UPDATES to the TOE can be verified by the administrator to be unaltered and (optionally) from a trusted source. Table 4-3: TOE Security Objectives

4.3.2 Operational Environment Objectives The Operational Environment of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). This section defines the security objectives that are to be addressed by the IT domain or by non- technical or procedural means. As indicated above, if requirements supporting an objective on the TOE (in the previous table) are implemented in whole or in part by the platform, the ST should indicate this by an entry in this table with that objective. Objective Objective Definition Information cannot flow onto the network to which the VPN OE.NO_TOE_BYPASS Client's host is connected without passing through the TOE. Physical security, commensurate with the value of the TOE and the OE.PHYSICAL data it contains, is assumed to be provided by the operational

environment. Personnel configuring the TOE and its operational environment OE.TRUSTED_CONFIG will follow the applicable security configuration guidance. Table 4-4: TOE Operational Environment Objectives 4.4 Security Problem Definition Rationale The assumptions, threats, OSPs, and objectives that are defined in this ST represent the assumptions, threats, OSPs, and objectives that are specified in the Protection Profile to which the TOE claims conformance. The associated mappings of assumptions to environmental objectives, SFRs to TOE objectives, and OSPs and objectives to threats are therefore identical to the mappings that are specified in the claimed Protection Profile.

16 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

5 Extended Components Definition

5.1 Extended Security Functional Requirements The extended Security Functional Requirements that are claimed in this ST are taken directly from the PP to which the ST and TOE claim conformance. These extended components are formally defined in the PP in which their usage is required.

5.2 Extended Security Assurance Requirements There are no extended Security Assurance Requirements in this ST.

17 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

6 Security Functional Requirements

6.1 Conventions The CC permits four functional component operations—assignment, refinement, selection, and iteration—to be performed on functional requirements. This ST will highlight the operations in the following manner:  Assignment: allows the specification of an identified parameter. Indicated with bold and italicized text.  Refinement: allows the addition of details. Indicated with italicized text.  Selection: allows the specification of one or more elements from a list. Indicated with underlined text.  Iteration: allows a component to be used more than once with varying operations. Indicated with a sequential number in parentheses following the element number of the iterated SFR. When multiple operations are combined, such as an assignment that is provided as an option within a selection or refinement, a combination of the text formatting is used. If SFR text is reproduced verbatim from text that was formatted in a claimed PP (such as if the PP’s instantiation of the SFR has a refinement or a completed assignment), the formatting is not preserved. This is so that the reader can identify the operations that are performed by the ST author as opposed to the PP author.

6.2 Security Functional Requirements Summary The following table lists the SFRs claimed by the TOE: Component Class Name Component Name Identification Cryptographic Key Generation FCS_CKM.1(1) (Asymmetric Keys) Cryptographic Key Generation (for FCS_CKM.1(2) asymmetric keys – IKE) FCS_CKM_EXT.2 Cryptographic Key Storage FCS_CKM_EXT.4 Cryptographic Key Zeroization Cryptographic operation (Data Encryption FCS_COP.1(1) /Decryption) Cryptographic Support Cryptographic operation (for cryptographic FCS_COP.1(2) signature) Cryptographic operation (Cryptographic FCS_COP.1(3) Hashing) Cryptographic operation (Keyed-Hash FCS_COP.1(4) Message Authentication) Internet Protocol Security (IPsec) FCS_IPSEC_EXT.1 Communications FCS_RBG_EXT.1 Cryptographic Operation (Random Bit

18 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Component Class Name Component Name Identification Generation) User Data Protection FDP_RIP.2 Full Residual Information Protection FIA_PSK_EXT.1 Pre-Shared Key Composition Identification and FIA_X509_EXT.1 X.509 Certificate Validation Authentication FIA_X509_EXT.2 X.509 certificate authentication Security Management FMT_SMF.1 Specification of Management Functions FPT_TST_EXT.1 TSF Cryptographic Functionality Testing Protection of the TSF FPT_TUD_EXT.1 Trusted Update Trusted Path /Channels FTP_ITC.1 Inter-TSF trusted channel Table 6-1: Security Functional Requirements for the TOE

19 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

6.3 Security Functional Requirements

6.3.1 Class FCS: Cryptographic Support

6.3.1.1 FCS_CKM.1(1) Cryptographic Key Generation

FCS_CKM.1.1 (1) The [TOE platform] shall generate asymmetric cryptographic keys used for key establishment in accordance with  NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for finite field-based key establishment schemes;  NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic curve-based key establishment schemes and implementing “NIST curves” P-256, P-384 and [P-521] (as defined in FIPS PUB 186-4, “Digital Signature Standard”)  [NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography” for RSA-based key establishment schemes] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. See NIST Special Publication 800-57, “Recommendation for Key Management” for information about equivalent key strengths.

6.3.1.2 FCS_CKM.1(2) Cryptographic Key Generation(for asymmetric keys - IKE)

FCS_CKM.1.1(2) The [TOE platform] shall generate asymmetric cryptographic keys used for IKE peer authentication in accordance with a:  [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA schemes and implementing “NIST curves” P-256, P-384 and [P-521];  ANSI X9.31-1998, Appendix A.2.4 Using AES for RSA schemes] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits.

6.3.1.3 FCS_CKM_EXT.2 Cryptographic Key Distribution

FCS_CKM_EXT.2.1 The [TOE platform] shall store persistent secrets and private keys when not in use in platform- provided key storage.

6.3.1.4 FCS_CKM_EXT.4 Cryptographic Key Zeroization

FCS_CKM_EXT.4.1

20 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

The [TOE platform] shall zeroize all plaintext secret and private cryptographic keys and CSPs when no longer required.

6.3.1.5 FCS_COP.1(1) Cryptographic operation (Data Encryption /Decryption)

FCS_COP.1.1(1) The [TOE platform] shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm AES operating in GCM and CBC mode with cryptographic key sizes 128- bits and 256-bits that meets the following:  FIPS PUB 197, “Advanced Encryption Standard (AES)”  NIST SP 800-38D, NIST SP 800-38A.

6.3.1.6 FCS_COP.1(2) Cryptographic operation (for cryptographic signature)

FCS_COP.1.1(2) The [TOE platform] shall perform cryptographic signature services in accordance with a specified cryptographic algorithm:  [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA scheme  FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA schemes and implementing “NIST curves” P-256, P-384 and [P-521]] and cryptographic key sizes [equivalent to, or greater than, a symmetric key strength of 112 bits].

6.3.1.7 FCS_COP.1(3) Cryptographic operation (Cryptographic Hashing)

FCS_COP.1.1(3) The [TOE platform] shall perform [cryptographic hashing services] in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [160, 256, 384, 512] bits that meet the following: FIPS Pub 180-4, “Secure Hash Standard.”

6.3.1.8 FCS_COP.1(4) Cryptographic operation (Keyed-Hash Message Authentication)

FCS_COP.1.1(4) The [TOE platform] shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC- [SHA-1, SHA-256, SHA-384, SHA-512], key size [key size > block size, key size = block size, key size < block size], and message digest size of [160, 256, 384, 512] bits that meet the following: FIPS PUB 198-1, “The Keyed-Hash Message Authentication Code”, and FIPS PUB 180-4, “Secure Hash Standard”.

6.3.1.9 FCS_IPSEC_EXT.1 Internet Protocol Security (IPsec) Communications

FCS_IPSEC_EXT.1.1 The [TOE] shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 The [TOE] shall implement [tunnel mode].

21 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

FCS_IPSEC_EXT.1.3 The [TOE] shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. FCS_IPSEC_EXT.1.4 The [TOE] shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms AES-GCM-128, AES-GCM-256 as specified in RFC 4106, [AES-CBC-128, AES-CBC- 256 (both specified by RFC 3602) together with a Secure Hash Algorithm (SHA)-based HMAC]. FCS_IPSEC_EXT.1.5 The [TOE] shall implement the protocol: [IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified in section 2.23), 4307, and [no other RFCs for hash functions]]. FCS_IPSEC_EXT.1.6 The [TOE] shall ensure the encrypted payload in the [IKEv2] protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and [AES-GCM-128, AES- GCM-256 as specified in RFC 5282]. FCS_IPSEC_EXT.1.7 The [TOE] shall ensure that IKEv1 Phase 1 exchanges use only main mode. FCS_IPSEC_EXT.1.8 The [TOE] shall ensure that [IKEv2 SA lifetimes can be configured by [VPN Gateway] based on [number of packets/number of bytes]] FCS_IPSEC_EXT.1.9 The [TOE] shall generate the secret value x used in the IKE Diffie-Hellman key exchange (“x” in gx mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having a length of at least [224, 256 or 384] bits. FCS_IPSEC_EXT.1.10 The [TOE] shall generate nonces used in IKE exchanges in a manner such that the probability that a specific nonce value will be repeated during the life a specific IPsec SA is less than 1 in 2^[112, 128 or 192 bits]. FCS_IPSEC_EXT.1.11 The [TOE] shall ensure that all IKE protocols implement DH Groups 14 (2048-bit MODP), 19 (256- bit Random ECP), and [5 (1536-bit MODP), 24 (2048-bit MODP with 256-bit POS), 20 (384-bit Random ECP)]. FCS_IPSEC_EXT.1.12 The [TOE] shall ensure that all IKE protocols perform peer authentication using a [RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys]. FCS_IPSEC_EXT.1.13

22 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

The [TOE] shall not establish an SA if the distinguished name (DN) contained in a certificate does not match the expected DN for the entity attempting to establish a connection. FCS_IPSEC_EXT.1.14 The [VPN Gateway] shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 CHILD_SA] connection.

6.3.1.10 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)

FCS_RBG_EXT.1.1 The [TOE platform] shall perform all deterministic random bit generation services in accordance with [NIST Special Publication 800-90A using [CTR_DRBG (AES)]]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by an entropy source that accumulates entropy from [a platform-based RBG] with a minimum of [256 bits] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.

6.3.2 Class FDP: User Data Protection (FDP)

6.3.2.1 FDP_RIP.2 Full Residual Information Protection

FDP_RIP.2.1 The [TOE] shall enforce that any previous information content of a resource is made unavailable upon the [allocation of the resource to] all objects.

6.3.3 Class FIA: Identification and Authentication

6.3.3.1 FIA_PSK_EXT.1 Pre-Shared Key Composition

FIA_PSK_EXT.1.1 The [TOE] shall be able to use pre-shared keys for IPsec. FIA_PSK_EXT.1.2 The [TOE] shall be able to accept text-based pre-shared keys that: are a minimum of 11 characters and [[up to 64 characters]]; composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”). FIA_PSK_EXT.1.3 The [TOE] shall [be able to [accept] bit-based pre-shared keys].

6.3.3.2 FIA_X509_EXT.1 X.509 Certificate Validation

FIA_X509_EXT.1.1

23 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

The [TOE] shall validate certificates in accordance with the following rules:  Perform RFC 5280 certificate validation and certificate path validation.  Validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 2560].  Validate the certificate path by ensuring the basicConstraints extension is present and the cA flag is set to TRUE for all CA certificates.  Validate the extendedKeyUsage field according to the following rules: o Certificates used for [no other purpose] shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3). FIA_X509_EXT.1.2 The [TOE] shall only treat a certificate as a CA certificate if the following is met: the basicConstraints extension is present and the CA flag is set to TRUE.

6.3.3.3 FIA_X509_EXT.2 X509 certificate authentication

FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for IPsec exchanges, and [no additional uses]. FIA_X509_EXT.2.2 When a connection to determine the validity of a certificate cannot be established, the [TOE] shall [not accept the certificate]. FIA_X509_EXT.2.3 The [TOE] shall not establish an SA if a certificate or certificate path is deemed invalid.

6.3.4 Class FMT: Security Management

6.3.4.1 FMT_SMF.1 Specification of Management Functions

FMT_SMF.1.1 The [TOE, TOE platform, VPN Gateway] shall be capable of performing the following management functions:  Configuration of IKE protocol version(s) used,  Configure IKE authentication techniques used,  Configure the cryptoperiod for the established session keys. The unit of measure for configuring the cryptoperiod shall be no greater than an hour,  Configure certificate revocation check,  Specify the algorithm suites that may be proposed and accepted during the IPsec exchanges,  load X.509v3 certificates used by the security functions in this PP,  ability to update the TOE, and to verify the updates,  ability to configure all security management functions identified in other sections of this PP,  [no other actions].

24 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

6.3.5 Class FPT: Protection of the TSF

6.3.5.1 FPT_TST_EXT.1 TSF Cryptographic Functionality Testing

FPT_TST_EXT.1.1 The [TOE platform] shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct operation of the TSF. FPT_TST_EXT.1.2 The [TOE platform] shall provide the capability to verify the integrity of stored TSF executable code when it is loaded for execution through the use of the [cryptographic signature and hash for integrity].

6.3.5.2 FPT_TUD_EXT.1 Trusted Update

FPT_TUD_EXT.1.1 The [TOE platform] shall provide the ability to query the current version of the TOE firmware/software. FPT_TUD_EXT.1.2 The [TOE platform] shall provide the ability to initiate updates to TOE firmware/software. FPT_TUD_EXT.1.3 The [TOE platform] shall provide a means to verify firmware/software updates to the TOE using a digital signature mechanism and [no other functions] prior to installing those updates.

6.3.6 Class FTP: Trusted Path/Channels

6.3.6.1 FTP_ITC.1 Inter-TSF trusted channel

FTP_ITC.1.1 The [TOE] shall use IPsec to provide a trusted communication channel between itself and a VPN Gateway that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. FTP_ITC.1.2 The [TOE] shall permit the TSF to initiate communication via the trusted channel. FTP_ITC.1.3 The [TOE] shall initiate communication via the trusted channel for all traffic traversing that connection. 6.4 Statement of Security Functional Requirements Consistency The Security Functional Requirements included in the ST represent all required SFRs specified in the PPs against which strict conformance is claimed and a subset of the optional SFRs. All hierarchical

25 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3 relationships, dependencies, and unfulfilled dependency rationales in the ST are considered to be identical to those that are defined in the claimed PP.

26 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

7 Security Assurance Requirements This section identifies the Security Assurance Requirements (SARs) that are claimed for the TOE. The SARs which are claimed are consistent with the conformance claim of the Protection Profile.

7.1 Class ADV: Development

7.1.1 Basic Functional Specification (ADV_FSP.1)

7.1.1.1 Developer action elements:

ADV_FSP.1.1D The developer shall provide a functional specification. ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs.

7.1.1.2 Content and presentation elements:

ADV_FSP.1.1C The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2C The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.3C The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

7.1.1.3 Evaluator action elements:

ADV_ FSP.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_ FSP.1.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.

27 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

7.2 Class AGD: Guidance Documentation

7.2.1 Operational User Guidance (AGD_OPE.1)

7.2.1.1 Developer action elements:

AGD_OPE.1.1D The developer shall provide operational user guidance.

7.2.1.2 Content and presentation elements:

AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. AGD_OPE.1.7C The operational user guidance shall be clear and reasonable.

7.2.1.3 Evaluator action elements:

AGD_OPE.1.1E

28 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

7.2.2 Preparative Procedures (AGD_PRE.1)

7.2.2.1 Developer action elements:

AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.

7.2.2.2 Content and presentation elements:

AGD_ PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_ PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

7.2.2.3 Evaluator action elements:

AGD_ PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_ PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.

7.3 Class ALC: Life Cycle Support

7.3.1 Labeling of the TOE (ALC_CMC.1)

7.3.1.1 Developer action elements:

ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE.

7.3.1.2 Content and presentation elements:

ALC_CMC.1.1C The TOE shall be labeled with its unique reference.

29 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

7.3.1.3 Evaluator action elements:

ALC_CMC.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

7.3.2 TOE CM Coverage (ALC_CMS.1)

7.3.2.1 Developer action elements:

ALC_CMS.1.1D The developer shall provide a configuration list for the TOE.

7.3.2.2 Content and presentation elements:

ALC_CMS.1.1C The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs. ALC_CMS.1.2C The configuration list shall uniquely identify the configuration items.

7.3.2.3 Evaluator action elements:

ALC_CMS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

7.4 Class ATE: Tests

7.4.1 Independent Testing - Conformance (ATE_IND.1)

7.4.1.1 Developer action elements:

ATE_IND.1.1D The developer shall provide the TOE for testing.

7.4.1.2 Content and presentation elements:

ATE_IND.1.1C The TOE shall be suitable for testing.

7.4.1.3 Evaluator action elements:

ATE_IND.1.1E

30 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1.2E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.

7.5 Class AVA: Vulnerability Assessment

7.5.1 Vulnerability Survey (AVA_VAN.1)

7.5.1.1 Developer action elements:

AVA_VAN.1.1D The developer shall provide the TOE for testing.

7.5.1.2 Content and presentation elements:

AVA_VAN.1.1C The TOE shall be suitable for testing.

7.5.1.3 Evaluator action elements:

AVA_VAN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VAN.1.2E The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. AVA_VAN.1.3E The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.

31 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

8 TOE Summary Specification The following sections identify the security functions of the TOE and describe how the TSF meets each claimed SFR. 8.1 Cryptographic Support The TOE implements the IPsec protocol as specified in RFC 4301; however, the TOE presents as few configuration options as possible to the user in order to minimize the possibility of misconfiguration and relies upon the VPN Gateway to enforce organizational policies (e.g., specific cipher suites and selection of traffic to protect). For this reason, the TOE does not support editing of its Security Policy Database (SPD) entries. The TOE will insert a PROTECT rule to ensure that the TOE protects traffic destined for the VPN Gateway (as the TOE ignores the IKEv2 Traffic Selector negotiated between the client and gateway and always sends all traffic) with IPsec. The TOE routes all packets through the kernel’s IPsec interface when the VPN is active. The kernel compares packets routed through this interface to the SPDs configured for the VPN to determine whether to PROTECT, BYPASS, or DISCARD each packet. The vendor designed the TOE’s VPN, when operating in CC Mode, to allow no configuration and to always force all traffic through the VPN. The TOE ignores any IKEv2 Traffic Selector negotiations with the VPN GW and will always create an SPD PROTECT rule that matches all traffic. Thus, the kernel will match all packets, subsequently encrypt those packets, and finally forward them to the VPN Gateway. The TOE supports tunnel mode for its IPsec connections. The TOE provides IKEv2 key establishment as part of its IPsec implementation. The IKEv2 implementation is conformant with RFCs 5996 and 4307 and supports NAT traversal. The TOE implements RFC 4106 conformant AES-GCM-128, and AES-GCM-256, and RFC 3602 conformant AES-CBC-128, and AES-CBC-256 as encryption algorithms. The TOE also implements HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 as integrity/authentication algorithms as well as Diffie-Hellman Groups 5, 14, 19, 20 and 24. The encrypted payload for IKEv2 uses AES-CBC-128, AES-CBC-256, as specified in RFC 6379 and AES-GCM-128, AES-GCM-256, as specified in RFC 5282. The TOE relies upon the VPN Gateway to ensure that by default the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the IKEv2 IKE_SA connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the IKEv2 CHILD_SA connection. The cryptographic signature services are performed by the TOE platform using the RSA and ECDSA schemes specified in FIPS PUB 186-4 with cryptographic key sizes that are greater than or equal to a symmetric key strength of 112 bits. The ECDSA scheme implements NIST curves P-356, 384 and 521. The TOE utilizes the cryptographic algorithm implementation of the TOE platform by linking against the native OpenSSL cryptographic library. In this way, then TOE can invoke the cryptographic operations provided by the TOE platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). An administrator can configure the VPN Gateway to limit SA lifetimes based on the number of packets/number of bytes transmitted. The TOE and VPN Gateway will rekey their SAs after the SAs exceed the VPN Gateway configured packet/byte limit. The TOE generates the secret value x used in the IKEv2 Diffie-Hellman key exchange ('x' in gx mod p) using the FIPS validated RBG specified in FCS_RBG_EXT.1 and having possible lengths of 224, 256, or

32 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

384 bits. When a random number is needed for a nonce, the probability that a specific nonce value will be repeated during the life a specific IPsec SA is less than 1 in 2112, 2128, or 2192. The TOE implements peer authentication using RSA certificates or ECDSA certificates that conform to RFC 4945 and FIPS 186-4 or by using pre-shared keys. If certificates are used, the TOE ensures that if the distinguished name (DN) contained in a certificate matches the expected DN for the entity attempting to establish a connection and ensures that the certificate has not been revoked (using the Online Certificate Status Protocol (OCSP) in accordance with RFC 2560). Pre-shared keys can include any letter from a-z, A-Z, the numbers 0-9, and the following special characters:

! @ # $ % ^ & * ( )

The TOE supports pre-shard keys with lengths between 11 and 64 characters. The TOE does not perform any processing on pre-shared keys and will use the pre-shared key as they were entered by the user. When entering a pre-shared key, the user may specify whether it is parsed as ASCII or as a hexadecimal (bit- based) key. The following table describes the keys and secrets utilized by the TOE.

Key Name Origin/ Purpose Storage Location Cleared Upon: Type of Clearing RFC defined parameters DH Group hardcoded into the Parameters TSF/used in the TOE N/A – Public values N/A – Public values (DH 14, 19, 5, ephemeral Diffie- 24, 20) Hellman key exchange Entered by the IPsec Pre- TOE Platform user/used for peer On wipe function Crypto erase Shared Keys Keystore authentication User IPsec Entered by the TOE Platform X.509v3 Certs user/used for client On wipe function Crypto erase Keystore (RSA/ECDSA) authentication Entered by the CA IPsec user/used to TOE Platform X.509v3 Certs N/A – public values N/A -public values authenticate the Keystore (RSA/ECDSA) Gateway Generated as part of IKEv2 IKEv2 IKE_SA IKE_SA Enc No longer needed establishment/used TOE platform Zero overwrite Keys (AES by trusted channel to encipher/decipher CBC or GCM) traffic IKEv2 Generated as part of IKE_SA MAC IKEv2 IKE_SA No longer needed Memory Zero overwrite Keys (HMAC- establishment/used by trusted channel SHA) for traffic integrity IKEv2 Generated as part of CHILD_SA IKEv2 CHILD_SA No longer needed Enc Keys establishment/ used Memory Zero overwrite by trusted channel (AES CBC or to encipher/decipher GCM) traffic

33 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

IKEv2 Generated as part of CHILD_SA IKEv2 CHILD_SA No longer needed Memory Zero overwrite MAC Keys establishment/ used by trusted channel (HMAC-SHA) for traffic integrity Table 8-1: TOE Keys and Secrets

The TOE supports a number of different Diffie-Hellman (DH) groups for use in SA negotiation including DH Groups 5 (1536-bit MODP), 14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit Random ECP), and 24 (2048-bit MODP with 256-bit POS). The TOE selects the DH group by selecting the largest group configured by an administrator that is offered by the VPN Gateway. During the Peer Authentication stage of IPsec, the TOE will verify the authenticity of the VPN Gateway’s X.509v3 certificate by validating the certificate, validating the certificate path, validating the certificates revocation status using OCSP, validating that the certificate path terminates in a trusted Certificate Authority (CA) certificate, and validating that the CA certificate has the basicConstraints extension present and the CA flag set to true. The TOE depends on the VPN Gateway to ensure that the cryptographic algorithms and key sizes negotiated during the IKEv2 negotiation ensure that the security strength of the IKE_SA are greater than or equal to that of the CHILD_SA. The Cryptographic Support function is designed to satisfy the following security functional requirements:

8.1.1 FCS_CKM.1(1): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.2 FCS_CKM.1(2): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.3 FCS_CKM_EXT.2: This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.4 FCS_CKM_EXT. 4: This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.5 FCS_COP.1(1): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

34 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

8.1.6 FCS_COP.1(2): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.7 FCS_COP.1(3): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.8 FCS_COP.1(4): This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014).

8.1.9 FCS_IPSEC_EXT.1: The TOE implements IPsec in accordance with FCS_IPSEC_EXT.1 as described in Section 8.1.

8.1.10 FCS_RBG_EXT.1: This requirement is satisfied by the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1 12 February 2014). 8.2 User Data Protection

8.2.1 FDP_RIP.2: The TOE ensures that past remnants of resource information that are used for new objects are not discernible in any new object, such as network packets. When the TOE allocates a new buffer for either an incoming or outgoing a network packet, the new packet data will be used to overwrite any previous data in the buffer. If an allocated buffer exceeds the size of the packet, and additional space will be overwritten (padded) with zeroes before the packet is forwarded (to the external network or delivered to the appropriate, internal application). 8.3 Identification and Authentication

8.3.1 FIA_PSK_EXT.1: The TOE supports the use of pre-shared keys (the TOE allows 11 to 64 character PSKs) for IPsec VPNs. The usage of pre-shared keys within the IPsec implementation is described in Section 8.1.

8.3.2 FIA_X509_EXT.1: This requirement is satisfied by the TOE, which performs all needed certificate validation (including the certificate, its path, and its revocation status). The TOE requires that for each VPN connection, the user will specify the client certificate that the TOE will use (the user must have previously loaded such a certificate into the keystore) and specify the CA certificate to which the server’s certificate must chain. The TOE thus uses the specified certificate when attempting to establish that VPN connection. The TOE validates authentication certificates (including the full path) and checks their revocation station using OCSP. The TOE processes a VPN connection to a server by first comparing the Identification (ID)

35 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

Payload received from the server against the certificate sent by the server, and if the DN of the certificate does not match the ID, then the TOE does not establish the connection. If the server’s certificate matches the ID, then the TOE validates that it can construct a certificate path from the server’s certificate through any intermediary CAs to the CA certificate specified by the user in the VPN configuration. If the TOE can successfully build the certificate path, then the TOE will check the validity of the certificates (e.g., checking its validity dates and that the CA flag is present in the basic constraints section for all CA certs).

8.3.3 FIA_X509_EXT.2: The TOE checks the revocation status of all certificates (starting with the server’s certificate and working up the chain) assuming that the certificates are valid. The TOE will reject any certificate for which it cannot determine the validity and reject the connection attempt. Section 8.1 describes how the TOE uses certificates in its IPsec architecture. 8.4 Security Management

8.4.1 FMT_SMF.1: The following security management functions are provided directly by the TOE, are implemented in the VPN Gateway or are implemented by the TOE platform; as defined below:  The TOE provides functions allowing the user to select VPN Gateway and credentials used to connect to those VPN Gateways.  The TOE selects the IKE protocol version (only supports IKEv2)  The VPN Gateway (acting as an administrator) to which the TOE connects selects the authentication techniques.  The VPN Gateway (acting as an administrator) to which the TOE connects selects the algorithms to be used in IPsec exchanges.  The VPN Gateway provides the ability to configure the cryptoperiod for the established IPsec session keys (including the ability to define crypto periods that are less than one hour in duration).  The TOE provides the ability to configure certificate revocation checking by providing the ability to specify an OCSP URL for revocation checking.  The TOE platform provides the ability to load X.509v3 certificates used for VPN connections using IPsec.  The TOE provides users the ability to specify an X.509v3 certificate (previously loaded into the TOE Platform’s key store) for the TOE to use to authenticate to the VPN Gateway during IPsec peer authentication as well as an X.509v3 certificate to use as the CA certificate. The TOE alternatively provides users the ability to enter a Pre-Shared Key to be used in lieu of an X.509v3 certificate during IPsec peer authentication.  The TOE platform provides the ability to update the TOE, and to verify the updates.  The TOE platform provides the functions necessary for all other security functions identified in this Security Target.

36 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

8.5 Protection of the TSF

8.5.1 FPT_TST_EXT.1: The TOE is a system service (i.e., Native App) built into the TOE platform. As such, it is subject to the self-tests feature of the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1, 12 February 2014). The TOE platform cryptographically verifies the integrity of its executable code (the files /system/bin/charon, /system/lib/libcharon.so, /system/lib/libstrongswan.so, and /system/lib/libhydra.so) upon load and prior to execution (the TOE platform loads the executable whenever a VPN connection is requested/attempted) by requesting checking from the Security Manager daemon (part of the TOE platform). The Security Manager verifies (using an embedded RSA-2048 public key) a PKCS#1 (using SHA-256) signature of the TOE executable code to ensure that it has not been modified or corrupted. If the Security Manager’s check of the TOE fails, the TOE will fail to establish a VPN connection. The TOE platform performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure that they are functioning correctly. The kernel itself performs known answer tests on its cryptographic algorithms to ensure they are working correctly and the Samsung security manager service invokes self-test of the OpenSSL module at start to ensure that those cryptographic algorithms are working correctly. If the TOE platform fails its power-up tests fails, the TOE platform will automatically reboot, which will prevent user login.

8.5.2 FPT_TUD_EXT.1: The TOE is a system service (i.e., Native App) built into the TOE platform. As such, it is subject to the trusted updated feature of the TOE platform (evaluated against the Protection Profile For Mobile Device Fundamentals, Version 1.1, 12 February 2014). The TOE platform’s user interface provides a method to query the current version of the TOE platform’s software/firmware (Tizen version, baseband version, kernel version, and build number) and hardware (model and version). Additionally, the TOE platform provides users the ability to review the currently installed apps (including Native Apps) and their version. When in CC mode, the TOE platform verifies all updates to its software using a public key (FOTA public key) chaining ultimately to the Secure Boot Public Key (SBPK), a hardware protected key whose SHA- 256 hash resides inside the application processor (note that when not in CC mode, the TOE platform allows updates to the TOE platform software through ODIN mode of the bootloader). After verifying the FOTA signature of an update, the TOE platform will then install those updates to the TOE platform. The application processing verifies the bootloader’s authenticity and integrity (thus tying the bootloader and subsequent stages to a hardware root of trust: the SHA-256 hash of the SBPK, which cannot be reprogrammed after the “write-enable” fuse has been blown). Additionally, the Tizen OS on the TOE platform requires that all applications bear a valid signature before Tizen will install the application.

8.6 Trusted Path/Channels

8.6.1 FTP_ITC.1: The TOE uses IPsec to provide a protected communication channel between itself and an IPsec VPN Gateway. The channel provides assurance identification of the end points and protects transmitted data from disclosure and modification. See section 8.1 for a description of how the TOE can establish IPsec

37 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary

Security Target Samsung Z VPN on Tizen 2.3

VPN connections with configured VPN Gateways. The resulting VPNs ensure that both ends of the channel are authenticated and the channel protects data from disclosure and modification.

38 | P a g e Booz Allen Hamilton – CATL / Samsung Proprietary