Version | Date | Comment |
---|---|---|
1.0 | 2013-10-21 | Initial Release |
1.1 | 2014-02-07 | Typographical changes and clarifications to front-matter |
2.0 | 2014-12-31 | Separation of MDM Agent SFRs Updated cryptography, protocol, X.509 requirements. Updated management functions to match MDFPPv2.0. Included SSH as a remote administration protocol. Removed IPsec as protocol to communicate to MDM Agent. Added X509 enrollment objective requirement. Added Optional Mobile Application Store requirements. |
3.0 | 2016-11-21 | Updates to align with Technical Decisions Added requirements to support BYOD use case Removed IPsec and SSH requirements, which are now contained in EPs |
4.0 | 2018-09-24 |
Updates to align with Technical Decisions Removed platform dependency Removed TLS SFRs and utilize the TLS Functional Package Allowed for a distributed TOE |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
Common Criteria Testing Laboratory | Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Extended Package (EP) | An implementation-independent set of security requirements for a category of products, which extends those in a Protection Profile. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles.. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Security Assurance Requirement (SAR) | A requirement for how the TOEs proper implementation of the SFRs is verified by an evaluator. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
TSF Data | Data for the operation of the TSF that is used to enforce its security requirements. |
Administrator | The person who is responsible for management activities, including setting the policy that is applied by the enterprise on the mobile device. |
Application Programming Interface (API) | A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. API's are often provided for a set of libraries included with the platform. |
Critical Security Parameter (CSP) | Security-related information whose disclosure or modification can compromise the security of a cryptographic module and/or authentication system. |
Data | Program or application or data files that are stored or transmitted by a server or MD. |
Data Encryption Key (DEK) | A key used to encrypt data-at-rest. |
Developer Modes | States in which additional services are available to a user in order to provide enhanced system access for debugging of software. |
Enrolled State | The state in which a mobile device is managed by a policy from an MDM. |
Enterprise Applications | Applications that are provided and managed by the enterprise as opposed to a public application store. |
Enterprise Data | Any data residing in enterprise servers or temporarily stored on mobile devices to which the mobile device user is allowed access according to the security policy defined by the enterprise and implemented by the administrator. |
Enrollment over Secure Transport (EST) | Cryptographic protocol that describes an X.509 certificate management protocol targeting public key infrastructure (PKI) clients that need to acquire client certificates and associated certificate authority (CA) certificates. |
Key Encryption Key (KEK) | A key that is used to encrypt other keys, such as (DEKs) or storage repositories that contain keys. |
Locked State | Mobile device state where the device is powered on but most functionality is unavailable for use without authentication. |
Mobile Device (MD) | A device which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other MDs. |
Mobile Device Management (MDM) | Products that allow enterprises to apply security policies to MDs. This system consists of two primary components: the MDM Server and the MDM Agent. |
Mobile Device User | The person who uses and is held responsible for a MD. |
Operating System (OS) | Software which runs at the highest privilege level and can directly control hardware resources. Modern mobile devices typically have at least two primary operating systems: one which runs on the cellular baseband processor and one which runs on the application processor. The platform of the application processor handles most user interaction and provides the execution environment for apps. The platform of the cellular baseband processor handles communications with the cellular network and may control other peripherals. The term OS, without context, may be assumed to refer to the platform of the application processor. |
Powered-Off State | Mobile device shutdown state. |
Protected Data | All non-TSF data on the mobile device, including user or enterprise data. Protected data is encrypted while the mobile device is in the powered-off state. This includes keys in software-based storage. May overlap with sensitive data. |
Root Encryption Key (REK) | A key tied to a particular device that is used to encrypt all other keys for that device. |
Sensitive Data | Data that is encrypted by the mobile device. May include all user or enterprise data or may be data for specific applications such as emails, messaging, documents, calendar items, or contacts. May be protected while the mobile device is in the locked state. Must include at minimum some keys in software-based key storage. |
Trust Anchor Database | A list of trusted root Certificate Authority certificates. |
Unenrolled State | Mobile device state when it is not managed by an MDM. |
Unlocked State | Mobile device state where it is powered on and its functionality is available for use. |
Requirement | Description | Distributed TOE SFR Allocation |
FAU_ALT_EXT.1 | Server Alerts | One |
FAU_CRP_EXT.1 | Support for Compliance Reporting of Mobile Device Configuration | One |
FAU_GEN.1(1) | Audit Data Generation | All |
FAU_GEN.1(2) | Audit Data Generation | Feature Dependent |
FAU_NET_EXT.1 | Network Reachability Review | One |
FAU_SAR.1 | Audit Review | Feature Dependent |
FAU_SEL.1 | Security Audit Event Selection | One |
FAU_STG_EXT.1 | External Trail Storage | All |
FAU_STG_EXT.2 | Audit Event Storage | Feature Dependent |
FCO_CPC_EXT.1 | Communication Partner Control | All |
FCS_CKM.1 | Cryptographic Key Generation | Feature Dependent |
FCS_CKM.2 | Cryptographic Key Establishment | All |
FCS_CKM_EXT.4 | Cryptographic Key Destruction | All |
FCS_COP.1.1(1) | Cryptographic Operation (Confidentiality Algorithms) | All |
FCS_COP.1.1(2) | Cryptographic Operation (Hashing Algorithms) | All |
FCS_COP.1.1(3) | Cryptographic Operation (Signature Algorithms) | All |
FCS_COP.1.1(4) | Cryptographic Operation (Keyed-Hash Message Authentication) | All |
FCS_HTTPS_EXT.1 | HTTPS Protocol | Feature Dependent |
FCS_IV_EXT.1 | Initialization Vector Generation | Feature Dependent |
FCS_RBG_EXT.1 | Random Bit Generation | All |
FCS_STG_EXT.1 | Cryptographic Key Storage | All |
FCS_STG_EXT.2 | Encrypted Cryptographic Key Storage | Feature Dependent |
FIA_ENR_EXT.1 | Enrollment of Mobile Device into Management | One |
FIA_UAU.1 | Timing of Authentication | One |
FIA_UAU_EXT.4(1) | User Authentication | One |
FIA_UAU_EXT.4(2) | User Authentication | One |
FIA_X509_EXT.1(1) | X.509 Certification Validation | Feature Dependent |
FIA_X509_EXT.1(2) | X.509 Certification Validation | Feature Dependent |
FIA_X509_EXT.2 | X.509 Certificate Authentication | Feature Dependent |
FIA_X509_EXT.3 | X.509 Enrollment | Feature Dependent |
FIA_X509_EXT.4 | Alternate X.509 Enrollment | Feature Dependent |
FIA_X509_EXT.5 | X.509 Unique Certificate | One |
FMT_MOF.1(1) | Management of functions behaviour | Feature Dependent |
FMT_MOF.1(2) | Management of functions behaviour (Enrollment) | Feature Dependent |
FMT_MOF.1(3) | Management of Functions in (MAS Server Downloads) | Feature Dependent |
FMT_POL_EXT.1 | Trusted Policy Update | One |
FMT_SAE_EXT.1 | Security Attribute Expiration | One |
FMT_SMF.1(1) | Specification of Management Functions (Server configuration of Agent) | One |
FMT_SMF.1(2) | Specification of Management Functions (Server configuration of Server) | Feature Dependent |
FMT_SMF.1(3) | Specification of Management Functions (MAS Server) | Feature Dependent |
FMT_SMR.1(1) | Security Management Roles | One |
FMT_SMR.1(2) | Security Management Roles | Feature Dependent |
FPT_API_EXT.1 | Use of Supported Services and API's | All |
FPT_ITT.1(1) | Internal TOE TSF Data Transfer | Feature Dependent |
FPT_ITT.1(2) | Internal TOE TSF Data Transfer (To MDM Agent) | Feature Dependent |
FPT_LIB_EXT.1 | Use of Third Party Libraries | All |
FPT_TST_EXT.1 | Functionality Testing | All |
FPT_TUD_EXT.1 | Trusted Update | All |
FTA_TAB.1 | Default TOE Access Banners | One |
FTP_ITC.1(1) | Inter-TSF Trusted Channel (Authorized IT Entities) | One |
FTP_ITC.1(2) | Inter-TSF Trusted Channel (MDM Agent) | One |
FTP_ITC_EXT.1 | Trusted Channel | One |
FTP_TRP.1(1) | Trusted Path for Remote Administration | Feature Dependent |
FTP_TRP.1(2) | Trusted Path for Enrollment | Feature Dependent |
FTP_TRP.1(3) | Trusted Path for Joining | Feature Dependent |
Threat, Assumption, or OSP | Security Objectives | Rationale |
T.MALICIOUS_APPS | O.APPLY_POLICY, O.INTEGRITY | The threat T.MALICIOUS_APPS is countered by O.APPLY_POLICY as this provides the capability to limit the ability to install applications on the MD. The threat T.MALICIOUS_APPS is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. |
T.NETWORK_ATTACK | O.DATA_PROTECTION_TRANSIT | The threat T.NETWORK_ATTACK is countered by O.DATA_PROTECTION_TRANSIT as this provides authentication of the endpoints of a trusted communication path. |
T.NETWORK_EAVESDROP | O.DATA_PROTECTION_TRANSIT, O.QUALITY | The threat T.NETWORK_EAVESDROP is countered by O.DATA_PROTECTION_TRANSIT as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside and within the TOE.
The threat T.NETWORK_EAVESDROP is countered by O.QUALITY as this provides the capability to invoke platform resources to ensure quality of implementation. |
T.PHYSICAL_ACCESS | O.APPLY_POLICY | The threat T.PHYSICAL_ACCESS is countered by O.APPLY_POLICY as this provides the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process. |
A.COMPONENTS_RUNNING (applies to distributed TOEs only) | OE.COMPONENTS_RUNNING | The operational environment objective OE.COMPONENTS_RUNNING is realized through A.COMPONENTS_RUNNING. |
A.CONNECTIVITY | OE.WIRELESS_NETWORK | The operational environment objective OE.WIRELESS_NETWORK is realized through A.CONNECTIVITY. |
A.MDM_SERVER_PLATFORM | OE.TIMESTAMP | The operational environment objective OE.TIMESTAMP is realized through A.MDM_SERVER_PLATFORM. |
A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
A.PROPER_USER | OE.PROPER_USER | The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. |
P.ACCOUNTABILITY | O.ACCOUNTABILITY | The organizational security policy O.ACCOUNTABILITY is realized through P.ACCOUNTABILITY. |
P.ADMIN | OE.PROPER_ADMIN | The organizational security policy P.ADMIN is realized through OE.PROPER_ADMIN. |
P.DEVICE_ENROLL | OE.IT_ENTERPRISE | The organizational security policy P.DEVICE_ENROLL is realized through OE.IT_ENTERPRISE. |
P.NOTIFY | OE.PROPER_USER | The organizational security policy P.NOTIFY is realized through OE.PROPER_USER. |
Assurance Class | Assurance Components |
Security Target (ASE) |
ST introduction (ASE_INT.1) Conformance claims (ASE_CCL.1) Security objectives for the operational environment (ASE_OBJ.1) Extended components definition (ASE_ECD.1) Stated security requirements (ASE_REQ.1) TOE summary specification (ASE_TSS.1) |
Development (ADV) | Basic functional specification (ADV_FSP.1) |
Guidance documents (AGD) | Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) |
Life cycle support (ALC) | Labeling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) |
Tests (ATE) | Independent testing - sample (ATE_IND.1) |
Vulnerability assessment (AVA) | Vulnerability survey (AVA_VAN.1) |
Cipher Mode | Reference | IV Requirement |
Electronic Codebook (ECB) | SP800-38A | No IV |
Counter (CTR) | SP800-38A | "Initial Counter" shall be non-repeating. No counter value shall be repeated across multiple messages with the same secret key. |
Cipher Block Chaining (CBC) | SP800-38A | IVs shall be unpredictable. Repeating IVs leak information about whether the first one or more blocks are shared between two messages, so IVs should be non-repeating in such situations. |
Output Feedback (OFB) | SP800-38A | IVs shall be non-repeating and shall not be generated by invoking the cipher on another IV. |
Cipher Feedback (CFB) | SP800-38A | IVs should be non-repeating as repeating IVs leak information about the first plaintext block and about common shared prefixes in messages. |
XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing (XTS) |
SP800-38E | No IV. Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer. |
Cipher-based Message Authentication Code (CMAC) | SP800-38B | No IV |
Key Wrap and Key Wrap with Padding | SP800-38F | No IV |
Counter with CBC-Message Authentication Code (CCM) | SP800-38C | No IV. Nonces shall be non-repeating. |
Galois Counter Mode (GCM) | SP800-38D | IV shall be non-repeating. The number of invocations of GCM shall not exceed 2^32 for a given secret key unless an implementation only uses 96-bit IVs (default length). |
Factor | Same/Different | Guidance |
PP-Specified Funtionality | Same | If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. |
Different | If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences. |
Factor | Same/Different | Guidance |
Product Models | Different | Versions of different Product Models are not equivalent unless the Models are equivalent as defined in subsection 3. |
PP-Specified Funtionality | Same | If the differences affect only non-PP-specified functionality, then the Versions are equivalent. |
Different | If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences. |
Factor | Same/Different/None | Guidance |
Platform Architectures | Different | Platforms that present different processor architectures and instruction sets to the MDM are not equivalent. |
PP-Specified Funtionality | Same | For platforms with the same processor architecture, the platforms are equivalent with respect to the MDM if execution of all PP-specified security functionality follows the same code path on both platforms. |
Factor | Same/Different/None | Guidance |
Platform Architectures | Different | Platforms that run on different processor architectures and instruction sets are not equivalent. |
Platform Vendors | Different | Platforms from different vendors are not equivalent. |
Platform Versions | Different | Platforms from the same vendor with different major version numbers are not equivalent. |
Platform Interfaces | Different | Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the MDM. |
Platform Interfaces | Same | Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the MDM, or if the Platform does not provide such functionality to the MDM. |
Factor | Same/Different/None | Guidance |
Platform Type/Vendor | Different | Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container. |
Platform Versions | Different | Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers. |
PP-Specified Security Functionality | Same | All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to MDMs. |
Requirement | Action |
FMT_SMF.1.1(1) Function 32 | Include in ST and assign GPS. |
FMT_SMF.1.1(1) Function 34 | Include in ST. Assign personal hotspot connections (if feature exists). |
FMT_SMF.1.1(1) Function 47 | Include in ST. |
FMT_SMF.1.1(1) Function 49 | Include in ST and select "a. USB mass storage mode". |
FMT_SMF.1.1(1) Function 51 | Include in ST. Select both options. |
Requirement | Action |
FMT_SMF.1.1(1) Function 15 | Include in ST. |
FMT_SMF.1.1(1) Function 16 | Include in ST. |
FMT_SMF.1.1(1) Function 31 | Include in ST and select "no other method". |
FMT_SMF.1.1(1) Function 32 | Include in ST. |
FMT_SMF.1.1(1) Function 33 | Include in ST. Assign at least USB. |
FMT_SMF.1.1(1) Function 34 | Include in ST. Assign all protocols where the TSF acts as a server. |
FMT_SMF.1.1(1) Function 36 | Include in ST. |
FMT_SMF.1.1(1) Function 37 | Include in ST. |
FMT_SMF.1.1(1) Function 40 | Include in ST. |
FMT_SMF.1.1(1) Function 42 | Include in ST. |
FMT_SMF.1.1(1) Function 47 | Include in ST. |
FMT_SMF.1.1(1) Function 52 | Include in ST. |
FMT_SMF.1.1(1) Function 54 | Include in ST. |
FMT_SMF.1.1(1) Function c | Include in ST. |
FMT_SMF.1.1(1) Function d | Include in ST. |
FCS_CKM.1.1 | Select RSA with key size of 3072 or select ECC schemes. |
FCS_CKM.2.1 | Select "RSA schemes" or select "ECC schemes". |
FCS_COP.1.1(1) | Select 256 bits |
FCS_COP.1.1(2) | Select SHA-384 |
FCS_COP.1.1(3) | Select RSA with key size of 3072 or select ECC schemes. |
FIA_X509_EXT.2.2 | Select either "allow the administrator to choose…" or "not accept the certificate". |
FCS_TLSC_EXT.1.1 (from TLS Package) | If included in ST, select "TLS 1.2". |
FCS_TLSC_EXT.2.1 (from TLS Package) | If included in ST, select "secp384r1". |
Requirement | Action |
FMT_SMF.1.1(1) Function 13 | Include in ST |
FMT_SMF.1.1(1) Function 14 | Include in ST |
FMT_SMF.1.1(1) Function 21 | Include in ST |
FMT_SMF.1.1(1) Function 22 | Include in ST |
FMT_SMF.1.1(1) Function 30 | Select "on a per-app basis" and/or "on a per-group of application processes basis" |
FMT_SMF.1.1(1) Function 31 | If included in ST, select "on a per-app basis" and/or "on a per-group of application processes basis" |
FMT_SMF.1.1(1) Function 48 | Include in ST |
FMT_SMF.1.1(1) Function 52 | If included in ST, select "on a per-app basis" and/or "on a per-group of application processes basis" |
FMT_SMF.1.1(2) Function f | Include in the ST |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 4, September 2012. |
[CSA] | Computer Security Act of 1987, H.R. 145, June 11, 1987. |
[OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |
[MDF PP] | Protection Profile for Mobile Device Fundamentals, Version 3.0, June 2016 |
[MDM Agent PP] | Protection Profile for Mobile Device Management, Version 3.0, October 2016 |