NIAP: Compliant Product
  NIAP  »»  Product Compliant List  »»  Compliant Product  
Compliant Product - MobileIron Core / Mobile@Work for Android

Certificate Date:  2016.06.14

Validation Report Number:  CCEVS-VR-VID10584-2016

Product Type:    Mobility

Conformance Claim:  Protection Profile Compliant

PP Identifier:    Extended Package for Mobile Device Management Agents Version 2.0
  Protection Profile for Mobile Device Management Version 2.0

CC Testing Lab:  Gossamer Security Solutions

CC Certificate [PDF] Security Target [PDF] Validation Report [PDF]

Assurance Activity [PDF]

Administrative Guide [PDF]

Product Description

The Target of Evaluation (TOE) the MobileIron Core server and associated MobileIron Client (referred to as Mobile@Work) agents for Android devices that are part of their MobileIron Platform. 

MobileIron 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 device, application, and content management.

MobileIron Client ( – also known as Mobile@Work – is an app downloaded by end users onto their mobile devices. It automatically 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.

Evaluated Configuration

The evaluated software version is Core version 9.0 and Mobile@Work Version 8.6.  The Core component of the TOE is an application installed on a CentOS system provided by MobileIron.  The Mobile@Work component of the TOE evaluated mobile device running Android 4.4.  It relies on its evaluated platform’s Android API for generating keys as well as handling key wrapping. The TOE invokes Android’s cryptographic API to generate keys through Android’s KeyGenerator API, for use during TLS communication.

Security Evaluation Summary

The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) requirements and guidance. The evaluation demonstrated that the TOE meets the security requirements contained in the Security Target.  The criteria against which the TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012. 

The product, when delivered and configured as identified in the MobileIron Core and Android Client Mobile Device Management Protection Profile Guide, Version 1.0, March 24, 2016 document, satisfies all of the security functional requirements stated in the MobileIron Platform (MDMPP20 and MDMAEP20) Security Target, Version 1.0, May 27, 2016.  The project underwent CCEVS Validator review.  The evaluation was completed in March 2016.  Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report (report number CCEVS-VR-10584-2016) prepared by CCEVS.

Environmental Strengths

The logical boundaries of the MobileIron Core and MD Agent software application packages are realized in the security functions that it implements. Each of these security functions is summarized below.

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 includes the ability to indicate (i.e., respond) when it has been enrolled and when policies are 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 he administrator when a policy update fails or an MDM Agent has been enrolled.

Cryptographic support: The MDM Server and MDM Agent both include and/or utilize cryptographic modules or libraries with National Voluntary Laboratory Accreditation Program (NVLAP) Cryptographic Algorithm Validation Program (CAVP) validated 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, HTTPS, and SSH used for communication between the MDM Server and MDM Agent and between the MDM Server and remote administrators.

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.

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 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 and enrolled MDM Server, and report the results of applying policies.

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.

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.

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. In addition, the MDM Server implements a restricted shell (CLISH) that is accessible via SSH to provide access to low level management functions.

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.

Vendor Information

Brian Mansfield
Site Map              Contact Us              Home