MobileIron Platform (MDMPP30 and
MDMAEP30) Security Target
Version 0.8
01/04/2019
Prepared for:
MobileIron
401 East Middlefield Road
Mountain View, CA 94043
Prepared By:
www.gossamersec.com
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 2 of 45
1. SECURITY TARGET INTRODUCTION........................................................................................................3
1.1 SECURITY TARGET REFERENCE......................................................................................................................3
1.2 TOE REFERENCE............................................................................................................................................3
1.3 TOE OVERVIEW .............................................................................................................................................4
1.4 TOE DESCRIPTION .........................................................................................................................................4
1.4.1 TOE Architecture...................................................................................................................................5
1.4.2 TOE Documentation ..............................................................................................................................7
2. CONFORMANCE CLAIMS..............................................................................................................................8
2.1 CONFORMANCE RATIONALE...........................................................................................................................8
3. SECURITY OBJECTIVES ................................................................................................................................9
3.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .....................................................................9
4. EXTENDED COMPONENTS DEFINITION ................................................................................................10
5. SECURITY REQUIREMENTS.......................................................................................................................11
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................11
5.1.1 Security audit (FAU)............................................................................................................................12
5.1.2 Cryptographic support (FCS)..............................................................................................................16
5.1.3 Identification and authentication (FIA) ...............................................................................................22
5.1.4 Security management (FMT) ...............................................................................................................24
5.1.5 Protection of the TSF (FPT) ................................................................................................................27
5.1.6 TOE access (FTA)................................................................................................................................28
5.1.7 Trusted path/channels (FTP) ...............................................................................................................28
5.2 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................29
5.2.1 Development (ADV).............................................................................................................................29
5.2.2 Guidance documents (AGD)................................................................................................................30
5.2.3 Life-cycle support (ALC) .....................................................................................................................31
5.2.4 Tests (ATE) ..........................................................................................................................................31
5.2.5 Vulnerability assessment (AVA)...........................................................................................................32
6. TOE SUMMARY SPECIFICATION..............................................................................................................33
6.1 SECURITY AUDIT ..........................................................................................................................................33
6.2 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................34
6.3 IDENTIFICATION AND AUTHENTICATION.......................................................................................................40
6.4 SECURITY MANAGEMENT .............................................................................................................................41
6.5 PROTECTION OF THE TSF .............................................................................................................................44
6.6 TOE ACCESS.................................................................................................................................................45
6.7 TRUSTED PATH/CHANNELS ...........................................................................................................................45
LIST OF TABLES
Table 1 TOE Security Functional Components ......................................................................................................12
Table 2 Server Auditable Events..............................................................................................................................14
Table 3 Client Auditable Events...............................................................................................................................15
Table 4 Assurance Components ...............................................................................................................................29
Table 5 Algorithm Certificates.................................................................................................................................38
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 3 of 45
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE is a MobileIron Platform provided by MobileIron. The
TOE is being evaluated as a Mobile Device Management (MDM) solution consisting of an MDM server
(MobileIron Core) and associated MDM mobile device agents (MobileIron Client).
The Security Target contains the following additional sections:
 Conformance Claims (Section 2)
 Security Objectives (Section 3)
 Extended Components Definition (Section 4)
 Security Requirements (Section 5)
 TOE Summary Specification (Section 6)
Conventions
The following conventions have been applied in this document:
 Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by a parenthetical number placed at the end of the component. For example,
FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the
FDP_ACC.1 requirement. Alternately, iterations are identified with a prefix in the requirement
labels representing the source Protection Profile or Extended Package (e.g.,
MDMPP30:FCS_HTTPS_EXT.1 vs. MDMAEP30:FCS_HTTPS_EXT.1).
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a
selection would be identified in italics and with embedded bold brackets (e.g., [[selected-
assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
 Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.1 Security Target Reference
ST Title – MobileIron Platform (MDMPP30 and MDMAEP30) Security Target
ST Version – Version 0.8
ST Date – 01/04/2019
1.2 TOE Reference
TOE Identification – MobileIron Platform
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 4 of 45
 MobileIron Core, Version 10.0.1.0
 MobileIron Client – Mobile@Work for Android, Version 10.0.1.0
TOE Developer – MobileIron
Evaluation Sponsor – MobileIron
1.3 TOE Overview
The Target of Evaluation (TOE) is the MobileIron Core server (deployed as a physical appliance or a VM as
identified later) and associated MobileIron Client agents for Android devices (Mobile@Work for Android) that are
part of their MobileIron Platform. Note that the MobileIron Platform consists of other components (MobileIron
Sentry and additional mobile device applications, e.g., Mobile@Work for iOS, Web@work, Docs@work,
AppConnect container and Secure Application Manager) that do not play a role in enforcing the security functions
included in this Security Target.
Also, while no iOS device agent security function claims are made within this Security Target, the MobileIron Core
server supports the enrollment of Apple iPad and iPhone Mobile Devices with iOS 11.2 (NIAP VID 10851) and
subsequent management of those devices via interaction with their own built in MDM agents.
1.4 TOE Description
The TOE is an MDM solution where the claimed security functions are implemented in a central MDM server –
MobileIron Core - and distributed MDM agents – MobileIron Client.
MobileIron Core (http://www.mobileiron.com/en/products/core) integrates with backend enterprise IT systems and
enables IT to define security and management policies for mobile apps, content and devices independent of the
operating system. MobileIron Core enables mobile devices (including both Android and iOS mobile devices
identified in section 1.4.1.1 below), application, and content management.
 Mobile device management capabilities are the primary focus of this evaluation and enable IT to securely
manage mobile devices across mobile operating systems and provide secure corporate email, automatic
device configuration, certificate-based security, and selective wiping of enterprise data from both
corporate-owned as well as user-owned devices.
 Mobile application management capabilities are a secondary focus of this evaluation and help IT manage
the entire application lifecycle, from making the applications available in the enterprise app storefront,
facilitating deployment of applications to mobile devices, and retiring applications as necessary. Note that
this capability is referred to as MAS – Mobile Application Store – Server later in this ST.
 Mobile content management functions are included in the MobileIron Platform, but no claims are made
about those capabilities in this Security Target.
MobileIron Client– also known as Mobile@Work for Android – is an app downloaded by end users onto their
mobile devices. It configures the device to function in an enterprise environment by enforcing the configuration and
security policies set by the IT department. Once installed, it creates a secure MobileIron container to protect
enterprise data and applications.
 The MobileIron Client works with MobileIron Core to configure corporate email, Wi-Fi, VPN, and security
certificates and to create a clear separation between personal and business information. This allows IT to
selectively wipe only the enterprise data on the device if the user leaves or if the device falls out of
compliance or is lost.
 The MobileIron Client also enables additional enterprise device controls that are not subject to security
claims and hence are outside the scope of the evaluation related to this Security Target.
Note that MobileIron distributes a Mobile@Work for iOS application, however, given restrictions on the associated
Apple iOS mobile devices it is incapable of implementing the required MDM agent security functions. Rather,
Mobile@Work for iOS is an optional component and serves only to direct the built-in iOS MDM agent to the
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 5 of 45
MobileIron Core MDM server for enrollment. As such, this component does not implement any security functions.
Mobile@Work for iOS is not require to enroll an iOS device with the MobileIron Core MDM server – the Safari
browser built into iOS devices can be used to enroll with the MobileIron Core MDM server with no other
application support.
1.4.1 TOE Architecture
MobileIron offers a MobileIron Platform solution comprising MobileIron Core, MobileIron Sentry, MobileIron
Client, and mobile end user products (e.g., smartphones and tablets).
Of these components, the TOE is a central MobileIron Core server and MobileIron Clients installed on distributed
end user mobile Android devices (Mobile@Work for Android). Mobile@Work for iOS and MobileIron Sentry are
security products not within scope of this evaluation (i.e., the MDMPP30 requirements are not applicable), but can
freely be used with the TOE in its evaluated configuration.
1.4.1.1 Physical Boundaries
As indicated above the TOE consists of two software components: MobileIron Core and MobileIron Client.
MobileIron Core is a server based on a CentOS 7.4 Linux operating system (OS) with Apache 2.4 (or later) that runs
on an Intel x64 architecture server platform. MobileIron supports the MobileIron Core operating on one physical
server appliance that they distribute (Mobile Iron M2600) as well as virtual deployments in VMWare ESXi (5.1, 5.5,
or 6.0) and Microsoft Hyper-V (Server 2008 R2 or Server 2012 R2). Later in this ST the MobileIron Core
component is identified as the “MDM server” and its underlying OS is identified as the “MDM server platform”.
Note that while an earlier version (7.1) of Red Hat Enterprise Linux
(https://www.commoncriteriaportal.org/files/epfiles/0949b_pdf.pdf) which is comparable to CentOS was previously
evaluated, the CentOS MDM Server Platform for the MDM Server is effectively unevaluated. All of the security
claims that refer to the platform for compliance are addressed with NIST CAVP algorithm certificates identified in
this Security Target.
The MobileIron M2600 appliances are based on Intel Xeon E5 CPUs and utilize Intel network adapters (Quad I350
GbE) along with SATA disk drives and 128 GB of DRAM.
MobileIron Core can optionally be configured to utilize an external LDAP server via a secure TLS channel to
authenticate users.
MobileIron Client consists of apps deployed on Android mobile devices. These components are identified later in
this ST as the “MDM Agent”.
NIAP requires that MDM agents must be installed on NIAP-evaluated mobile devices in order to be evaluated using
the MDMAEP20. At present there are a number of evaluated Samsung Galaxy mobile Android devices ranging from
Android version 7 to 8 that can be used with the Android version of the MobileIron Client.
 (NIAP VID 10898, https://www.niap-ccevs.org/MMO/Product/st_vid10898-st.pdf) Samsung Galaxy
Devices on Android 8: Samsung Galaxy S8, S8+, S8 Active, Note 8, S9 and S9+.
 (NIAP VID 10849, https://www.niap-ccevs.org/MMO/Product/st_vid10849_st.pdf) Samsung Galaxy
Devices on Android 7.1: Samsung Galaxy Note8 and Tab Active 2.
 (NIAP VID 10809, https://www.niap-ccevs.org/MMO/Product/st_vid10809-st.pdf) Samsung Galaxy
Devices with Android 7: Samsung Galaxy S6, S6 Active, S6 Edge, S6 Edge+, Note 5, S7, S7 Active, S7
Edge, S8, S8 Active, S8+, and Tab S3.
MobileIron Core can manage devices with the iOS MDM agent developed and evaluated by Apple Inc. – that agent
has been evaluated on Apple iPad and iPhone Mobile Devices with iOS 11.2 (NIAP VID 10851).
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 6 of 45
1.4.1.2 Logical Boundaries
This section summarizes the security functions provided by MobileIron Platform:
- Security audit
- Cryptographic support
- Identification and authentication
- Security management
- Protection of the TSF
- TOE access
- Trusted path/channels
1.4.1.2.1 Security audit
The MDM Server can generate and store audit records for security-relevant events as they occur. These events are
stored and protected by the MDM Server and can be reviewed by an authorized administrator. The MDM Server can
be configured to export the audit records in either in CSV (comma separated values) format, text format, or a
compressed archive format utilizing TLS for protection of the records on the network. The MDM Server also
supports the ability to query information about MDM agents and export MDM configuration information.
The MDM Agent can generate audit records for security-relevant events and includes the ability to indicate (i.e.,
respond) when it has been enrolled and when policies are successfully applied to the MDM Agent. The MDM
Server can be configured to alert an administrator based on its configuration. For example, it can be configured to
alert the administrator when a policy update fails or an MDM Agent has been enrolled.
1.4.1.2.2 Cryptographic support
The MDM Server and MDM Agent both include and/or utilize cryptographic modules with certified algorithms for a
wide range of cryptographic functions including: asymmetric key generation and establishment,
encryption/decryption, cryptographic hashing and keyed-hash message authentication. These functions are
supported with suitable random bit generation, initialization vector generation, secure key storage, and key and
protected data destruction.
The primitive cryptographic functions are used to implement security communication protocols: TLS and HTTPS
used for communication between the MDM Server and MDM Agent and between the MDM Server and remote
administrators.
1.4.1.2.3 Identification and authentication
The MDM Server requires mobile device users (MD users) and administrators to be authenticated prior to allowing
any security-related functions to be performed. This includes MD users enrolling their device in the MDM Server
using a corresponding MDM Agent as well as an administrator logging on to manage the MDM Server
configuration, MDM policies for mobile devices, etc.
In addition, both the MDM Server and MDM Agent utilize X.509 certificates, including certificate validation
checking, in conjunction with TLS to secure communications between the MDM Server and MDM Agents as well
as between the MDM Server and administrators using a web-based user interface for remote administrative access.
1.4.1.2.4 Security management
The MDM Server is designed to include at least two distinct user roles: administrator and mobile device user (MD
user). The former interacts directly with the MDM Server while the latter is the user of a mobile device hosting an
MDM Agent. The MDM Server further supports the fine-grain assignment of role (access to management function)
to defined users allowing the definition of multiple user and administrator roles with different capabilities and
responsibilities.
The MDM Server provides all the function necessary to manage its own security functions as well as to manage
mobile device policies that are sent to MDM Agents. In addition, the MDM Server ensures that security
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 7 of 45
management functions are limited to authorized administrators while allowing MD users to perform only necessary
functions such as enrolling in the MDM Server.
The MDM Agents provide the functions necessary to securely communicate with and enroll in a MDM Server,
implement policies received from an enrolled MDM Server, and report the results of applying policies.
1.4.1.2.5 Protection of the TSF
The MDM Server and MDM Agent work together to ensure that all security related communication between those
components is protected from disclosure and modification.
Both the MDM Server and MDM Agent include self-testing capabilities to ensure that they are functioning properly.
The MDM Server also has the ability to cryptographically verify during start-up that its executable image has not
been corrupted.
The MDM Server also includes mechanisms (i.e., verification of the digital signature of each new image) so that the
TOE itself can be updated while ensuring that the updates will not introduce malicious or other unexpected changes
in the TOE.
1.4.1.2.6 TOE access
The MDM Server has the capability to display an advisory banner when users attempt to login in order to manage
the TOE using the web-based and command-line based user interfaces.
1.4.1.2.7 Trusted path/channels
The MDM Server uses TLS/HTTPS to secure communication channels between itself and remote administrators
accessing the TOE via a web-based user interface.
The MDM Server can optionally be configured to use TLS to communicate with an LDAP server for user
authentication.
It also uses TLS to secure communication channels between itself and mobile device users (MD users). In this latter
case, the protected communication channel is established between the MDM Server and applicable MDM Agent on
the user’s mobile device.
1.4.2 TOE Documentation
MobileIron has developed an extensive document set for the MobileIron Platform. However, for the purpose of
evaluation, the following guides were examined:
 MobileIron Core and Android and iOS Client Mobile Device Management Protection Profile Guide,
Version 1.1, January 10, 2019
 MobileIron Core and Connector 10.0.1.0 Release and Upgrade Notes, November 15, 2018
 On-Premise Installation Guide for MobileIron Core and Enterprise Connector 10.0.0.0, June 20, 2018
 Getting Started with MobileIron Core 10.0.0.0, July 20, 2018
 MobileIron Core 10.0.0.0 Device Management Guide for Android and Android enterprise Devices, June
29, 2018
 MobileIron Core 10.0.0.0 Device Management Guide for iOS and macOS Devices, June 29, 2018
 MobileIron Core 10.0.0.0 System Manager Guide, June 6, 2018
 MobileIron Core 10.0.0.0 Apps@Work Guide, June 6, 2018
 MobileIron Core 10.0.0.0 AppConnect and AppTunnel Guide, June 13, 2018
 MobileIron Core Delegated Administration Guide 10.0.0.0, June 12, 2018
 MobileIron Core 9.7.0.0 Command Line Interface (CLI) Reference, March 7, 2018
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 8 of 45
2. Conformance Claims
This TOE is conformant to the following CC specifications:
 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 4, September 2012.
 Part 2 Extended
 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1 Revision 4, September 2012.
 Part 3 Conformant
 Package Claims:
 Protection Profile for Mobile Device Management, Version 3.0, 21 November 2016 (MDMPP30)
with the following NIAP TDs applied: TD0163, TD0212, TD0231, TD0232, TD0234, TD0267,
TD0304, TD0305, and TD0318
 Extended Package for Mobile Device Management Agents, Version 3.0, 21 November 2016
(MDMAEP30) with the following NIAP TD applied: TD0237
2.1 Conformance Rationale
The ST conforms to the MDMPP30 and MDMAEP30. As explained below, the security problem definition, security
objectives, and security requirements have been drawn from the MDMPP30 and MDMAEP30.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 9 of 45
3. Security Objectives
The Security Problem Definition can be found in the Protection Profile for Mobile Device Management, Version
3.0, 21 November 2016 (MDMPP30) and Extended Package for Mobile Device Management Agents, Version 3.0,
21 November 2016 (MDMAEP30) and this section reproduces only the corresponding Security Objectives for
operational environment for reader convenience. The MDMPP30 and MDMAEP30 offer additional information
about the identified security objectives, but that has not been reproduced here and the MDMPP30 and MDMAEP30
should be consulted if there is interest in that material.
In general, the MDMPP30 and MDMAEP30 have defined Security Objectives appropriate for a Mobile Device
Management (MDM) product and as such are applicable to the MobileIron Platform TOE.
3.1 Security Objectives for the Operational Environment
OE.DATA_PROPER_ADMIN TOE Administrators are trusted to follow and apply all administrator
guidance in a trusted manner.
OE.DATA_PROPER_USER Users of the mobile device are trained to securely use the mobile device and
apply all guidance in a trusted manner.
OE.IT_ENTERPRISE The Enterprise IT infrastructure provides security for a network that is available to
the TOE and mobile devices that prevents unauthorized access.
OE.MOBILE_DEVICE_PLATFORM The MDM Agent relies upon the trustworthy mobile platform and
hardware to provide policy enforcement as well as cryptographic services and data protection. The mobile
platform provides trusted updates and software integrity verification of the MDM Agent.
OE.TIMESTAMP Reliable timestamp is provided by the operational environment for the TOE.
OE.WIRELESS_NETWORK A wireless network will be available to the mobile devices.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 10 of 45
4. Extended Components Definition
All of the extended requirements in this Security Target (ST) have been drawn from the Protection Profile for
Mobile Device Management, Version 3.0, 21 November 2016 (MDMPP30) and Extended Package for Mobile
Device Management Agents, Version 3.0, 21 November 2016 (MDMAEP30). The MDMPP30 and MDMAEP30
define the following extended requirements and since they are not redefined in this ST the MDMPP30 and
MDMAEP30 should be consulted for more information in regard to those Common Criteria (CC) extensions.
Extended SFRs:
 MDMPP30:FAU_ALT_EXT.1: Server Alerts
 MDMAEP30:FAU_ALT_EXT.2: Agent Alerts
 MDMPP30:FAU_CRP_EXT.1: Support for Compliance Reporting of Mobile Device Configuration
 MDMPP30:FAU_NET_EXT.1: Network Reachability Review
 MDMPP30:FAU_STG_EXT.1(1): External Trail Storage
 MDMPP30:FAU_STG_EXT.2: Audit Event Storage
 MDMPP30:FCS_CKM_EXT.4: Cryptographic Key Destruction
 MDMAEP30:FCS_CKM_EXT.4: Cryptographic Key Destruction
 MDMPP30:FCS_HTTPS_EXT.1: HTTPS Protocol
 MDMAEP30:FCS_HTTPS_EXT.1: HTTPS Protocol
 MDMPP30:FCS_RBG_EXT.1: Extended: Random Bit Generation
 MDMAEP30:FCS_RBG_EXT.1: Extended: Random Bit Generation
 MDMPP30:FCS_STG_EXT.1: Cryptographic Key Storage
 MDMAEP30:FCS_STG_EXT.1(2): Cryptographic Key Storage
 MDMPP30:FCS_TLSC_EXT.1: TLS Client Protocol
 MDMPP30:FCS_TLSS_EXT.1: TLS Server Protocol
 MDMPP30:FIA_ENR_EXT.1: Enrollment of Mobile Device into Management
 MDMAEP30:FIA_ENR_EXT.2: Enrollment of Mobile Device into Management
 MDMPP30:FIA_X509_EXT.1: Validation of Certificates
 MDMAEP30:FIA_X509_EXT.1: Validation of Certificates
 MDMPP30:FIA_X509_EXT.2: X509 Certificate Authentication
 MDMAEP30:FIA_X509_EXT.2: X509 Certificate Authentication
 MDMPP30:FMT_POL_EXT.1: Trusted Policy Update
 MDMAEP30:FMT_POL_EXT.2: Trusted Policy Update
 MDMPP30:FMT_SAE_EXT.1: Security Attribute Expiration
 MDMAEP30:FMT_SMF_EXT.3: Specification of Management Functions
 MDMAEP30:FMT_UNR_EXT.1: User Unenrollment Prevention
 MDMPP30:FPT_TST_EXT.1: TSF Functionality Testing
 MDMPP30:FPT_TUD_EXT.1: Trusted Update
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 11 of 45
5. Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs)
that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation
effort.
The SFRs have all been drawn from the Protection Profile for Mobile Device Management, Version 3.0, 21
November 2016 (MDMPP30) and Extended Package for Mobile Device Management Agents, Version 3.0, 21
November 2016 (MDMAEP30). The refinements and operations already performed in the MDMPP30 and
MDMAEP30 are not identified (e.g., highlighted) here, rather the requirements have been copied from the
MDMPP30 and MDMAEP30 and any residual operations have been completed herein. Of particular note, the
MDMPP30 and MDMAEP30 made a number of refinements and completed some of the SFR operations defined in
the Common Criteria (CC) and that PP should be consulted to identify those changes if necessary.
The SARs are also drawn from the MDMPP30 and MDMAEP30. However, the SARs are effectively refined since
requirement-specific ‘Assurance Activities’ are defined in the MDMPP30 and MDMAEP30 that serve to ensure
corresponding evaluations will yield more practical and consistent assurance. The MDMPP30 and MDMAEP30
should be consulted for the assurance activity definitions.
5.1 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by MobileIron Platform TOE.
Requirement Class Requirement Component
FAU: Security audit MDMPP30:FAU_ALT_EXT.1: Server Alerts
MDMAEP30:FAU_ALT_EXT.2: Agent Alerts
MDMPP30:FAU_CRP_EXT.1: Support for Compliance Reporting of Mobile Device
Configuration
MDMPP30:FAU_GEN.1(1): Audit Data Generation
MDMAEP30:FAU_GEN.1(2): Audit Data Generation
MDMPP30:FAU_NET_EXT.1: Network Reachability Review
MDMPP30:FAU_SAR.1: Audit Review
MDMAEP30:FAU_SEL.1(2): Security Audit Event Selection
MDMPP30:FAU_STG_EXT.1(1): External Trail Storage
MDMPP30:FAU_STG_EXT.2: Audit Event Storage
FCS: Cryptographic
support
MDMPP30:FCS_CKM.1: Cryptographic Key Generation
MDMAEP30:FCS_CKM.1: Cryptographic Key Generation
MDMPP30:FCS_CKM.2: Cryptographic Key Establishment
MDMAEP30:FCS_CKM.2: Cryptographic Key Establishment
MDMPP30:FCS_CKM_EXT.4: Cryptographic Key Destruction
MDMAEP30:FCS_CKM_EXT.4: Cryptographic Key Destruction
MDMPP30:FCS_COP.1(1): Cryptographic Operation (Confidentiality Algorithms)
MDMAEP30:FCS_COP.1(1): Cryptographic Operation (Confidentiality Algorithms)
MDMPP30:FCS_COP.1(2): Cryptographic Operation (Hashing Algorithms)
MDMAEP30:FCS_COP.1(2): Cryptographic Operation (Hashing Algorithms)
MDMPP30:FCS_COP.1(3): Cryptographic Operation (Signature Algorithms)
MDMAEP30:FCS_COP.1(3): Cryptographic Operation (Signature Algorithms)
MDMPP30:FCS_COP.1(4): Cryptographic Operation (Keyed-Hash Message
Authentication)
MDMAEP30:FCS_COP.1(4): Cryptographic Operation (Keyed-Hash Message
Authentication)
MDMPP30:FCS_HTTPS_EXT.1: HTTPS Protocol
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 12 of 45
MDMAEP30:FCS_HTTPS_EXT.1: HTTPS Protocol
MDMPP30:FCS_RBG_EXT.1: Extended: Random Bit Generation
MDMAEP30:FCS_RBG_EXT.1: Extended: Random Bit Generation
MDMPP30:FCS_STG_EXT.1: Cryptographic Key Storage
MDMAEP30:FCS_STG_EXT.1(2): Cryptographic Key Storage
MDMPP30:FCS_TLSC_EXT.1: TLS Client Protocol
MDMPP30:FCS_TLSS_EXT.1: TLS Server Protocol
FIA: Identification and
authentication
MDMPP30:FIA_ENR_EXT.1: Enrollment of Mobile Device into Management
MDMAEP30:FIA_ENR_EXT.2: Enrollment of Mobile Device into Management
MDMPP30:FIA_UAU.1: Timing of Authentication
MDMPP30:FIA_X509_EXT.1: Validation of Certificates
MDMAEP30:FIA_X509_EXT.1: Validation of Certificates
MDMPP30:FIA_X509_EXT.2: X509 Certificate Authentication
MDMAEP30:FIA_X509_EXT.2: X509 Certificate Authentication
FMT: Security
management
MDMPP30:FMT_MOF.1(1): Management of Functions Behavior
MDMPP30:FMT_MOF.1(2): Management of Functions Behavior (Enrollment)
MDMPP30:FMT_MOF.1(3): Management of Functions (MAS Server)
MDMPP30:FMT_MOF.1(4): Management of Functions in (MAS Server Downloads)
MDMPP30:FMT_POL_EXT.1: Trusted Policy Update
MDMAEP30:FMT_POL_EXT.2: Trusted Policy Update
MDMPP30:FMT_SAE_EXT.1: Security Attribute Expiration
MDMPP30:FMT_SMF.1(1): Specification of Management Functions (Server
configuration of Agent)
MDMPP30:FMT_SMF.1(2): Specification of Management Functions (Server
Configuration of Server)
MDMPP30:FMT_SMF.1(3): Specification of Functions (MAS Server)
MDMAEP30:FMT_SMF_EXT.3: Specification of Management Functions
MDMPP30:FMT_SMR.1(1): Security Management Roles
MDMAEP30:FMT_UNR_EXT.1: User Unenrollment Prevention
FPT: Protection of the
TSF
MDMPP30:FPT_ITT.1: Internal TOE TSF Data Transfer
MDMPP30:FPT_TST_EXT.1: TSF Functionality Testing
MDMPP30:FPT_TUD_EXT.1: Trusted Update
FTA: TOE access MDMPP30:FTA_TAB.1: TOE Access Banners
FTP: Trusted
path/channels
MDMPP30:FTP_ITC.1(1): Inter-TSF Trusted Channel (Authorized IT Entities)
MDMPP30:FTP_ITC.1(2): Inter-TSF Trusted Channel (MDM Agent)
MDMPP30:FTP_TRP.1(1): Trusted Path (Remote Administration)
MDMPP30:FTP_TRP.1(2): Trusted Path (for Enrollment)
Table 1 TOE Security Functional Components
5.1.1 Security audit (FAU)
5.1.1.1 Server Alerts (MDMPP30:FAU_ALT_EXT.1)
MDMPP30:FAU_ALT_EXT.1.1
The MDM Server shall alert the administrators in the event of any of the following:
a. change in enrollment status;
b. failure to apply policies to a mobile device;
c. [no other events].
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 13 of 45
5.1.1.2 Agent Alerts (MDMAEP30:FAU_ALT_EXT.2)
MDMAEP30:FAU_ALT_EXT.2.1
The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the event of
any of the following audit events:
a. successful application of policies to a mobile device,
b. [receiving] periodic reachability events,
c. [change in enrollment state].
MDMAEP30:FAU_ALT_EXT.2.2
The MDM Agent shall queue alerts if the trusted channel is not available.
5.1.1.3 Support for Compliance Reporting of Mobile Device Configuration (MDMPP30:FAU_CRP_EXT.1)
MDMPP30:FAU_CRP_EXT.1.1
The MDM Server shall provide [an interface that provides responses to queries about the
configuration of enrolled devices, an interface that permits the export of data about the
configuration of enrolled devices] to authorized entities over an authenticated [TLS/HTTPS]
trusted communication channel. The provided information for each enrolled mobile device
includes:
a. The current version of the MD firmware/software
b. The current version of the hardware model of the device
c. The current version of installed mobile applications
d. List of MD configuration policies that are in place on the device (as defined in
FMT_SMF.1.1(1))
e. [no other information].
5.1.1.4 Audit Data Generation (MDMPP30:FAU_GEN.1(1))
MDMPP30:FAU_GEN.1.1(1)
The [TSF] shall be able to generate an audit record of the following auditable events:
a. Start-up and shutdown of the MDM Server software;
b. All administrative actions;
c. Commands issued from the MDM Server to an MDM Agent;
d. Specifically defined auditable events listed in Table 2 Server Auditable Events; and
e. [MDM agent alerts generated by MDMAEP30:FAU_ALT_EXT.2.1].
MDMPP30:FAU_GEN.1.2(1)
The [TSF] shall record within each TSF audit record at least the following information:
- date and time of the event,
- type of event,
- subject identity,
- (if relevant) the outcome (success or failure) of the event,
- additional information in Table 2 Server Auditable Events,
- [no other audit relevant information].
Requirement Auditable Events Additional Content
MDMPP30:FAU_ALT_EXT.1 Type of alert. Identity of Mobile Device that
sent alert.
MDMPP30:FAU_CRP_EXT.1
MDMPP30:FAU_GEN.1(1)
MDMPP30:FAU_NET_EXT.1
MDMPP30:FAU_SAR.1
MDMPP30:FAU_STG_EXT.1(1)
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 14 of 45
Requirement Auditable Events Additional Content
MDMPP30:FAU_STG_EXT.2
MDMPP30:FCS_CKM.1 Failure of key generation activity for
authentication keys.
MDMPP30:FCS_CKM.2
MDMPP30:FCS_CKM_EXT.4
MDMPP30:FCS_COP.1(1)
MDMPP30:FCS_COP.1(2)
MDMPP30:FCS_COP.1(3)
MDMPP30:FCS_COP.1(4)
MDMPP30:FCS_HTTPS_EXT.1 Failure of the certificate validity check. Issuer Name and Subject Name
of certificate. [no additional
information].
MDMPP30:FCS_RBG_EXT.1 Failure of the randomization process.
MDMPP30:FCS_STG_EXT.1
MDMPP30:FCS_TLSC_EXT.1 Failure to establish a TLS session.
Failure to verify presented identifier.
Reason for failure. Presented
identifier and reference identifier.
MDMPP30:FCS_TLSS_EXT.1 Failure to establish a TLS session. Reason for failure.
MDMPP30:FIA_ENR_EXT.1 Failure of MD user authentication. Presented username.
MDMPP30:FIA_UAU.1
MDMPP30:FIA_X509_EXT.1 Failure to validate X.509 certificate. Reason for failure.
MDMPP30:FIA_X509_EXT.2 Failure to establish connection to
determine revocation status.
MDMPP30:FMT_MOF.1(1) Issuance of command to perform
function. Change of policy settings.
Command sent and identity of
MDM Agent recipient. Policy
changed and value or full policy.
MDMPP30:FMT_MOF.1(2) Enrollment by a user. Identity of user.
MDMPP30:FMT_MOF.1(3)
MDMPP30:FMT_MOF.1(4)
MDMPP30:FMT_POL_EXT.1
MDMPP30: FMT_SAE_EXT.1 Enrollment attempted after expiration
of authentication data.
Identity of user.
MDMPP30:FMT_SMF.1(1)
MDMPP30:FMT_SMF.1(2) Success or failure of function.
MDMPP30:FMT_SMF.1(3)
MDMPP30:FMT_SMR.1(1)
MDMPP30:FPT_ITT.1 Initiation and termination of the trusted
channel.
Trusted channel protocol.
Identity of initiator and recipient.
MDMPP30:FPT_TST_EXT.1 Initiation of self-test. Failure of self-
test. Detected integrity violation.
Algorithm that caused failure.
The TSF code file that caused the
integrity violation.
MDMPP30:FPT_TUD_EXT.1 Success or failure of signature
verification.
MDMPP30:FTA_TAB.1 Change in banner setting.
MDMPP30:FTP_ITC.1(1) Initiation and termination of the trusted
channel.
Trusted channel protocol. Non-
TOE endpoint of connection.
MDMPP30:FTP_ITC.1(2) Initiation and termination of the trusted
channel.
Trusted channel protocol. Non-
TOE endpoint of connection.
MDMPP30:FTP_TRP.1(1) Initiation and termination of the trusted
channel.
Trusted channel protocol.
Identity of administrator.
MDMPP30:FTP_TRP.1(2) Initiation and termination of the trusted
channel.
Trusted channel protocol.
Table 2 Server Auditable Events
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 15 of 45
5.1.1.5 Audit Data Generation (MDMAEP30:FAU_GEN.1(2))
MDMAEP30:FAU_GEN.1.1(2)
The MDM Agent shall be able to generate an MDM Agent audit record of the following auditable
events:
- start-up and shutdown of the MDM Agent,
- change in MDM policy,
- any modification commanded by the MDM Server,
- specifically defined auditable events listed in Table 3 Client Auditable Events,
- [no other events].
MDMAEP30:FAU_GEN.1.2(2)
The [TSF] shall record within each MDM Agent audit record at least the following information:
- date and time of the event,
- type of event,
- subject identity,
- (if relevant) the outcome (success or failure) of the event,
- additional information in Table 3 Client Auditable Events,
- [no other relevant audit information].
Requirement Auditable Events Additional Content
MDMAEP30:FAU_ALT_EXT.2 Type of alert.
MDMAEP30:FAU_GEN.1(2)
MDMAEP30:FAU_SEL.1(2) All modifications to the audit
configuration that occur while the
audit collection functions are
operating.
MDMAEP30:FCS_CKM.1
MDMAEP30:FCS_CKM.2
MDMAEP30:FCS_CKM_EXT.4
MDMAEP30:FCS_COP.1(1)
MDMAEP30:FCS_COP.1(2)
MDMAEP30:FCS_COP.1(3)
MDMAEP30:FCS_COP.1(4)
MDMAEP30:FCS_HTTPS_EXT.1
MDMAEP30:FCS_RBG_EXT.1
MDMAEP30:FCS_STG_EXT.1(2)
MDMAEP30:FCS_TLSC_EXT.1 Failure to establish a TLS session.
Failure to verify presented identifier.
Establishment/termination of a TLS
session.
Reason for failure. Presented
identifier and reference identifier.
Non-TOE endpoint of
connection.
MDMAEP30:FIA_ENR_EXT.2 Enrollment in management. Reference identifier of MDM
Server.
MDMAEP30:FIA_X509_EXT.1
MDMAEP30:FIA_X509_EXT.2
MDMAEP30:FMT_POL_EXT.2 Failure of policy validation. Reason for failure of validation.
MDMAEP30:FMT_SMF_EXT.3 Success or failure of function.
MDMAEP30:FMT_UNR_EXT.1 [none] (TD0237 applied)
MDMAEP30:FTP_ITC.1(2)
MDMAEP30:FPT_ITT.1
Initiation and termination of the
trusted channel.
Trusted channel protocol. Non-
TOE endpoint of connection.
Table 3 Client Auditable Events
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 16 of 45
5.1.1.6 Network Reachability Review (MDMPP30:FAU_NET_EXT.1)
MDMPP30:FAU_NET_EXT.1.1
The MDM Server shall provide authorized administrators with the capability to read the network
connectivity status of an enrolled agent.
5.1.1.7 Audit Review (MDMPP30:FAU_SAR.1)
MDMPP30:FAU_SAR.1.1
The [TSF] shall provide Authorized Administrators with the capability to read all audit data from
the audit records.
MDMPP30:FAU_SAR.1.2
The [TSF] shall provide the audit records in a manner suitable for the Authorized Administrators
to interpret the information.
5.1.1.8 Security Audit Event Selection (MDMAEP30:FAU_SEL.1(2))
MDMAEP30:FAU_SEL.1.1(2)
The TSF shall be able to select the set of events to be audited from the set of all auditable events
based on the following attributes:
- event type;
- success of auditable security events;
- failure of auditable security events; and
- [no other attributes].
5.1.1.9 External Trail Storage (MDMPP30:FAU_STG_EXT.1(1))
MDMPP30:FAU_STG_EXT.1.1(1)
The [TSF] shall be able to transmit audit data to an external IT entity using a trusted channel per
FTP_ITC.1(1) and [stored locally].
5.1.1.10 Audit Event Storage (MDMPP30:FAU_STG_EXT.2)
MDMPP30:FAU_STG_EXT.2.1
The [TSF] shall protect the stored audit records in the audit trail from unauthorized modification.
5.1.2 Cryptographic support (FCS)
5.1.2.1 Cryptographic Key Generation (MDMPP30:FCS_CKM.1)
MDMPP30:FCS_CKM.1.1
The [TSF, TOE platform] shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meets FIPS
PUB 186-4, ‘Digital Signature Standard (DSS)’, Appendix B.3,1
- ECC schemes using 'NIST curves' P-384 and [P-256, P-521] that meet the following:
FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.4,
- FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.1].
1
Only the TOE platform (openSSL) is used to generate asymmetric RSA cryptographic keys.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 17 of 45
5.1.2.2 Cryptographic Key Generation (MDMAEP30:FCS_CKM.1)
MDMAEP30:FCS_CKM.1.1
The [TSF] shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm [
- ECC schemes using 'NIST curves' P-384 and [P-256, P-521] that meet the following:
FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.4,
- FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.1].
5.1.2.3 Cryptographic Key Establishment (MDMPP30:FCS_CKM.2)
MDMPP30:FCS_CKM.2.1
The [TSF, TOE platform] shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method: [
- RSA-based key establishment schemes that meets the following: NIST Special
Publication 800-56B, 'Recommendation for Pair-Wise Key Establishment Schemes
Using Integer Factorization Cryptography',
- Elliptic curve-based key establishment schemes that meets the following: NIST
Special Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography',
- Finite field-based key establishment schemes that meets the following: NIST Special
Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography'].
5.1.2.4 Cryptographic Key Establishment (MDMAEP30:FCS_CKM.2)
MDMAEP30:FCS_CKM.2.1
The [TSF, TOE platform] shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method: [
- Elliptic curve-based key establishment schemes that meets the following: NIST
Special Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography',
- Finite field-based key establishment schemes that meets the following: NIST Special
Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography'].
5.1.2.5 Cryptographic Key Destruction (MDMPP30:FCS_CKM_EXT.4)
MDMPP30:FCS_CKM_EXT.4.1
The [TSF, TOE Platform] shall destroy plaintext keying material and critical security parameters
in accordance with the following rules:
o For volatile memory, the destruction shall be executed by a single direct overwrite
[consisting of zeroes].
o For non-volatile EEPROM, the destruction shall be executed by a single direct
overwrite consisting of a pseudo random pattern using the TSF's RBG (as specified in
FCS_RBG_EXT.1), followed a read-verify.
o For non-volatile flash memory that is not wear-leveled, the destruction shall be
executed [by a single direct overwrite consisting of zeros followed by a read-verify].
o For non-volatile flash memory that is wear-leveled, the destruction shall be executed
[by a single direct overwrite consisting of zeros].
o For non-volatile memory other than EEPROM and flash, the destruction shall be
executed by a single direct overwrite with a random pattern that is changed before each
write.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 18 of 45
MDMPP30:FCS_CKM_EXT.4.2
The TSF shall destroy all plaintext keying material and critical security parameters (CSP) when no
longer needed.
5.1.2.6 Cryptographic Key Destruction (MDMAEP30:FCS_CKM_EXT.4)
MDMAEP30:FCS_CKM_EXT.4.1
The [TSF] shall destroy plaintext keying material and critical security parameters in accordance
with the following rules:
o For volatile memory, the destruction shall be executed by a single direct overwrite
[consisting of zeroes].
o For non-volatile EEPROM, the destruction shall be executed by a single direct
overwrite consisting of a pseudo random pattern using the TSF's RBG (as specified in
FCS_RBG_EXT.1), followed by a read-verify.
o For non-volatile flash memory, that is not wear-leveled, the destruction shall be
executed [by a single direct overwrite consisting of zeros followed by a read-verify].
o For non-volatile flash memory, that is wear-leveled, the destruction shall be executed
[by a single direct overwrite consisting of zeros].
o For non-volatile memory other than EEPROM and flash, the destruction shall be
executed by a single direct overwrite with a random pattern that is changed before each
write.
MDMAEP30:FCS_CKM_EXT.4.2
The TSF shall destroy all plaintext keying material and critical security parameters (CSP) when no
longer needed.
5.1.2.7 Cryptographic Operation (Confidentiality Algorithms) (MDMAEP30:FCS_COP.1(1))
MDMAEP30:FCS_COP.1.1(1)
The [TSF] shall perform encryption/decryption in accordance with a specified cryptographic
algorithm [
- AES-CBC (as defined in FIPS PUB 197 C98, and NIST SP 800-38A) mode,
- AES-GCM (as defined in NIST SP 800-38D]
and cryptographic key sizes [128-bit, 256-bit].
5.1.2.8 Cryptographic Operation (Confidentiality Algorithms) (MDMPP30:FCS_COP.1(1))
MDMPP30:FCS_COP.1.1(1)
The [TSF, TOE Platform] shall perform encryption/decryption in accordance with a specified
cryptographic algorithm [
- AES-CBC (as defined in FIPS PUB 197 C98:C101and NIST SP 800-38A) mode,
- AES-GCM (as defined in NIST SP 800-38D]
and cryptographic key sizes [128 bit, 256 bit].
5.1.2.9 Cryptographic Operation (Hashing Algorithms) (MDMAEP30:FCS_COP.1(2))
MDMAEP30:FCS_COP.1.1(2)
The [TSF] shall perform cryptographic hashing in accordance with a specified cryptographic
algorithm [SHA-256, SHA-384, SHA-512] and message digest sizes [256, 384, 512] bits that meet
the following: FIPS Pub 180-4.
5.1.2.10 Cryptographic Operation (Hashing Algorithms) (MDMPP30:FCS_COP.1(2))
MDMPP30:FCS_COP.1.1(2)
The [TSF, TOE platform] shall perform cryptographic hashing in accordance with a specified
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 19 of 45
cryptographic algorithm [SHA-256, SHA-384, SHA-512] and message digest sizes [256, 384,
512] bits that meet the following: FIPS Pub 180-4.
5.1.2.11 Cryptographic Operation (Signature Algorithms) (MDMAEP30:FCS_COP.1(3))
MDMAEP30:FCS_COP.1.1(3)
The [TSF] shall perform cryptographic signature services (generation and verification) in
accordance with a specified cryptographic algorithm [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following:
FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 4,
- ECDSA schemes using 'NIST curves' P-384 and [P-256, P-521] that meet the following: FIPS
PUB 186-4, 'Digital Signature Standard (DSS)', Section 5].
5.1.2.12 Cryptographic Operation (Signature Algorithms) (MDMPP30:FCS_COP.1(3))
MDMPP30:FCS_COP.1.1(3)
The [TSF, TOE platform] shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following:
FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 4,
- ECDSA schemes using 'NIST curves' P-384 and [P-256, P-521] that meet the following: FIPS
PUB 186-4, 'Digital Signature Standard (DSS)', Section 5].
5.1.2.13 Cryptographic Operation (Keyed-Hash Message Authentication) (MDMAEP30:FCS_COP.1(4))
MDMAEP30:FCS_COP.1.1(4)
The [TSF] shall perform keyed-hash message authentication in accordance with a specified
cryptographic algorithm HMAC-[ SHA-256, SHA-384, SHA-512] key sizes [equal to hash size],
and message digest sizes [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.'
5.1.2.14 Cryptographic Operation (Keyed-Hash Message Authentication) (MDMPP30:FCS_COP.1(4))
MDMPP30:FCS_COP.1.1(4)
The [TSF, TOE platform] shall perform keyed-hash message authentication in accordance with a
specified cryptographic algorithm HMAC-[ SHA-256, SHA-384, SHA-512] key sizes [equal to
hash size], and message digest sizes [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.'
5.1.2.15 HTTPS Protocol (MDMPP30:FCS_HTTPS_EXT.1)
MDMPP30:FCS_HTTPS_EXT.1.1
The [TSF] shall implement the HTTPS protocol that complies with RFC 2818.
MDMPP30:FCS_HTTPS_EXT.1.2
The [TSF] shall implement HTTPS using TLS as specified in FCS_TLSS_EXT.1.
MDMPP30:FCS_HTTPS_EXT.1.3
Removed per TD0212
5.1.2.16 HTTPS Protocol (MDMAEP30:FCS_HTTPS_EXT.1)
MDMAEP30:FCS_HTTPS_EXT.1.1
The [TSF, TOE platform] shall implement the HTTPS protocol that complies with RFC 2818.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 20 of 45
MDMAEP30:FCS_HTTPS_EXT.1.2
The [TSF, TOE platform] shall implement HTTPS using TLS as specified in FCS_TLSS_EXT.1.
MDMAEP30:FCS_HTTPS_EXT.1.3
The [TSF, TOE platform] shall [not establish the connection] if the peer certificate is deemed
invalid.
5.1.2.17 Extended: Random Bit Generation (MDMPP30:FCS_RBG_EXT.1)
MDMPP30:FCS_RBG_EXT.1.1
The [TSF, TOE platform] shall perform all deterministic random bit generation services in
accordance with NIST Special Publication 800-90A using [HMAC_DRBG (any), CTR_DRBG
(AES)2
].
MDMPP30: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.
5.1.2.18 Extended: Random Bit Generation (MDMAEP30:FCS_RBG_EXT.1)
MDMAEP30:FCS_RBG_EXT.1.1
The [TSF] shall perform all deterministic random bit generation services in accordance with NIST
Special Publication 800-90A using [CTR_DRBG (AES)].
MDMAEP30: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.
5.1.2.19 Cryptographic Key Storage (MDMPP30:FCS_STG_EXT.1)
MDMPP30:FCS_STG_EXT.1.1
The [TSF] shall use [the platform-provided key storage] for all persistent secrets and private keys.
5.1.2.20 Cryptographic Key Storage (MDMAEP30:FCS_STG_EXT.1(2))
MDMAEP30:FCS_STG_EXT.1.1(2)
The MDM Agent shall use the platform provided key storage for all persistent secret and private
keys.
5.1.2.21 TLS Client Protocol (MDMPP30:FCS_TLSC_EXT.1)
MDMPP30:FCS_TLSC_EXT.1.1
The [TSF] shall implement TLS 1.2 (RFC 5246) and [TLS 1.0 (RFC 3246), TLS 1.1 (RFC 4346)]
supporting the following ciphersuites:
[o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
o TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246]
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
o TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
2
The TOE Bouncy Castle implementation uses HMAC_DRBG with SHA-256 while the TOE platform OpenSSL
implementation uses CTR_DRBG with AES-256.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 21 of 45
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289]. (TD0318
applied)
MDMPP30:FCS_TLSC_EXT.1.2
The [TSF] shall verify that the presented identifier matches the reference identifier according to
RFC 6125.
MDMPP30:FCS_TLSC_EXT.1.3
The [TSF] shall only establish a trusted channel if the peer certificate is valid.
MDMPP30:FCS_TLSC_EXT.1.4
The [TSF] shall support mutual authentication using X.509v3 certificates.
MDMPP30:FCS_TLSC_EXT.1.5
The [TSF] shall present the Supported Elliptic Curves Extension in the Client Hello with the
following NIST curves: [secp256r1, secp384r1, secp521r1] and no other curves.
5.1.2.22 TLS Server Protocol (MDMPP30:FCS_TLSS_EXT.1)
MDMPP30:FCS_TLSS_EXT.1.1
The [MDM Server] shall implement TLS 1.2 (RFC 5246) and [no other version] supporting the
following ciphersuites:
[- TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
- TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246]
- TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246,
- TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289]. (TD0318
applied)
MDMPP30:FCS_TLSS_EXT.1.2
The [TSF] shall deny connections from clients requesting SSL 2.0, SSL 3.0 and [TLS 1.0, TLS
1.1]. (TD0231 applied)
MDMPP30:FCS_TLSS_EXT.1.3
The [TSF] shall support mutual authentication of TLS clients using X.509v3 certificates.
MDMPP30:FCS_TLSS_EXT.1.4
The [TSF] shall not establish a trusted channel if the peer certificate is invalid.
MDMPP30:FCS_TLSS_EXT.1.5
The [TSF] shall not establish a trusted channel if the distinguished name (DN) or Subject
Alternative Name (SAN) contained in a certificate does not match the expected identifier for the
peer.
MDMPP30:FCS_TLSS_EXT.1.6
The [TSF] shall generate key agreement parameters [over NIST curves [secp256r1, secp384r1]
and no other curves, Diffie-Hellman parameters of size 2048 bits and [3072 bits]].
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 22 of 45
5.1.3 Identification and authentication (FIA)
5.1.3.1 Enrollment of Mobile Device into Management (MDMPP30:FIA_ENR_EXT.1)
MDMPP30:FIA_ENR_EXT.1.1
The MDM Server shall authenticate the remote user over a trusted channel during the enrollment
of a mobile device.
MDMPP30:FIA_ENR_EXT.1.2
The MDM Server shall limit the user's enrollment of devices to [a number of devices] and [none].
5.1.3.2 Enrollment of Mobile Device into Management (MDMAEP30:FIA_ENR_EXT.2)
MDMAEP30:FIA_ENR_EXT.2.1
The MDM Agent shall record the reference identifier of the MDM Server during the enrollment
process.
5.1.3.3 Timing of Authentication (MDMPP30:FIA_UAU.1)
MDMPP30:FIA_UAU.1.1
The [TSF] shall allow [no TSF mediated actions] on behalf of the user to be performed before
the user is authenticated with the Server.
MDMPP30:FIA_UAU.1.2
The [TSF] shall require each user to be successfully authenticated with the Server before allowing
any other TSF-mediated actions on behalf of that user.
5.1.3.4 Validation of Certificates (MDMPP30:FIA_X509_EXT.1)
MDMPP30:FIA_X509_EXT.1.1
The [TSF] shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certificate path validation.
- The certificate path must terminate with a trusted CA certificate.
- The TSF shall validate a certificate path by ensuring the presence of the
basicConstraints extension and that the CA flag is set to TRUE for all CA certificates.
- The TSF shall validate the revocation status of the certificate using [a Certificate
Revocation List (CRL) as specified in RFC 5759 Section 5]. (TD0232 applied)
- The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication
purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
o Server certificates presented for EST shall have the CMC Registration
Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the
extendedKeyUsage field.
MDMPP30:FIA_X509_EXT.1.2
The [TSF] shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 23 of 45
5.1.3.5 Validation of Certificates (MDMAEP30:FIA_X509_EXT.1)
MDMAEP30:FIA_X509_EXT.1.1
The [TSF] shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certificate path validation.
- The certificate path must terminate with a trusted CA certificate.
- The TSF shall validate a certificate path by ensuring the presence of the
basicConstraints extension and that the CA flag is set to TRUE for all CA certificates.
- The TSF shall validate the revocation status of the certificate using [a Certificate
Revocation List (CRL) as specified in RFC 5759].
- The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication
purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
o Server certificates presented for EST shall have the CMC Registration
Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the
extendedKeyUsage field.
MDMAEP30:FIA_X509_EXT.1.2
The [TSF] shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
5.1.3.6 X509 Certificate Authentication (MDMPP30:FIA_X509_EXT.2)
MDMPP30:FIA_X509_EXT.2.1
The [TSF] shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
[TLS], and [no additional uses].
MDMPP30:FIA_X509_EXT.2.2
When the [TSF] cannot establish a connection to determine the validity of a certificate, the [TSF]
shall [not accept the certificate].
MDMPP30:FIA_X509_EXT.2.3
The [TSF] shall require a unique certificate for each client device.
5.1.3.7 X509 Certificate Authentication (MDMAEP30:FIA_X509_EXT.2)
MDMAEP30:FIA_X509_EXT.2.1
The [TSF] shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
[TLS], and [no additional uses].
MDMAEP30:FIA_X509_EXT.2.2
When the [TSF] cannot establish a connection to determine the validity of a certificate, the [TSF]
shall [not accept the certificate].
MDMAEP30:FIA_X509_EXT.2.3
The [TSF] shall require a unique certificate for each client device.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 24 of 45
5.1.4 Security management (FMT)
5.1.4.1 Management of Functions Behavior (MDMPP30:FMT_MOF.1(1))
MDMPP30:FMT_MOF.1.1(1)
The MDM Server shall restrict the ability to perform the functions
- listed in FMT_SMF.1(1)
- enable, disable, and modify policies listed in FMT_SMF.1(1)
- listed in FMT_SMF.1(2)
to authorized administrators.
5.1.4.2 Management of Functions Behavior (Enrollment) (MDMPP30:FMT_MOF.1(2))
MDMPP30:FMT_MOF.1.1(2)
The MDM Server shall restrict the ability to initiate the enrollment process to authorized
administrators and MD users.
5.1.4.3 Management of Functions (MAS Server) (MDMPP30:FMT_MOF.1(3))
MDMPP30:FMT_MOF.1.1(3)
The MAS Server shall restrict the ability to configure user groups for user-access to specific
applications allowing only the administrator to perform this function.
5.1.4.4 Management of Functions in (MAS Server Downloads) (MDMPP30:FMT_MOF.1(4))
MDMPP30:FMT_MOF.1.1(4)
The MAS Server shall restrict the ability to download applications allowing only enrolled mobile
devices that are compliant with MDM policies and assigned to a user in the application access
group to perform this function.
5.1.4.5 Trusted Policy Update (MDMPP30:FMT_POL_EXT.1)
MDMPP30:FMT_POL_EXT.1.1
The MDM Server shall provide digitally signed policies and policy updates to the MDM Agent.
5.1.4.6 Trusted Policy Update (MDMAEP30:FMT_POL_EXT.2)
MDMAEP30:FMT_POL_EXT.2.1
The MDM Agent shall only accept policies and policy updates that are digitally signed by the
Enterprise.
MDMAEP30:FMT_POL_EXT.2.2
The MDM Agent shall not install policies if the policy-signing certificate is deemed invalid.
5.1.4.7 Security Attribute Expiration (MDMPP30:FMT_SAE_EXT.1)
MDMPP30:FMT_SAE_EXT.1.1
The TSF shall be capable to specify a configurable expiration time for enrollment authentication
data.
MDMPP30:FMT_SAE_EXT.1.2
The TSF shall be able to deny enrollment after the expiration time for the enrollment
authentication data has passed.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 25 of 45
5.1.4.8 Specification of Management Functions (Server configuration of Agent)
(MDMPP30:FMT_SMF.1(1))
MDMPP30:FMT_SMF.1.1(1)
The MDM Server shall be capable of communicating the following commands to the MDM
Agent:
1. transition to the locked state, (MDF Function 6)
2. full wipe of protected data, (MDF Function 7)
3. unenroll from management,
4. install policies,
5. query connectivity status,
6. query the current version of the MD firmware/software
7. query the current version of the hardware model of the device
8. query the current version of installed mobile applications
9. import X.509v3 certificates into the Trust Anchor Database, (MDF Function 11)
10. install applications, (MDF Function 16)
11. update system software, (MDF Function 15)
12. remove applications, (MDF Function 14)
and the following commands to the MDM Agent:
[13. remove Enterprise applications, (MDF Function 17)
15. remove imported X.509v3 certificates and [[default X.509v3 certificates]] in
the Trust Anchor Database, (MDF Function 12) – Samsung Only
17. import keys/secrets into the secure key storage, (MDF Function 9)
18. destroy imported keys/secrets and [no other keys/secrets] in the secure key
storage, (MDF Function 10)
19. read audit logs kept by the MD, (MDF Function 32) – Samsung Only
]
and the following MD configuration policies:
25. password policy:
a. minimum password length
b. minimum password complexity
c. maximum password lifetime (MDF Function 1)
26. session locking policy:
a. screen-lock enabled/disabled
b. screen lock timeout
c. number of authentication failures (MDF Function 2)
27. wireless networks (SSIDs) to which the MD may connect (WLAN Client EP
Function 2) – Samsung Only
28. security policy for each wireless network:
a. [specify the CA(s) from which the MD will accept WLAN authentication
server certificate(s)]
b. ability to specify security type
c. ability to specify authentication protocol
d. specify the client credentials to be used for authentication
e. [no additional WLAN management functions] (WLAN Client EP Function
1)
29. application installation policy by [
a. specifying authorized application repository(s) - Samsung Only
b. specifying a set of allowed applications and versions (an application
whitelist) - Samsung Only
c. denying application installation], (MDF Function 8) – iOS Only
30. enable/disable policy for [camera and microphone] across device, [no other
method], (MDF Function 5) – Camera-only on iOS
and the following MD configuration policies: [
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 26 of 45
31. enable/disable policy for the VPN protection across MD, [no other method], (MDF
Function 3) – iOS only
32. enable/disable policy for [NFC, Bluetooth, Wi-Fi, and cellular radios], (MDF
Function 4) – Samsung Only
34. enable/disable policy for [protocols supporting remote access], (MDF Function 25),
– Samsung Only
35. enable/disable policy for developer modes, (MDF Function 26), – Samsung Only
36. enable policy for data-at rest protection, (MDF Function 20), – Samsung Only
37. enable policy for removable media's data-at-rest protection, (MDF Function 21), –
Samsung Only
40. enable/disable policy for display notification in the locked state of [all
notifications3
], (MDF Function 19) - iOS only
44. [certificate] used to validate digital signature on
applications, (MDF Function 33) – iOS only
47. the unlock banner policy, (MDF Function 36),
48. configure the auditable items (MDF Function 37) – Samsung Only
49. enable/disable [a. USB mass storage mode] (MDF Function 39), – Samsung Only
52. enable/disable location services: a. across device [d. no other method] (MDF
Function 22), – Samsung Only
55. enable/disable policy for use of Biometric Authentication Factor (MDF
Function 23)
57. [no other policies].
5.1.4.9 Specification of Management Functions (Server Configuration of Server)
(MDMPP30:FMT_SMF.1(2))
MDMPP30:FMT_SMF.1.1(2)
The MDM Server shall be capable of performing the following management functions:
a. choose X.509v3 certificates for MDM Server use
b. configure the [a number of devices] and [
[- configure server session lock timeout,
]] allowed for enrollment,
[d. configure the TOE unlock banner,
e. configure periodicity of the following commands to the agent: [
1. query connectivity status;
2. query the current version of the MD firmware/software;
3. query the current version of the hardware model of the device;
4. query the current version of installed mobile applications]].
5.1.4.10 Specification of Functions (MAS Server) (MDMPP30:FMT_SMF.1(3))
MDMPP30:FMT_SMF.1.1(3)
The MAS Server shall be capable of performing the following management functions:
a. Configure application access groups,
b. Download applications,
c. [no other functions].
3
The iOS Security Target claims “all notifications”, so while the MDMPP30 indicates the choices are a. email
notifications, b. calendar appointments, c. contact associated with phone call notification, d. text message
notification, e. other application-based notifications, f. none, this Security Target is effectively refining the
requirement to indicate “all notifications” to match the claim of the applicable mobile device.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 27 of 45
5.1.4.11 Specification of Management Functions (MDMAEP30:FMT_SMF_EXT.3)
MDMAEP30:FMT_SMF_EXT.3.1
The MDM Agent shall be capable of interacting with the platform to perform the following
functions:
- [administrator-provided device management functions in MDM PP]
- Import the certificates to be used for authentication of MDM Agent communications
- [no additional functions].
MDMAEP30:FMT_SMF_EXT.3.2
The MDM Agent shall be capable of performing the following functions:
- Enroll in management,
- Configure whether users can unenroll from management,
- [configure periodicity of reachability events].
5.1.4.12 Security Management Roles (MDMPP30:FMT_SMR.1(1))
MDMPP30:FMT_SMR.1.1(1)
The MDM Server shall maintain the roles administrator, MD user, and [Server primary
administrator, Security configuration administrator, Device user group administrator,
Auditor].
MDMPP30:FMT_SMR.1.2(1)
The MDM Server shall be able to associate users with roles.
5.1.4.13 User Unenrollment Prevention (MDMAEP30:FMT_UNR_EXT.1)
MDMAEP30:FMT_UNR_EXT.1.1
The MDM Agent shall provide a mechanism to enforce the following behavior upon an attempt to
unenroll the mobile device from management: [prevent the unenrollment from occurring].
5.1.5 Protection of the TSF (FPT)
5.1.5.1 Internal TOE TSF Data Transfer (MDMPP30:FPT_ITT.1)
MDMPP30:FPT_ITT.1.1
The TSF shall protect all data from disclosure and modification through use of [TLS] when it is
transferred between separate parts of the TOE.
5.1.5.2 TSF Functionality Testing (MDMPP30:FPT_TST_EXT.1)
MDMPP30:FPT_TST_EXT.1.1
The [TSF] shall run a suite of self-tests during initial start-up (on power on) to demonstrate
correct operation of the TSF.
MDMPP30:FPT_TST_EXT.1.2
The [TSF] shall provide the capability to verify the integrity of stored TSF executable code when
it is loaded for execution through the use of the [TOE platform]-provided cryptographic services.
5.1.5.3 Trusted Update (MDMPP30:FPT_TUD_EXT.1)
MDMPP30:FPT_TUD_EXT.1.1
The MDM Server shall provide Authorized Administrators the ability to query the current version
of the MDM Server software.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 28 of 45
MDMPP30:FPT_TUD_EXT.1.2
The [TSF] shall provide Authorized Administrators the ability to initiate updates to TSF software.
MDMPP30:FPT_TUD_EXT.1.3
The [TSF] shall provide a means to verify software updates to the TSF using a digital signature
mechanism prior to installing those updates.
5.1.6 TOE access (FTA)
5.1.6.1 TOE Access Banners (MDMPP30:FTA_TAB.1)
MDMPP30:FTA_TAB.1.1
Before establishing a user session, the [TSF, TOE platform] shall display an Administrator-
specified advisory notice and consent warning message regarding use of the TOE.
5.1.7 Trusted path/channels (FTP)
5.1.7.1 Inter-TSF Trusted Channel (Authorized IT Entities) (MDMPP30:FTP_ITC.1(1))
MDMPP30:FTP_ITC.1.1(1)
The [TSF] shall use [TLS, TLS/HTTPS] to provide a trusted communication channel between
itself and authorized IT entities supporting the following capabilities: audit server, [authentication
server] that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from modification or disclosure.
MDMPP30:FTP_ITC.1.2(1)
The TSF shall permit the MDM Server or other authorized IT entities to initiate communication
via the trusted channel.
MDMPP30:FTP_ITC.1.3(1)
The TSF shall initiate communication via the trusted channel for [exporting audit logs and
LDAP authentication requests].
5.1.7.2 Inter-TSF Trusted Channel (MDM Agent) (MDMPP30:FTP_ITC.1(2))
MDMPP30:FTP_ITC.1.1(2)
The TSF shall use [TLS, HTTPS] to provide a trusted communication channel between itself and
another trusted IT product that is logically distinct from other communication channels, provides
assured identification of its end points, protects channel data from disclosure, and detects
modification of the channel data.
MDMPP30:FTP_ITC.1.2(2)
The TSF shall permit the TSF and MDM Agent to initiate communication via the trusted channel.
MDMPP30:FTP_ITC.1.3(2)
The TSF shall initiate communication via the trusted channel for all communication between the
MDM Server and the MDM Agent and [all communication between the MAS Server and the
MDM Agent].
5.1.7.3 Trusted Path (Remote Administration) (MDMPP30:FTP_TRP.1(1))
MDMPP30:FTP_TRP.1.1(1)
The [TSF] shall use [TLS/HTTPS] to provide a trusted communication path between itself and
remote administrators that is logically distinct from other communication paths and provides
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 29 of 45
assured identification of its endpoints and protection of the communicated data from modification,
disclosure.
MDMPP30:FTP_TRP.1.2(1)
The [TSF] shall permit remote administrators to initiate communication via the trusted path.
MDMPP30:FTP_TRP.1.3(1)
The [TSF] shall require the use of the trusted path for all remote administration actions.
5.1.7.4 Trusted Path (for Enrollment) (MDMPP30:FTP_TRP.1(2))
MDMPP30:FTP_TRP.1.1(2)
The [TSF] shall use [TLS/HTTPS] to provide a trusted communication path between itself and
MD users that is logically distinct from other communication paths and provides assured
identification of its endpoints and protection of the communicated data from disclosure and
detection of modification of the communicated data from modification, disclosure.
MDMPP30:FTP_TRP.1.2(2)
The [TSF] shall permit MD users to initiate communication via the trusted path.
MDMPP30:FTP_TRP.1.3(2)
The [TSF] shall require the use of the trusted path for all MD user actions.
5.2 TOE Security Assurance Requirements
The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the SARs have
effectively been refined with the assurance activities explicitly defined in association with both the SFRs and SARs.
Requirement Class Requirement Component
ADV: Development ADV_FSP.1: Basic Functional Specification
AGD: Guidance documents AGD_OPE.1: Operational User Guidance
AGD_PRE.1: Preparative Procedures
ALC: Life-cycle support ALC_CMC.1: Labelling of the TOE
ALC_CMS.1: TOE CM Coverage
ATE: Tests ATE_IND.1: Independent Testing – Conformance
AVA: Vulnerability assessment AVA_VAN.1: Vulnerability Survey
Table 4 Assurance Components
5.2.1 Development (ADV)
5.2.1.1 Basic Functional Specification (ADV_FSP.1)
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.
ADV_FSP.1.1c
The functional specification shall describe the purpose and method of use for each SFR-enforcing
and SFR-supporting TSFI.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 30 of 45
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.
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.
5.2.2 Guidance documents (AGD)
5.2.2.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1d
The developer shall provide operational user guidance.
AGD_OPE.1.1c
The operational user guidance shall describe, for each user role, the useraccessible 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.
AGD_OPE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.2.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1d
The developer shall provide the TOE, including its preparative procedures.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 31 of 45
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.
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.
5.2.3 Life-cycle support (ALC)
5.2.3.1 Labelling of the TOE (ALC_CMC.1)
ALC_CMC.1.1d
The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.1.1c
The TOE shall be labelled with its unique reference.
ALC_CMC.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.3.2 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.1.1d
The developer shall provide a configuration list for the TOE.
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.
ALC_CMS.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.4 Tests (ATE)
5.2.4.1 Independent Testing – Conformance (ATE_IND.1)
ATE_IND.1.1d
The developer shall provide the TOE for testing.
ATE_IND.1.1c
The TOE shall be suitable for testing.
ATE_IND.1.1e
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.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 32 of 45
5.2.5 Vulnerability assessment (AVA)
5.2.5.1 Vulnerability Survey (AVA_VAN.1)
AVA_VAN.1.1d
The developer shall provide the TOE for testing.
AVA_VAN.1.1c
The TOE shall be suitable for testing.
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.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 33 of 45
6. TOE Summary Specification
This chapter describes the security functions:
 Security audit
 Cryptographic support
 Identification and authentication
 Security management
 Protection of the TSF
 TOE access
 Trusted path/channels
6.1 Security audit
MDMPP30:FAU_ALT_EXT.1: The MDM Server component of the TOE can be configured to alert the
administrator on essentially anything in the device configuration database – including newly enrolled devices and
failed policy deployment. Note that while a device could effectively be unenrolled by being factory reset, there is no
explicit unenroll function available to the MDM Agent, though a mobile device can be retired (and hence
unenrolled) at the MDM Server. Alerts can be configured and can be displayed on the administrator console, be sent
to a configured e-mail address, text (SMS), or a push notification to a configured device.
MDMAEP30:FAU_ALT_EXT.2: The TOE supports the ability to periodically synchronize the MDM Server and
MDM Agents. The synchronization includes retrieving information about the policies that are installed, thereby
ensuring the MDM Server is informed about which policies have been applied. The MDM Server can force a check-
in at any time and that would serve to determine MDM Agent connectivity status.
When a mobile device checks in, the mobile device performs a compliance check based on configured policies. If
any of the settings have not been reported to and acknowledged by the MDM server, the mobile device reports those
changes. Hence, if something happens, such as a network disruption, that prevents the MDM server from receiving
the mobile device compliance information or prevents the mobile device from receiving an acknowledgement from
the MDM server, that information will be sent the next time the device connects until it is finally acknowledged.
The MDM Agent will store unsent alerts in the application storage available on the mobile device and that space is
limited only by the space available on the mobile device non-volatile flash.
MDMPP30:FAU_CRP_EXT.1: The MDM Server component of the TOE maintains a configuration database that
can be queried to determine the current configuration of mobile devices and can be used to export that configuration
information. The MDM server maintains a database of device information including OS versions, device model,
installed applications, applied policies, etc. and this information can be exported by an administrator in CSV
(comma separated values) format via the administrator web interface.
See also section 6.4, MDMPP30:FMT_POL_EXT.1 and MDMAEP30:FMT_POL_EXT.2 for more information
about how policies are received and checked prior to application.
MDMPP30:FAU_GEN.1(1): The MDM Server component of the TOE can generate audit events for a wide range of
security-relevant operations including start-up and shutdown, administrator functions, commands sent to MDM
Agents, and others (see Table 2 Server Auditable Events). In addition to identifying the security event, each audit
records incudes a time stamp, identify of the responsible user (where applicable), and the outcome of the event
(success or failure).
MDMAEP30:FAU_GEN.1(2): The MDM Agent component of the TOE is able to generate records of the following
auditable events: start-up and shutdown of the MDM Agent, change in MDM policy, any modification commanded
by the MDM Server, and the auditable events listed in Table 3. The MDM Agent component of the TOE includes in
each audit record the following information: date and time of the event, type of event, subject identity, (if relevant)
the outcome (success or failure) of the event, and the additional information identified in Table 1
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 34 of 45
MDMPP30:FAU_NET_EXT.1: The MDM Server component of the TOE provides the ability for an administrator
to determine the connectivity status of any MDM Agent. Device check-in normally occurs periodically, where an
administrator configured the period. Device check-ins can also be initiated by the mobile device user using the
MDM Agent or by an administrator using the MDM Server web interface to cause an immediate check-in to ensure
or determine the current connectivity status. While an administrator can check the last check-in status of any device
via the administrator web interface, the administrator can also configure a policy to send an alert if a device has not
checked-in for a configured number of days.
MDMPP30:FAU_SAR.1/MDMPP30:FAU_STG_EXT.1(1)/MDMPP30:FAU_STG_EXT.2: The MDM Server
component of the TOE provides the functions necessary for an administrator to review all of the collected audit
records, while ensuring that the audit records cannot be modified. The MDM Server doesn’t offer any functions that
allow the audit log or individual audit records therein to be modified, inserted, or deleted. The MDM Server
component of the TOE also provides the ability to export audit records via a function available in the administrator
web interface and the exported records are protected via the HTTPS/TLS connection to that interface. This export
transmits audit data in either in CSV (comma separated values) format, text format, or a compressed archive format,
depending upon the specific audit data being exported.
MDMPP30: MDMAEP30:FAU_SEL.1(2): The MDM Agent component of the TOE stores most audit records in the
mobile device audit log and thereby leverages the selection functions of the mobile device to allow audited events to
be selected based on the following attributes: event type; success of auditable security events; failure of auditable
security events. The remaining events (e.g., policy signature related audits and agent alerts) not stored in the
platform audit log are always audited (i.e., cannot be de-selected) and are stored locally by the agent in its data space
until delivered to the MDM server.
6.2 Cryptographic support
FCS_CKM.1/FCS_CKM.2/FCS_COP.1(*): The TOE and its platform include and make use of available
cryptographic modules to perform cryptographic operations to support higher level functions (such as
communication protocols).
The MDM Server component includes the Bouncy Castle (1.0.1) cryptographic library (CMVP #3152) – operating
in the Java SE Runtime Environment 8 - and also utilizes the Red Hat Enterprise Linux OpenSSL Module 5.0
(CMVP #3016) cryptographic functions available in its CentOS platform.
The MDM Agent component includes its own OpenSSL (1.0.2h with FIPS) cryptographic library.
In the event of decryption errors, particularly for communication (e.g., key establishment), the associated function
for both the server and agent will fail and be logged, where appropriate, as a higher level session failure with no
specific details about the decryption failure being disclosed.
The available cryptographic functions are as follows:
Requirement Component Function Details
FIPS
Algorithm
Certificate
MDMPP30:FCS_CKM.2 MDM Server generate asymmetric
cryptographic keys used
for key establishment
● 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
RSA- Vendor
affirmed as
no CAVP test
exists
ECDSA
#1191
KAS #135
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 35 of 45
Requirement Component Function Details
FIPS
Algorithm
Certificate
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
MDMPP30:FCS_CKM.2 Server
Platform
generate asymmetric
cryptographic keys used
for key establishment
● 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
RSA- Vendor
affirmed as
no CAVP test
exists
ECDSA
#1144, 1150
CVL #1298,
1318
MDMPP30:FCS_CKM.1 MDM Server generate asymmetric
cryptographic keys used
for authentication
● 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];
● FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Appendix B.1 for FFC
ECDSA
#1191
DSA #1279
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 36 of 45
Requirement Component Function Details
FIPS
Algorithm
Certificate
schemes
MDMPP30:FCS_CKM.1 Server
Platform
generate asymmetric
cryptographic keys used
for authentication
● FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Appendix B.3 for RSA
schemes;
● 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];
● FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Appendix B.1 for FFC
schemes
RSA #2535,
2546
ECDSA
#1144, 1150
DSA #1228,
1237
MDMAEP30:FCS_CKM.2 MDM Agent generate asymmetric
cryptographic keys used
for key establishment
● 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
ECDSA
#1549
CVL #2087
MDMAEP30:FCS_CKM.1 MDM Agent generate asymmetric
cryptographic keys used
for authentication
● 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];
● FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Appendix B.1 for FFC
schemes
ECDSA
#1549
DSA #1466
MDMPP30:FCS_COP.1(3) MDM Server cryptographic signature
services
● RSA Digital Signature
Algorithm (RSA) with a key
size (modulus) of 2048 bits or
greater that meets FIPS PUB
186-2 or FIPS PUB 186-4,
“Digital Signature Standard”,
● Elliptic Curve Digital
RSA #2602
ECDSA
#1191
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 37 of 45
Requirement Component Function Details
FIPS
Algorithm
Certificate
Signature Algorithm (ECDSA)
with a key size of 256 bits or
greater] that meets FIPS PUB
186-4, “Digital Signature
Standard” with “NIST curves”
P-256, P-384 and [P-521] (as
defined in FIPS PUB 186-4,
“Digital Signature Standard”),
MDMPP30:FCS_COP.1(3) Server
Platform
cryptographic signature
services
● RSA Digital Signature
Algorithm (RSA) with a key
size (modulus) of 2048 bits or
greater that meets FIPS PUB
186-2 or FIPS PUB 186-4,
“Digital Signature Standard”,
● Elliptic Curve Digital
Signature Algorithm (ECDSA)
with a key size of 256 bits or
greater] that meets FIPS PUB
186-4, “Digital Signature
Standard” with “NIST curves”
P-256, P-384 and [P-521] (as
defined in FIPS PUB 186-4,
“Digital Signature Standard”),
RSA #2535,
2546
ECDSA
#1144, 1150
MDMPP30:FCS_COP.1(4) MDM Server keyed-hash message
authentication
HMAC-SHA-256, HMAC-
SHA-384, HMAC-SHA-512
with key length equal to output
MAC length, hash function as
identified in the specific
HMAC algorithm, and block
size 512 for HMAC-SHA-256
and 1024 for HMAC-SHA-384
and HMAC-SHA-512
HMAC
#3170
MDMPP30:FCS_COP.1(4) Server
Platform
keyed-hash message
authentication
HMAC-SHA-256, HMAC-
SHA-384, HMAC-SHA-512
with key length equal to output
MAC length, hash function as
identified in the specific
HMAC algorithm, and block
size 512 for HMAC-SHA-256
and 1024 for HMAC-SHA-384
and HMAC-SHA-512
HMAC
#3076, 3090,
3107, 3110
MDMPP30:FCS_COP.1(1) MDM Server encryption/decryption ● AES-CBC (as defined in
NIST SP 800-38A) mode,
● AES-GCM (as defined in
NIST SP 800-38D)
AES #4759
MDMPP30:FCS_COP.1(1) Server
Platform
encryption/decryption ● AES-CBC (as defined in
NIST SP 800-38A) mode,
● AES-GCM (as defined in
NIST SP 800-38D)
AES #4644,
4666, 4695,
4698
MDMPP30:FCS_COP.1(2) MDM Server cryptographic hashing SHA-256, SHA-384, SHA-512 SHS #3807,
3823, 3842,
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 38 of 45
Requirement Component Function Details
FIPS
Algorithm
Certificate
3845
MDMPP30:FCS_COP.1(2) Server
Platform
cryptographic hashing SHA-256, SHA-384, SHA-512 SHS #3901
MDMAEP30:FCS_COP.1(3) MDM Agent cryptographic signature
services
● RSA Digital Signature
Algorithm (RSA) with a key
size (modulus) of 2048 bits or
greater that meets FIPS PUB
186-2 or FIPS PUB 186-4,
“Digital Signature Standard”,
● Elliptic Curve Digital
Signature Algorithm (ECDSA)
with a key size of 256 bits or
greater] that meets FIPS PUB
186-4, “Digital Signature
Standard” with “NIST curves”
P-256, P-384 and [P-521] (as
defined in FIPS PUB 186-4,
“Digital Signature Standard”),
RSA #3068
ECDSA
#1549
MDMAEP30:FCS_COP.1(4) MDM Agent keyed-hash message
authentication
HMAC-SHA-256, HMAC-384
with key length equal to output
MAC length, hash function as
identifed in the specific
HMAC algorithm, and block
size 512 for HMAC-SHA-256
and 1024 for HMAC-SHA-384
HMAC
#3797
MDMAEP30:FCS_COP.1(1) MDM Agent encryption/decryption ● AES-CBC (as defined in
NIST SP 800-38A) mode,
● AES-GCM (as defined in
NIST SP 800-38D)
AES #5700
MDMAEP30:FCS_COP.1(2) MDM Agent cryptographic hashing SHA-256, SHA-384 SHS # 4570
MDMPP30:FCS_RBG_EXT.1 MDM Server DRBG SHA-256 HMAC-DRBG DRBG
#1636
MDMPP30:FCS_RBG_EXT.1 Server
Platform
DRBG AES-256 CTR_DRBG DRBG
#1567,
1578, 1593,
1596
MDMAEP30:FCS_RBG_EXT.1 MDM Agent DRBG AES-256 CTR-DRBG DRBG
#2311
Table 5 Algorithm Certificates
MDMPP30:FCS_CKM_EXT.4/ MDMAEP30:FCS_CKM_EXT.4: The TOE (and MDM server platform) destroys
cryptographic keys when they are no longer in use. Keys stored in memory are overwritten with zeros, while keys
stored on non-volatile media are overwritten as required by FIPS 140-2.
The following keys and CSPs are managed by the MDM Server and MDM Agent.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 39 of 45
Component Key or CSP Where Stored Destruction
MDM Agent Certificate private key Platform key storage Not stored on media in plain
text. Replaced when a new
certificate is received
MDM Agent Certificate private key Volatile memory (in use) Overwritten with zeroes
when the Agent terminates.
MDM Agent TLS session key Volatile memory Overwritten with zeroes
when TLS session terminates
MDM Server Platform Web Portal certificate
private key
Platform key storage Not stored on media in plain
text. Replaced when a new
certificate is loaded
MDM Server Platform Web Portal certificate
private key
Volatile memory (in use) Overwritten with zeroes
when the MDM server
terminates.
MDM Server Local CA certificate issuing
certificate private keys
Platform key storage Not stored on media in plain
text. Replaced when a new
certificate is loaded
MDM Server Local CA certificate issuing
certificate private keys
Volatile memory (in use) Overwritten with zeroes
when the MDM server
terminates.
MDM Server Platform TLS session key Volatile memory Overwritten with zeroes
when TLS session terminates
MDMPP30:FCS_HTTPS_EXT.1/MDMAEP30:FCS_HTTPS_EXT.1: Both the MDM Server and MDM Agent
components of the TOE included the ability to support the HTTPS protocol (compliant with RFC 2818) so that
remote users can securely connect using the web-based user interface and the server and agent can communicate
with each other using HTTPS.
MDMPP30:FCS_RBG_EXT.1: The MDM Server component of the TOE includes a cryptographic module (Bouncy
Castle) and accesses a second cryptographic module (OpenSSL on its platform). In the case of OpenSSL, the library
provides an AES-256 CTR_DRBG (cert #1567, 1578, 1593, 1596) deterministic random bit generation that is
seeded with 384-bits of platform-based entropy with a security strength of 256-bits. In the case of Bouncy Castle,
the MDM Server implements a SHA-256 HMAC-DRBG (cert # 1636) also seeded with 384-bits of platform-based
entropy with a security strength of 256-bits.
MDMAEP30:FCS_RBG_EXT.1: The MDM Agent component of the TOE incudes a cryptographic module
(OpenSSL). The MDM Agent provides an AES-256 CTR-DRBG (cert #2311) seeded using 384-bits (also forming a
256-bit entropy input and 128-bit nonce in conformance with SP 800-90A) of platform-based seeding material and
further conditioned using an OpenSSL conditioning function.
MDMPP30:FCS_STG_EXT.1/ MDMAEP30:FCS_STG_EXT.1(2): Both the MDM Server and MDM Agent
components of the TOE use platform provided storage to store persistent and private keys.
The MDM Server stores each of its keys and certificates (including those used by the MDM Server Platform) in flat
files that are assigned permissions to restrict those keys to the components/processes that use them. The certificates
are further protected using PCKS #12 encryption. The MDM Agent utilizes the Android keystore API on the mobile
device to store its keys and certificates both utilizing the platform storage and the platform encryption of the key
storage.
MDMPP30:FCS_TLSC_EXT.1/MDMPP30:FCS_TLSS_EXT.1: The MDM Server component of the TOE includes
the ability to support the TLS protocol (TLS 1.2 (RFC 5246) only) for the purposes of protecting audit records
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 40 of 45
exported to an external server, protecting communication channels between the MDM Server and MDM Agent, and
protecting (in conjunction with HTTPS) remote web-based administrator sessions. It will reject any attempts to use
other TLS or SSL versions and TLS sessions will not be established if an applicable certificate is found to be invalid
or if the remote network entity doesn’t match the distinguished name (DN) in the certificate. The DN can be an
exact match or a match with a wildcard in accordance with RFC 6125. Note that when a mobile device is enrolled it
is assigned a unique UUID that is associated with the serial number of the device’s certificate. When the mobile
device connects and presents its certificate, the UUID in the certificate is used to look up the certificate serial
number to ensure it matches the certificate that was presented. The MDM Server generates key agreement
parameters using NIST curves secp256r1 and secp384r1 and 2048-bit and 3072-bit Diffie-Hellman parameters. The
specific curve or Diffie-Hellman parameters always corresponds to the server certificate that is configured for client
access and can only be changed by configuring a different server certificate (e.g., an RSA 2048-bit server certificate
will only use 2048-bit Diffie-Hellman). Note also that pinned certificates are not supported by the MDM Server or
Agent.
The MDM Server component of the TOE also includes an LDAP client that acts as a TLS client. It supports the
TLS protocol (TLS 1.0 (RFC 2246), TLS 1.1 (RFC 4346), and TLS 1.2 (RFC 5246)) for the purpose of protecting
the communication channel between the MDM Server and secure LDAP server for authentication. TLS sessions will
not be established if an applicable certificate is found to be invalid or if the remote LDAP server doesn’t match the
distinguished name (DN) in the certificate (i.e., FQDN). Note that the DN can appear in the certificate CN or SAN
and any value in the SAN (when present) always takes precedent over values in the CN. The LDAP client supports
only NIST curves secp256r1, secp384r1, and secp521r1 when using elliptic curve ciphers. This is the default
behavior and there is no means to enable additional curves in the LDAP client.
The MDM Agent component of the TOE includes the ability to support the TLS protocol (TLS 1.0 (RFC 2246),
TLS 1.1 (RFC 4346), and TLS 1.2 (RFC 5246)) for the purposed of protecting the communication channel between
the MDM Server and MDM Agent. TLS sessions will not be established if an applicable certificate if found to be
invalid or if the remote network entity doesn’t match the distinguished name (DN) in the certificate (i.e., FQDN).
The MDM Agent supports only NIST curves secp256r1, secp384r1, and secp521r1 when using elliptic curve
ciphers. This is the default behavior and there is no means to enable additional curves in the MDM Agent.
The following ciphers are supported by both the MDM Server and MDM Agent:
 TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
 TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
 TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246,
 TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, and
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289].
The LDAP client supports all the ciphers listed above.
6.3 Identification and authentication
MDMPP30:FIA_ENR_EXT.1: When a new device is being enrolled, the initial connection is made using TLS
where only the MDM Server certificate is authenticated by the MDM Agent. Once the TLS connection is
established, the mobile device user must be authenticated with a PIN or username and password that are configured
on the MDM Server. Only after the MDM Server determines that the device can be enrolled (including ensuring the
user has not exceeded the maximum number of enrolled devices), the device is provisioned with an X.509v3
certificate so that subsequent communication between the MDM Agent and MDM Server will be protected by
mutually authenticated TLS. When enrolled (and later when synchronizing), the MDM Server checks the OS version
on the mobile device and will quarantine the device if it doesn’t meet any configured restrictions. Note that
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 41 of 45
quarantine removes most enterprise configurations, but leaves the ability to check-in. If the device is determined to
be in compliance during a subsequent check-in, the quarantined accesses will be restored.
MDMAEP30:FIA_ENR_EXT.2: During enrollment, the MDM Agent records the unique URL (FQDN) of the
MDM Server for future communication purposes. This value is initially configured by the mobile device user when
attempting to enroll the mobile device.
MDMPP30:FIA_UAU.1: The MDM Server component of the TOE requires users to login (be authenticated) before
they can perform any security-related functions. Mobile device users are initially authenticated using a provided PIN
or password and after that the MDM Agent uses its provisioned X.509v3 certificate to authenticate itself to the
MDM Server. Administrators are assigned usernames and passwords used for authentication when access the MDM
Server via the local console or web-based user interfaces.
MDMPP30:FIA_X509_EXT.1/MDMPP30:FIA_X509_EXT.2: The MDM Server component of the TOE uses
X.509v3 certificates as part of TLS authentication and will not establish TLS sessions if the applicable certificates
cannot be determined to be valid. Certificate validation includes checking the validation path, basicConstraints,
revocation, and extendedKeyUsage properties (see MDMPP30:FIA_X509_EXT.1.1).
MDMAEP30:FIA_X509_EXT.1/MDMAEP30:FIA_X509_EXT.2: The MDM Agent component of the TOE uses
X.509v3 certificates as part of TLS authentication and will not establish TLS sessions if the applicable certificate is
not valid. It also performs the validation checks including checking the validation path, basicConstraints, revocation,
and extendedKeyUsage properties (see MDMAEP30:FIA_X509_EXT.1.1).
6.4 Security management
MDMPP30:FMT_MOF.1(1)/MDMPP30:FMT_MOF.1(3)/MDMPP30:FMT_MOF.1(4): The MDM Server
component of the TOE restricts all security management functions (identified below for FMT_SMF.1(1)/
FMT_SMF.1(3)) to an authorized administrator. This is accomplished by role-based access controls (described
below) assigned to each of the functions. Note that applications and application updates are generally handled just
like policies – they are packaged using XML and digitally signed along with any other policy elements and sent
securely from the MDM server to the MDM agent via secure TLS. Applications and updates can be initiated by the
MDM server by creating a configuration policy that includes the application or update – in this case the application
will be sent to the MDM agent during its next check-in. Alternately, the MDM server can be configured with a list
of available applications and a mobile device user can use the MDM agent to query that list to select and install any
available applications or associated updates.
MDMPP30:FMT_MOF.1(2): While most security management functions are restricted to an authorized
administrator, the authorized administrator can enable mobile device users to enroll their mobile device. An
authorized administrator registers a given device and provides the mobile device user a 6-12 digit PIN or password
(that can be more than 15 characters) that will allow them to enroll the device.
MDMPP30:FMT_POL_EXT.1 The MDM Server provides digitally signed policies and policy updates to the MDM
Agent. Policies and policy updates (including policy settings, configurations, and applications) are formatted using
XML and the entire XML structure is hashed using SHA-256. The hash is then signed by the MDM server using the
configured portal certificate (RSA-2048 or ECDSA-P384) and the signed hash is added to the policy structure prior
to being sent to any agents via a secure TLS channel.
MDMAEP30:FMT_POL_EXT.2: The MDM Agent only accepts policies and policy updates that are digitally
signed by the Enterprise. When the MDM Agent checks-in with the MDM server, the MDM server will send any
policy or policy updates to the MDM agent via a secure TLS channel if the policy or policy update has not yet been
applied by the MDM agent. When the MDM agent receives the policy or policy update, it creates a SHA-256 hash
of its contents (less the signed hash), verifies the hash matches and then verifies that the hash was signed using the
same MDM server portal certificate that was used to receive the policy or policy update. The MDM agent will only
install policies and policy updates if both the hash matches and the hash was signed by the expected certificate. If
the verification fails, the policy or policy update is discarded and an alert is sent to the MDM server. This process is
repeated during the next checking since the policy current on the MDM server has not been applied.
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 42 of 45
MDMPP30:FMT_SAE_EXT.1: The MDM Server component of the TOE allows PINs to be issued to users for
device enrollment. The PINs are assigned expiration periods after which they can no longer be used by the user to
enroll a mobile device. Note that there is no similar expiration limit for usernames and passwords that might
alternately be used for device enrollment.
MDMPP30:FMT_SMF.1(1): A primary function of the MDM Server component of the TOE is to manage mobile
devices via installed MDM Agent components. The MDM Server supports the following commands and
configuration policies on the mobile devices identified in section 1.4.1.1:
 transition to the locked state
 full wipe of protected data
 unenroll from management
 install policies
 query connectivity status
 query the current version of the MD firmware/software
 query the current version of the hardware model of the device
 query the current version of installed mobile applications
 import X.509v3 certificates into the Trust Anchor Database
 install applications
 update system software
 remove applications and Enterprise applications
 remove imported X.509v3 certificates and default X.509v3 certificates in the Trust Anchor Database
(Samsung only)
 import keys/secrets into the secure key storage
 destroy imported keys/secrets in the secure key storage
 read audit logs kept by the mobile device (Samsung only)
 password Policy:
- minimum password length
- minimum password complexity
- maximum password lifetime
 session locking Policy:
- screen-lock enabled/disabled
- screen lock timeout
- number of authentication failures
 wireless networks (SSIDs) to which the MD may connect protection (Samsung only)
 security Policy for each wireless network:
- specify the CA(s) from which the MD will accept WLAN authentication server certificate(s)
- ability to specify security type
- ability to specify authentication protocol
- specify the client credentials to be used for authentication
 application installation Policy by
- specifying authorized application repository(s) (Google Playstore and MDM application server)
(Samsung only)
- specifying a set of allowed applications and versions (an application whitelist) (Samsung only)
- denying application installation (iOS only)
 enable/disable policy for the camera and microphone (Camera-only on iOS)
 enable/disable policy for the VPN (iOS only)
 enable/disable policy for NFC, Bluetooth, Wi-Fi, and cellular radios (Samsung only)
 enable/disable policy for protocols supporting remote access (Hotspot, USB, and Bluetooth tethering)
(Samsung only)
 enable/disable policy for developer modes (Samsung only)
 enable policy for data-at rest protection (Samsung only)
 enable policy for removable media's data-at-rest protection (Samsung only)
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 43 of 45
 enable/disable policy for display notification in the locked state of all notifications (iOS only)
 certificate used to validate digital signature on applications (iOS only)
 unlock banner policy
 configure the auditable items (Samsung only)
 enable/disable USB mass storage mode (Samsung only)
 enable/disable location services (Samsung only)
 enable/disable policy for use of Biometric Authentication Factor
MDMPP30:FMT_SMF.1(2): In addition to managing mobile devices, the MDM Server component of the TOE
supports the security management functions to configure and manage itself, including configuring a login banner.
Among the available security management functions are the ability to configure X.509v3 certificates, managing the
device registration process (enrolling specific devices and limiting the number of devices a user can enroll),
configure server session lock timeout, configure periodicity of the following commands to the agent, query
connectivity status, query the current version of the MD firmware/software, query the current version of the
hardware model of the device, and query the current version of installed mobile applications.
MDMPP30:FMT_SMF.1(3): Furthermore, in support of application hosting, the MDM server (which also serves as
a MAS server) supports the configuration of application groups in the form of labels assigned to individual apps and
devices. It also supports the ability to download applications for deployment.
MDMAEP30:FMT_SMF_EXT.3/MDMAEP30:FMT_UNR_EXT.1: The MDM Agent component of the TOE can
be configured with a X.509v3 certificate suitable to facilitate secure communication with the MDM Server. This
certificate is provisioned during device enrollment. The MDM Server can be configured to use an external CA or to
use a local CA using an administrator-configured certificate to sign CSRs from the MDM Agent during enrollment.
Once secure communication is enabled and the device is enrolled, the MDM Agent accepts commands and policies
from the enrolled MDM Server and implements those commands and policies (identified above). The MDM Agent
can also be unenrolled from an enrolled MDM Server. This is accomplished by retiring the mobile device on the
MDM Server or alternately by using the Android Settings - Device Administrators function to remove the MDM
Agent Administrator access on the mobile device. Note that the MDM Agent can restrict the ability to unenroll and
enrolled device using policy settings. Specifically, the mobile device user can be denied the permission to take
away the administrator privileges from the MDM agent.
Once an MDM Agent is enrolled, it offers a limited set of trouble shooting functions to the mobile device user: force
check-in, send agent log, reinstall certificates, and show warnings.
MDMPP30:FMT_SMR.1(1): The MDM Server component of the TOE implements a role-based access mechanism.
Initially, there is only one security management role by default – administrator – and additional roles can be
configured. The administrator has access to the local console command-line interface to perform low-level
management functions as well as access to the web-based System Manager and Admin Portals. Within the Admin
Portal additional users can be defined and assigned specific user and management roles as follows.
Users can connect to a user portal and perform functions on devices assigned to that user depending on their
assigned roles. The following list of roles can be individually assigned to each user:
 Wipe Device (cause the registered device to be reset)
 Lock Device (lock the device)
 Unlock Device (unlock the device)
 Locate Device (retrieve location information from the device)
 Retire Device (unenroll the device)
 Register Device (initiate a PIN registration request or send registration instructions for a device)
 Change Device Ownership (change the device ownership to another defined user)
User added in the Admin Portal cannot access the web-based System Manager or console command-line interfaces.
Furthermore, added users can access the Admin Portal only if they have been assigned an administrator role. The
following administrator roles can be individually assigned to each user:
 View dashboard, device page, device details
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 44 of 45
 Manage devices
 Manage devices, restricted
 Wipe device
 Add device
 Manage ActiveSync device
 Manage AppTunnel
 Manage device enrollment (iOS)
 Delete retired device
 View apps in device details
 Locate device
 View label
 Manage Label
 View user
 Manage user
 Manage app
 Apply and remove application label
 View configuration
 Manage configuration
 Apply and remove configuration
 View policy
 Manage policy
 Apply and remove policy label
 View settings
 Manage settings
 View logs and events
 Manage logs and events
 Manage administrators and device spaces
 Manage content
 View content, apply and remove content labels
The role settings allow fine-grained definition of administrative users.
Minimally the following roles are supported in the TOE:
 Administrator – This is the initial administrator that has full control of all functions.
 Mobile device user – This is a user added in the Admin Portal, but not assigned ant administrative roles.
 Enrolled mobile device – This is a mobile device that has been enrolled by a mobile device user.
 Application access group – The TOE allows “Labels” to be defined and apps to be assigned. Devices can
also be assigned to labels and the associated services to restrict or allow access to corresponding apps.
 Server primary administrator – Same as Administrator above.
 Security configuration administrator – This is a user with access to the web-based System Manager and
console command-line interfaces, as well as most of the Admin Portal manage roles.
 Device user group administrator – This is a user that minimally has the manage user Admin Portal role, but
is not assigned the manage administrators and device spaces role.
 Auditor – This is a user that minimally has the manage logs and events Admin Portal role. If necessary for
a given deployment, an auditor can be provided access to the System Manager Portal to have access to low
level protocol audit records (application logs).
6.5 Protection of the TSF
MDMPP30:FPT_ITT.1: The TOE provides a trusted channel between the MDM Server and Android MDM Agent
that is protected through the use of TLS. During enrollment, only the MDM Server is authenticated by the MDM
Agent. Once enrolled, all communication between the MDM Server and MDM Agent is protected using this channel
MobileIron Platform (MDMPP30/MDMAEP30) Version 0.8, 01/04/2019
Security Target
Page 45 of 45
using mutual authentication. Note that the MDM server also performs the MAS server functions, so the only
distributed TOE components are the MDM server and associated MDM agents.
MDMPP30:FPT_TST_EXT.1: The MDM Server utilizes FIPS 140-2 certified cryptographic modules that include
self-tests to ensure the available cryptographic operations (including AES, RSA, ECDSA, SHA, HMAC-SHA
functions) are performing correctly when starting up.
The MDM Server leverages its platform RPM Package Manager (RPM) functions to verify the integrity of its own
executable files during start-up. The platform maintains a database of all installed RPMs, including the TOE, and
during boot each RPM is checked for integrity with the standard CentOS (Redhat) RPM integrity checking
functions. Any errors are reported on the console and the MDM Server will attempt to restart if an error is detected
without intervention by an administrator.
MDMPP30:FPT_TUD_EXT.1: The MDM Server component of the TOE provides functions to query and update the
MDM Server software version. When updating the MDM Server software, each new update is installed as an RPM
package and is verified using a MobileIron digital signature prior to installation.
RPMs are signed with GPG (GNU’s PGP version). The MobileIron signing key is RSA 2048 and the CentOS
signing key is RSA 4096. When a package is installed, RedHat/CentOS validate the PGP signature on the package.
The RPM includes digests of the files within the RPM. These digests are stored in a database on the system during
package install. During boot, the contents of each file are verified against the stored digests.
6.6 TOE access
MDMPP30:FTA_TAB.1: The MDM Server component of the TOE can be configured to display an administrator-
defined message when an administrator is logging onto the MDM Server to access available security functions.
The web-based user interfaces (including the System Manager and Admin Portal) can be configured with a textual
banner up to 2048 characters that is displayed on the login screen. The local console interface can be configured
separately with a textual banner that is displayed immediately upon connecting, but before the user logs in (when
using a password).
6.7 Trusted path/channels
MDMPP30:FTP_ITC.1(1): The MDM Server uses TLS to secure communication when exporting audit records (this
is really part of FTP_TRP.1(1) below) as well as an external LDAP authentication server.
MDMPP30:FTP_ITC.1(2): The TOE provides a trusted channel between the MDM Server and iOS MDM Agent
that is protected through the use of TLS. During enrollment, only the MDM Server is authenticated by the MDM
Agent. Once enrolled, all communication between the MDM Server and MDM Agent is protected using this channel
using mutual authentication.
MDMPP30:FTP_TRP.1(1): The MDM Server provides a web-based user interface (including a System Manager
and Admin Portal) to the MDM Server for remote administration. Each web-based session can be initiated by
administrators and is protected through the use of HTTPS/TLS.
MDMPP30:FTP_TRP.1(2): The MDM Server provides a TLS interface as described above for
MDMPP30:FPT_ITT.1 that can be accessed by mobile device users via the MDM Agent.