Apple Inc.
© 2019 Apple Inc.
This document may be reproduced and distributed only in its original entirety without revision
Apple iPad and iPhone Mobile
Devices with iOS 12
Security Target
PP_MD_V3.1
with
EP_MDM_AGENT_V3.0,
PP_WLAN_CLI_EP_V1.0,
MOD_VPN_CLI_V2.1.
Version 1.6
2019-03-12
VID: 10937
Prepared for:
Apple Inc.
One Apple Park Way
MS 927-1CPS
Cupertino, CA 95014
www.apple.com
Prepared by:
atsec information security Corp.
9130 Jollyville Road, Suite 260
Austin, TX 78759
www.atsec.com
VID: 10937
Page 2 of 172 © 2019 Apple Inc. Version: 1.6
Table of Contents
Revision History.......................................................................................................................9
1 Security Target Introduction ..........................................................................................11
1.1 Security Target Reference ............................................................................................... 11
1.2 TOE Reference .................................................................................................................. 11
1.3 TOE Overview.................................................................................................................... 11
1.4 TOE Description................................................................................................................. 12
1.4.1 General information.............................................................................................. 12
1.4.2 Obtaining the mobile devices.............................................................................. 12
1.4.3 Obtaining software updates ................................................................................ 13
1.4.4 Supervising and configuring the mobile devices ............................................. 13
1.4.5 Mobile devices covered by this evaluation ....................................................... 13
1.5 TOE Architecture ............................................................................................................... 28
1.5.1 Physical Boundaries............................................................................................. 29
1.5.2 Security Functions provided by the TOE .......................................................... 29
1.5.3 TOE Documentation............................................................................................. 34
1.5.4 Other References ................................................................................................. 35
2 Conformance Claims.......................................................................................................36
2.1 CC Conformance ............................................................................................................... 36
2.2 Protection Profile (PP) Conformance ............................................................................. 36
2.2.1 Technical Decisions ............................................................................................. 36
2.3 Conformance Rationale.................................................................................................... 37
3 Security Problem Definition ...........................................................................................38
3.1 Threats ................................................................................................................................ 38
3.2 Assumptions ....................................................................................................................... 41
3.3 Organizational Security Policies...................................................................................... 42
4 Security Objectives..........................................................................................................43
4.1 Security Objectives for the TOE...................................................................................... 43
4.2 Security Objectives for the TOE Environment .............................................................. 44
5 Extended Components Definition..................................................................................46
6 Security Functional Requirements ................................................................................47
6.1 Security Audit (FAU).......................................................................................................... 48
Agent Alerts (FAU_ALT)............................................................................................................. 48
FAU_ALT_EXT.2 Extended: Agent Alerts ..................................................................... 48
Audit Data Generation (FAU_GEN).......................................................................................... 48
FAU_GEN.1(1) Audit Data Generation .......................................................................... 48
FAU_GEN.1(2) Audit Data Generation .......................................................................... 50
Security Audit Event Selection (FAU_SEL)............................................................................. 52
FAU_SEL.1(2) Security Audit Event Selection ............................................................. 52
Security Audit Event Storage (FAU_STG) .............................................................................. 52
FAU_STG.1 Audit Storage Protection............................................................................ 52
FAU_STG.4 Prevention of Audit Data Loss .................................................................. 52
6.2 Cryptographic Support (FCS) .......................................................................................... 53
Cryptographic Key Management (FCS_CKM)........................................................................ 53
FCS_CKM.1(1) Cryptographic Key Generation............................................................ 53
VID: 10937
Page 3 of 172 © 2019 Apple Inc. Version: 1.6
FCS_CKM.1/WLAN Cryptographic Key Generation (Symmetric Keys for WPA2
Connections) ......................................................................................................... 53
FCS_CKM.1/VPN VPN Cryptographic Key Generation (IKE).................................... 53
FCS_CKM.2(1) Cryptographic Key Establishment ...................................................... 53
FCS_CKM.2(2) Cryptographic Key Establishment (While device is locked) ........... 54
FCS_CKM.2/WLAN WLAN Cryptographic Key Distribution (GTK) ........................... 54
FCS_CKM_EXT.1 Extended: Cryptographic Key Support (REK) ............................. 54
FCS_CKM_EXT.2 Extended: Cryptographic Key Random Generation ................... 54
FCS_CKM_EXT.3 Extended: Cryptographic Key Generation.................................... 54
FCS_CKM_EXT.4 Extended: Key Destruction ............................................................. 55
FCS_CKM_EXT.5 Extended: TSF Wipe........................................................................ 55
FCS_CKM_EXT.6 Extended: Salt Generation.............................................................. 55
FCS_CKM_EXT.7 Extended: Cryptographic Key Support (REK) ............................. 56
Cryptographic Operations (FCS_COP).................................................................................... 57
FCS_COP.1(1) Confidentiality Algorithms..................................................................... 57
FCS_COP.1(2) Hashing Algorithms............................................................................... 57
FCS_COP.1(3) Signature Algorithms............................................................................. 57
FCS_COP.1(4) Keyed Hash Algorithms........................................................................ 57
FCS_COP.1(5) Password-Based Key Derivation Functions ...................................... 57
HTTPS Protocol (FCS_HTTPS)................................................................................................ 58
FCS_HTTPS_EXT.1 Extended: HTTPS Protocol ........................................................ 58
IPsec Protocol (FCS_IPSEC) .................................................................................................... 58
FCS_IPSEC_EXT.1 Extended: IPsec ............................................................................ 58
Initialization Vector Generation (FCS_IV)................................................................................ 59
FCS_IV_EXT.1 Extended: Initialization Vector Generation........................................ 59
Random Bit Generation (FCS_RBG) ....................................................................................... 60
FCS_RBG_EXT.1(Kernel and User space) Extended: Cryptographic Operation
(Random Bit Generation) .................................................................................... 60
FCS_RBG_EXT.1(SEP) Extended: Cryptographic Operation (Random Bit
Generation)............................................................................................................ 60
Cryptographic Algorithm Services (FCS_SRV) ...................................................................... 60
FCS_SRV_EXT.1 Extended: Cryptographic Algorithm Services............................... 60
Cryptographic Key Storage (FCS_STG).................................................................................. 61
FCS_STG_EXT.1 Extended: Secure Key Storage ...................................................... 61
FCS_STG_EXT.2 Extended: Encrypted Cryptographic Key Storage....................... 61
FCS_STG_EXT.3 Extended: Integrity of Encrypted Key Storage ............................. 61
FCS_STG_EXT.4 Extended: Cryptographic Key Storage.......................................... 62
TLS Client Protocol (FCS_TLSC) ............................................................................................. 62
FCS_TLSC_EXT.1 Extended: TLS Protocol................................................................. 62
FCS_TLSC_EXT.1/WLAN Extended: Extensible Authentication Protocol-Transport
Layer Security (EAP-TLS)................................................................................... 62
FCS_TLSC_EXT.2 Extended: TLS Protocol................................................................. 63
6.3 User Data Protection (FDP) ............................................................................................. 64
Access Control (FDP_ACF)....................................................................................................... 64
FDP_ACF_EXT.1 Extended: Security Access Control................................................ 64
Data-At-Rest Protection (FDP_DAR) ....................................................................................... 64
FDP_DAR_EXT.1 Extended: Protected Data Encryption ........................................... 64
FDP_DAR_EXT.2 Extended: Sensitive Data Encryption............................................ 64
Subset Information Flow Control - VPN (FDP_IFC) .............................................................. 64
FDP_IFC_EXT.1 Extended: Subset Information Flow Control................................... 64
Storage of Critical Biometric Parameters (FDP_PBA) .......................................................... 65
VID: 10937
Page 4 of 172 © 2019 Apple Inc. Version: 1.6
FDP_PBA_EXT.1 Extended: Storage of Critical Biometric Parameters................... 65
Residual Information Protection (FDP_RIP) ........................................................................... 65
FDP_RIP.2 Full Residual Information Protection ......................................................... 65
Certificate Data Storage (FDP_STG)....................................................................................... 65
FDP_STG_EXT.1 Extended: User Data Storage......................................................... 65
Inter-TSF User Data Protected Channel (FDP_UPC) ........................................................... 65
FDP_UPC_EXT.1 Extended: Inter-TSF User Data Transfer Protection................... 65
6.4 Identification and Authentication (FIA) ........................................................................... 66
Authentication Failures (FIA_AFL)............................................................................................ 66
FIA_AFL_EXT.1 Extended: Authentication Failure Handling ..................................... 66
Bluetooth Authorization and Authentication (FIA_BLT)......................................................... 66
FIA_BLT_EXT.1 Extended: Bluetooth User Authorization.......................................... 66
FIA_BLT_EXT.2 Extended: Bluetooth Mutual Authentication .................................... 66
FIA_BLT_EXT.3 Extended: Rejection of Duplicate Bluetooth Connections ............ 66
FIA_BLT_EXT.4 Extended: Secure Simple Pairing ..................................................... 67
Biometric Authentication (FIA_BMG) ....................................................................................... 67
FIA_BMG_EXT.1 Extended: Accuracy of Biometric Authentication.......................... 67
FIA_BMG_EXT.2 Extended: Biometric Enrollment...................................................... 68
FIA_BMG_EXT.3 Extended: Biometric Verification ..................................................... 68
FIA_BMG_EXT.5 Extended: Handling Unusual Biometric Templates...................... 68
Enrollment of Mobile Device into Management (FIA_ENR) ................................................. 68
FIA_ENR_EXT.2 Extended: Enrollment of Mobile Device into Management.......... 68
Port Access Entity Authentication (FIA_PAE)......................................................................... 69
FIA_PAE_EXT.1 Extended: PAE Authentication.......................................................... 69
Password Management (FIA_PMG) ........................................................................................ 69
FIA_PMG_EXT.1 Extended: Password Management................................................. 69
Authentication Throttling (FIA_TRT)......................................................................................... 69
FIA_TRT_EXT.1 Extended: Authentication Throttling ................................................. 69
User Authentication (FIA_UAU) ................................................................................................ 69
FIA_UAU.5 Multiple Authentication Mechanisms......................................................... 69
FIA_UAU.6 Re-Authentication......................................................................................... 69
FIA_UAU.7 Protected authentication feedback ............................................................ 70
FIA_UAU_EXT.1 Extended: Authentication for Cryptographic Operation................ 70
FIA_UAU_EXT.2 Extended: Timing of Authentication................................................. 70
X509 Certificates (FIA_X509_EXT).......................................................................................... 70
FIA_X509_EXT.1 Extended: Validation of Certificates................................................ 70
X509 Certificate Authentication (FIA_X509_EXT) ................................................................. 71
FIA_X509_EXT.2 Extended: X509 Certificate Authentication.................................... 71
FIA_X509_EXT.2/WLAN Extended: X509 Certificate Authentication (EAP-TLS)... 71
Request Validation of Certificates (FIA_X509_EXT) ............................................................. 71
FIA_X509_EXT.3 Extended: Request Validation of Certificates ............................... 71
6.5 Security Management (FMT) ........................................................................................... 72
Management of Functions in TSF (FMT_MOF)...................................................................... 72
FMT_MOF_EXT.1 Extended: Management of Security Functions Behavior .......... 72
Trusted Policy Update (FMT_POL) .......................................................................................... 72
FMT_POL_EXT.2 Trusted Policy Update...................................................................... 72
Specification of Management Functions (FMT_SMF) ........................................................... 72
FMT_SMF_EXT.1 Extended: Specification of Management Functions.................... 72
FMT_SMF_EXT.1/WLAN Specification of Management Functions .......................... 75
FMT_SMF.1/VPN Specification of Management Functions {VPN} ........................... 75
VID: 10937
Page 5 of 172 © 2019 Apple Inc. Version: 1.6
FMT_SMF_EXT.2 Extended: Specification of Remediation Actions......................... 76
FMT_SMF_EXT.3 Extended: Specification of Management Functions.................... 76
User Unenrollment Prevention .................................................................................................. 76
FMT_UNR_EXT.1 Extended: User Unenrollment Prevention.................................... 76
6.6 Protection of the TSF (FPT)............................................................................................. 77
Anti-Exploitation Services (FPT_AEX)..................................................................................... 77
FPT_AEX_EXT.1 Extended: Anti-Exploitation Services (ASLR) ............................... 77
FPT_AEX_EXT.2 Extended: Anti-Exploitation Services (Memory Page
Permissions).......................................................................................................... 77
FPT_AEX_EXT.3 Extended: Anti-Exploitation Services (Overflow Protection)....... 77
FPT_AEX_EXT.4 Extended: Domain Isolation............................................................. 77
JTAG Disablement (FPT_JTA).................................................................................................. 77
FPT_JTA_EXT.1 Extended: JTAG Disablement.......................................................... 77
Key Storage (FPT_KST) ............................................................................................................ 77
FPT_KST_EXT.1 Extended: Key Storage..................................................................... 77
FPT_KST_EXT.2 Extended: No Key Transmission..................................................... 78
FPT_KST_EXT.3 Extended: No Plaintext Key Export................................................. 78
Self-Test Notification (FPT_NOT)............................................................................................. 78
FPT_NOT_EXT.1 Extended: Self-Test Notification ..................................................... 78
Reliable Time Stamps (FPT_STM)........................................................................................... 78
FPT_STM.1 Reliable Time Stamps ................................................................................ 78
TSF Functionality Testing (FPT_TST) ..................................................................................... 78
FPT_TST_EXT.1 Extended: TSF Cryptographic Functionality Testing.................... 78
FPT_TST_EXT.1/VPN Extended: TSF Self-Test ......................................................... 78
FPT_TST_EXT.1/WLAN TSF Cryptographic Functionality Testing {WLAN}.......... 78
TSF Integrity Testing................................................................................................................... 79
FPT_TST_EXT.2 Extended: TSF Integrity Testing...................................................... 79
FPT_TST_EXT.3 Extended: TSF Integrity Testing ...................................................... 79
Trusted Update (FPT_TUD) ...................................................................................................... 79
FPT_TUD_EXT.1 Extended: Trusted Update: TSF Version Query .......................... 79
Trusted Update Verification (FPT_TUD_EXT)........................................................................ 79
FPT_TUD_EXT.2 Extended: Trusted Update Verification .......................................... 79
FPT_TUD_EXT.3 Extended: Trusted Update Verification .......................................... 80
FPT_TUD_EXT.4 Extended: Trusted Update Verification .......................................... 80
6.7 TOE Access (FTA) ............................................................................................................ 81
Session Locking (FTA_SSL)...................................................................................................... 81
FTA_SSL_EXT.1 Extended: TSF and User-initiated Locked State........................... 81
Default TOE Access Banners (FTA_TAB) .............................................................................. 81
FTA_TAB.1 Default TOE Access Banners.................................................................... 81
Wireless Network Access (FTA_WSE) .................................................................................... 81
FTA_WSE_EXT.1 Extended: Wireless Network Access ............................................ 81
6.8 Trusted Path/Channels (FTP).......................................................................................... 82
Trusted Channel Communication (FTP_ITC) ......................................................................... 82
FTP_ITC_EXT.1(1) Extended: Trusted Channel Communication............................. 82
FTP_ITC_EXT.1(2) Extended: Trusted Channel Communication............................. 82
FTP_ITC_EXT.1/WLAN(3) Extended: Trusted Channel Communication ................ 82
6.9 Security Functional Requirements Rationale................................................................ 83
7 Security Assurance Requirements................................................................................84
7.1 Security Target Evaluation (ASE) ................................................................................... 84
7.1.1 Conformance Claims (ASE_CCL.1) .................................................................. 84
VID: 10937
Page 6 of 172 © 2019 Apple Inc. Version: 1.6
7.1.2 Extended Components Definition (ASE_ECD.1)............................................. 85
7.1.3 ST Introduction (ASE_INT.1) .............................................................................. 86
7.1.4 Security Objectives for the Operational Environment (ASE_OBJ.1)............ 86
7.1.5 Stated Security Requirements (ASE_REQ.1).................................................. 87
7.1.6 Security Problem Definition (ASE_SPD.1) ....................................................... 87
7.1.7 TOE Summary Specification (ASE_TSS.1)...................................................... 88
7.2 Development (ADV) .......................................................................................................... 88
7.2.1 Basic Functional Specification (ADV_FSP.1) .................................................. 88
7.3 Guidance documents (AGD)............................................................................................ 88
7.3.1 Operational User Guidance (AGD_OPE.1) ...................................................... 88
7.3.2 Preparative Procedures (AGD_PRE.1)............................................................. 89
7.4 Life-cycle support (ALC) ................................................................................................... 90
7.4.1 Labelling of the TOE (ALC_CMC.1) .................................................................. 90
7.4.2 TOE CM Coverage (ALC_CMS.1)..................................................................... 90
7.4.3 Timely Security Updates (ALC_TSU_EXT.1) .................................................. 90
7.5 Tests (ATE)......................................................................................................................... 91
7.5.1 Independent Testing - Conformance (ATE_IND.1)......................................... 91
7.6 Vulnerability assessment (AVA)...................................................................................... 91
7.6.1 Vulnerability Survey (AVA_VAN.1) .................................................................... 91
8 TOE Summary Specification (TSS)................................................................................92
8.1 Mapping to the Security Functional Requirements ...................................................... 92
8.2 Hardware Protection Functions ..................................................................................... 122
8.2.1 The Secure Enclave........................................................................................... 122
8.2.2 Memory Protection ............................................................................................. 122
8.3 Cryptographic Support.................................................................................................... 123
8.3.1 Overview of Key Management ......................................................................... 123
8.3.2 Storage of Persistent Secrets and Private Keys by the Agent.................... 126
8.3.3 Randomness extraction step ............................................................................ 131
8.3.4 Explanation of usage for cryptographic functions.......................................... 133
8.4 User Data Protection (FDP) ........................................................................................... 139
8.4.1 Protection of Files............................................................................................... 139
8.4.2 Application Access to Files ............................................................................... 139
8.4.3 Declaring the Required Device Capabilities of an Application .................... 139
8.4.4 App Groups.......................................................................................................... 140
8.4.5 Restricting Applications Access to Services .................................................. 140
8.4.6 Keychain Data Protection.................................................................................. 140
8.4.7 VPN....................................................................................................................... 141
8.4.8 Keyed Hash ......................................................................................................... 141
8.5 Identification and Authentication (FIA) ......................................................................... 142
8.5.1 Biometric Authentication.................................................................................... 143
8.5.2 Certificates........................................................................................................... 144
8.5.3 MDM Server Reference ID................................................................................ 145
8.6 Specification of Management Functions (FMT) .......................................................... 146
8.6.1 Enrollment............................................................................................................ 146
8.6.2 Configuration Profiles......................................................................................... 147
8.6.3 Biometric Authentication Factors (BAFs)........................................................ 148
8.6.4 Unenrollment ....................................................................................................... 149
8.6.5 Radios .................................................................................................................. 149
8.6.6 Audio and Visual collection devices ................................................................ 150
8.6.7 VPN Certificate Credentials .............................................................................. 150
VID: 10937
Page 7 of 172 © 2019 Apple Inc. Version: 1.6
8.7 Protection of the TSF (FPT)........................................................................................... 150
8.7.1 Secure Boot......................................................................................................... 150
8.7.2 Joint Test Action Group (JTAG) Disablement................................................ 150
8.7.3 Secure Software Update ................................................................................... 151
8.7.4 Security Updates ................................................................................................ 151
8.7.5 Domain Isolation ................................................................................................. 152
8.7.6 Device Locking.................................................................................................... 152
8.7.7 Time...................................................................................................................... 153
8.7.8 Inventory of TSF Binaries and Libraries.......................................................... 153
8.7.9 Self-Tests............................................................................................................. 153
8.8 TOE Access (FTA) .......................................................................................................... 157
8.8.1 Session Locking.................................................................................................. 157
8.8.2 Restricting Access to Wireless Networks ....................................................... 158
8.8.3 Lock Screen / Access Banner Display ............................................................ 158
8.9 Trusted Path/Channels (FTP)........................................................................................ 158
8.9.1 EAP-TLS and TLS.............................................................................................. 159
8.9.2 Bluetooth.............................................................................................................. 160
8.9.3 Wireless LAN....................................................................................................... 160
8.9.4 VPN....................................................................................................................... 163
8.10 Security Audit (FAU)........................................................................................................ 165
8.10.1 Audit Records...................................................................................................... 165
8.10.2 MDM Agent Alerts .............................................................................................. 166
8.11 Inventory of TSF binaries and libraries ........................................................................ 168
Abbreviations and Acronyms............................................................................................. 169
Table of Figures
Figure 1: Layers of iOS .................................................................................................................. 28
Figure 2: Block Diagram of the Apple CoreCrypto Cryptographic Module for ARM ...................... 30
Figure 3: Block Diagram of the Apple CoreCrypto Kernel Module for ARM .................................. 31
Figure 4: Block Diagram of the Apple Secure Key Store Cryptographic Module........................... 32
Figure 5: Key Hierarchy in iOS..................................................................................................... 128
Table of Tables
Table 1: Devices Covered by the Evaluation ................................................................................. 27
Table 2: Combined mandatory auditable events from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0]...................................................................................................... 50
Table 3: Auditable events from [EP_MDM_AGENT_V3.0]............................................................. 51
Table 4: Management Functions .................................................................................................... 75
Table 5: Mapping of SFR Assurance Activities to the TSS........................................................... 121
Table 6: Summary of keys and persistent secrets in iOS 12........................................................ 126
Table 7: Summary of keys and persistent secrets used by the Agent ......................................... 127
Table 8: Explanation of usage for cryptographic functions in the cryptographic modules ........... 137
Table 9: Keychain to File-system Mapping................................................................................... 141
Table 10: MDM Server Reference Identifiers ............................................................................... 146
Table 11: Apple CoreCrypto Cryptographic Module for ARM Cryptographic Algorithm Tests...... 154
VID: 10937
Page 8 of 172 © 2019 Apple Inc. Version: 1.6
Table 12: Apple CoreCrypto Kernel Cryptographic Module for ARM Cryptographic Algorithm Tests
............................................................................................................................................... 155
Table 13: Apple Secure Key Store v9.0 Cryptographic Algorithm Tests....................................... 157
Table 14: Protocols used for trusted channels ............................................................................. 158
Table 15: WiFi Alliance certificates............................................................................................... 163
Table 16: MDM Agent Status Commands .................................................................................... 166
VID: 10937
Page 9 of 172 © 2019 Apple Inc. Version: 1.6
Revision History
Version Date Change
1.0 2018-08-23 Initial version
1.6 2019-03-12 Final version
VID: 10937
Page 10 of 172 © 2019 Apple Inc. Version: 1.6
© Copyright Apple Inc. 2019. All Rights Reserved.
The following terms are trademarks of Apple Inc. in the United States, other countries, or
both:
• AirPrint®
• App Store®
• Apple®
• Apple Pay®
• Apple Store®
• Cocoa®
• Cocoa Touch®
• Face ID®
• iCloud®
• iPad®
• iPad Air®
• iPad mini™
• iPad Pro®
• iPhone®
• iTunes®
• Keychain®
• Lightning®
• macOS®
• OS X®
• Safari®
• Touch ID®
• Xcode®
The following term is a trademark of Cisco in the United States, other countries, or both:
• IOS®
Common Criteria is a registered trademark of the National Security Agency, a federal agency
of the United States.
VID: 10937
Page 11 of 172 © 2019 Apple Inc. Version: 1.6
1 Security Target Introduction
This document is the Common Criteria (CC) Security Target (ST) for the Apple iOS 12
operating system on various hardware platforms, listed in section 1.4, TOE Description, to be
evaluated as Mobile Devices in exact conformance with:
• The Mobile Device Fundamentals Protection Profile Version 3.1, dated 16 June, 2017
[PP_MD_V3.1];
o The Extended Package for Mobile Device Management Agents Version 3.0
[EP_MDM_AGENT_V3.0], dated 21 November, 2016;
o The General Purpose Operating Systems Protection Profile/ Mobile Device
Fundamentals Protection Profile Extended Package (EP) Wireless Local Area
Network {WLAN} Clients, Version 1.0, dated 8 February, 2016
[PP_WLAN_CLI_EP_V1.0]; and
o The PP-Module for Virtual Private Network {VPN} Clients, Version 2.1, dated 5
October, 2017 [MOD_VPN_CLI_V2.1].
For the sake of readability, in this document the term “PP-Group” has been used to refer to
this set of PPs, PP-Modules and Extended Packages.
1.1 Security Target Reference
ST Title: Apple iPad and iPhone Mobile Devices with iOS 12
ST Version: Version 1.6
ST Date: 2019-03-12
1.2 TOE Reference
Target of Evaluation (TOE) Identification
• Apple iPad and iPhone Mobile Devices with iOS 12
(Please refer to section 1.4, TOE Description, for specific device information.)
• The TOE guidance documentation as detailed in section 1.5.3, TOE Documentation
• TOE Developer: Apple Inc
• Evaluation Sponsor: Apple Inc
1.3 TOE Overview
The TOE is a series of Apple iPad and iPhone mobile devices running the iOS 12 operating
system, an MDM agent which is included on the mobile devices as an application, a WLAN
client application component also executing on the mobile devices and VPN capabilities.
With the exception of the iPad Pro devices, all of the devices, listed in this ST were tested
using iOS 12.0 The iPad Pro devices were tested using iOS 12.1 since this release of iOS 12
added the necessary support for the newly released devices. Note that iOS 12.1 did not
introduce any new security functionality.
The operating system manages the device hardware, provides mobile device agent
functionality, and provides the technologies required to implement native apps. iOS 12
provides a built-in Mobile Device Management (MDM) framework application programmer
interface (API), giving management features that may be utilized by external MDM solutions,
allowing enterprises to use profiles to control some of the device settings.
iOS 12 provides a consistent set of capabilities allowing the supervision of enrolled devices.
This includes the preparation of devices for deployment, the subsequent management of the
devices, and the termination of management.
VID: 10937
Page 12 of 172 © 2019 Apple Inc. Version: 1.6
The TOE provides cryptographic services for the encryption of data-at rest, for secure
communication channels, for protection of Configuration Profiles, and for use by applications.
User data protection is provided by encrypting the user data, restricting access by
applications and by restricting access until the user has been successfully authenticated.
User identification and authentication is provided by a user defined passphrase (and in some
devices supplemented by biometric technologies) where the minimum length of the
passphrase, passphrase rules, and the maximum number of consecutive failed authentication
attempts can be configured by an administrator.
Security management capabilities are provided to users via the user interface of the device
and to administrators through the installation of Configuration Profiles on the device. This
installation can be done using the Apple Configurator tool or by using an MDM system.
The TOE protects itself by having its own code and data protected from unauthorized access
(using hardware provided memory protection features), by encrypting user and TOE Security
Functionality (TSF) data using TSF protected keys and encryption/decryption functions, by
self-tests, by ensuring the integrity and authenticity of TSF updates and downloaded
applications, and by locking the TOE upon user request or after a defined time of user
inactivity.
In addition, the TOE implements a number of cryptographic protocols that can be used to
establish a trusted channel to other IT entities.
The MDM Agent provides secure alerts to the MDM Server indicating status events.
1.4 TOE Description
1.4.1 General information
The TOE is a series of Apple iPad and iPhone mobile devices running the iOS 12 operating
system, an MDM agent which is included on the mobile devices as an application, a WLAN
client application component also executing on the mobile devices, and VPN support.
The TOE is intended to be used as a communication solution providing mobile staff
connectivity to enterprise data.
The TOE hardware is uniquely identified by the model number (See Table 1: Devices
Covered by the Evaluation), and the TOE software is identified by its version number: Apple
iOS 12. The TOE includes documentation that is listed in section 1.5.3, TOE Documentation.
The TOE provides wireless connectivity and includes support for VPN connection; for access
to the protected enterprise network, enterprise data and applications; and for communicating
with other Mobile Devices.
The TOE does not include the user applications that run on top of the operating system, but
does include controls that limit application behavior and enforces data segregation and
impermeability across applications by establishing containerization principles. The TOE may
be used as a mobile device within an enterprise environment where the configuration of the
device is managed through an MDM solution.
1.4.2 Obtaining the mobile devices
The normal distribution channels for a regular end user to obtain these hardware devices
include the following.
• The Apple Store (either a physical store or online at https://apple.com)
• Apple retailers
• Service carriers (e.g., AT&T, Verizon)
• Resellers
Business
VID: 10937
Page 13 of 172 © 2019 Apple Inc. Version: 1.6
There is a distinct online store for Business customers with a link from the “Apple Store.”
From the link to the “Apple Store” (https://www.apple.com), go to the upper left of the page
and click “Business Store Home.” Or optionally, use the following link.
https://www.apple.com/us_smb_78313/shop
Government
Government customers can use the following link.
https://www.apple.com/r/store/government/
Additional
Large customers can also have their own Apple Store Catalog for their employees to
purchase devices directly from Apple under their corporate employee purchase program.
1.4.3 Obtaining software updates
iOS devices support wireless software updates. Software update availability can be prompted
on the device with a message pushed in the Notification Center, or with a button in the
General Settings. Installation of the latest version of iOS can be performed automatically (if
the Software Automatic Update Settings are turned ON), manually from the device, or
manually using iTunes.
At the highest level, the operating system part of the TOE acts as an intermediary between
the underlying hardware and the apps operating on the TOE. Apps do not talk to the
underlying hardware directly. Instead, they communicate with the hardware through a set of
well-defined system interfaces. These interfaces make it easy to write apps that work
consistently on devices having different hardware capabilities.
1.4.4 Supervising and configuring the mobile devices
The TOE provides an interface allowing the enterprise to supervise devices under their
control.
Supervision gives enterprises greater control over the iOS devices they are responsible for.
With supervision, the administrator can apply extra restrictions like turning off AirDrop or
preventing access to the App Store. It also provides additional device configurations and
features, like silently updating apps or filtering web usage.
The TOE needs to be configured by an authorized administrator to operate in compliance with
the requirements defined in this [ST]. The evaluated configuration for this includes:
• the requirement to define a passcode for user authentication,
• the specification of a passcode policy defining criteria on the minimum length and
complexity of a passcode,
• the specification of the maximum number of consecutive failed attempts to enter the
passcode,
• the specification of the session locking policy,
• the specification of the audio and video collection devices allowed,
• the specification of the virtual private network (VPN) connection,
• the specification of the wireless networks allowed, and
• the requirement of the certificates in the trust anchor database.
1.4.5 Mobile devices covered by this evaluation
Table 1: Devices Covered by the Evaluation, following, lists the devices that are covered by
this evaluation and gives the technical characteristics of each.
VID: 10937
Page 14 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A8 iPhone 6 A1549
802.11
/a/b/g/n/ac
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
4.2
2.4
GHz
Touch
ID
1
4345
A1586 CDMA EV-DO Rev. A and Rev. B (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
A1589 CDMA EV-DO Rev. A and Rev. B (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
iPhone 6 Plus A1522 UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
4.2
2.4
GHz
Touch
ID
1
4345
A1524 CDMA EV-DO Rev. A and Rev. B (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
A1593 CDMA EV-DO Rev. A and Rev. B (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
iPad mini 4 A1538 Wi-Fi only
4.2
N/A
Touch
ID
1
4350
A1550 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29, 38, 39,
40, 41)
A8X iPad Air 2 A1566
8
0
2
.
1
1
a
/
b
/
g
/
n
/
a
c
Wi-Fi only 4.2
N
/
A
T
o
u
c
h
I
D
1
4
3
5
0
VID: 10937
Page 15 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A1567 GSM/EDGE (850, 900, 1800, 1900 MHz),
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz),
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz),
TD-SCDMA
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17,18, 19, 20, 25, 26, 28, 29)
TD-LTE (Bands 38, 39, 40,41)
VID: 10937
Page 16 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A9 iPhone 6s A1633
802.11
/a/b/g/n/ac
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29, 30)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
CDMA EV-DO Rev. A (800, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
4.2
2.4
GHz
Touch
ID
2
4350
A1688 LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1691
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1700
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
iPhone 6s Plus A1634
802.11
/a/b/g/n/ac
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29, 30)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
CDMA EV-DO Rev. A (800, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
4.2
2.4
GHz
Touch
ID
2
A1687 LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
VID: 10937
Page 17 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A1690
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1699
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
iPhone SE A1662
802.11
/a/b/g/n/ac
LTE (Bands 1, 2, 3, 4, 5, 8, 12, 13, 17, 18, 19, 20, 25, 26, 29)
CDMA EVDO Rev. A (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DCHSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
4.2
2.4
GHz
Touch
ID
1
43452
A1723
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 17, 18, 19, 20, 25, 26, 28)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EVDO Rev. A (800, 1700/2100, 1900, 2100 MHz)
UMTS/HSPA+/DCHSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1724
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 17, 18, 19, 20, 25, 26, 28)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
iPad 9.7-inch
(5th
generation)
A1822
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
1
4355
A1823 UMTS/HSPA/HSPA+/ DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29,
38, 39, 40, 41)
VID: 10937
Page 18 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A9X iPad Pro 9.7-
inch
A1673
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
1
4355
A1674 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25,
26, 27, 28, 29, 30, 38, 39, 40, 41)
A1675 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25,
26, 27, 28, 29, 30, 38, 39, 40, 41)
iPad Pro 12.9-
inch
A1584
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
1
4350
A1652 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 13, 17, 18, 19, 20, 25, 26, 28, 29, 38,
39, 40, 41)
VID: 10937
Page 19 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A10 Fusion iPhone 7 A1660
802.11
/a/b/g/n/ac
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27,
28, 29, 30)
TD-LTE (Bands 38, 39, 40, 41)
4.2
2.4
GHz
Touch
ID
3
4355
A1779
(Japan)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26,
27, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1780
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1778 UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27,
28, 29, 30)
TD-LTE (Bands 38, 39, 40, 41)
iPhone 7 Plus A1661
802.11
/a/b/g/n/ac
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
TD-SCDMA 1900 (F), 2000 (A)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27,
28, 29, 30)
TD-LTE (Bands 38, 39, 40, 41)
4.2
2.4
GHz
Touch
ID
3
A1785
(Japan)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26,
27, 28, 29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1786
(China)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27, 28,
29)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
VID: 10937
Page 20 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A1784 UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 27,
28, 29, 30)
TD-LTE (Bands 38, 39, 40, 41)
iPad
9.7-inch
(6th
generation)
A1893
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
3
A1954 UMTS/HSPA/HSPA+/ DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900
MHz)
CDMA EV-DO Rev. A (800, 1900 MHz)
LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29,
30, 38, 39, 40, 41)
VID: 10937
Page 21 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A10X
Fusion
iPad Pro
12.9-inch
(2nd
generation)
A1670
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
3
4355
A1671 UMTS/HSPA/ HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20,
21, 25, 26, 27, 28, 29, 30, 38, 39, 40, 41)
A1821
(China)
UMTS/HSPA/ HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20,
21, 25, 26, 27, 28, 29, 30, 38, 39, 40, 41)
iPad Pro
10.5-inch
A1701
802.11
/a/b/g/n/ac
Wi-Fi only
4.2
N/A
Touch
ID
3
A1709 UMTS/HSPA/ HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A and Rev. B (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20,
21, 25, 26, 27, 28, 29, 30, 38, 39, 40, 41)
A1852
(China)
UMTS/HSPA/ HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz);
GSM/EDGE (850, 900, 1800, 1900 MHz)
CDMA EV-DO Rev. A (800, 1900 MHz)
LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20,
21, 25, 26, 27, 28, 29, 30, 38, 39, 40, 41)
VID: 10937
Page 22 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A11 Bionic iPhone 8 A1863
802.11
/a/b/g/n/a
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5.0
2.4
GHz
Touch
ID
3
4357
A1906
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
A1907 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1905
(GSM)
Models A1905 and A1897 do not support CDMA networks, such as
those used by Verizon and Sprint.
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 8 Plus A1864
802.11
/a/b/g/n/ac
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
2.4
GHz
Touch
ID
3
A1898
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
VID: 10937
Page 23 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A1899 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1897
(GSM)
Models A1905 and A1897 do not support CDMA networks, such as
those used by Verizon and Sprint.
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone X A1865
(Japan)
802.11
/a/b/g/n/ac
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
2.4
GHz
Face
ID
A11
Bionic
A1902
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1903
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
VID: 10937
Page 24 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A1901 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28,
29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz))
VID: 10937
Page 25 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A12 Bionic iPhone XS A1920
(US/CA/
HK)
802.11
/a/b/g/n/ac
FDD‑LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, 71)
TD‑LTE (Bands 34, 38, 39, 40, 41, 46)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5.0
2.4
GHz
Face
ID
A12
Bionic
4377
A2097 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
28, 29, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2098
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21,
25, 26, 28, 29, 30, 32, 66)
TD LTE bands 34, 38, 39, 40, 41, 42, and 46.
A2099
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66 and 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2100
(China)
FDD-LTE (频段 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, 71)
TD-LTE (频段 34, 38, 39, 40, 41, 46)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone XS Max A1921
(US/CA)
Dual SIM (nano-
SIM and eSIM)
FDD‑LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, 71)
TD‑LTE (Bands 34, 38, 39, 40, 41, 46)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
2.4
GHz
A2101
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
28, 29, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
VID: 10937
Page 26 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A2102
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21,
25, 26, 28, 29, 30, and 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, and 46)
A2103
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66 and 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2104
(China/
HK)
FDD-LTE (频段 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, 71)
TD-LTE (频段 34, 38, 39, 40, 41, 46)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone XR A1984
(US/CA)
FDD‑LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, 71)
TD‑LTE (Bands 34, 38, 39, 40, 41)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
2.4
GHz
A2105
(Global)
FDD‑LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
28, 29, 30, 32, 66)
TD‑LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2106
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21,
25, 26, 28, 29, 30, and 66)
TD LTE (Bands 34, 38, 39, 40, 41, and 42)
A2107
(US/CA)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66 and 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2108
(HK/
China)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26,
29, 30, 32, 66, and 71)
TD LTE (Bands 34, 38, 39, 40, and 41)
VID: 10937
Page 27 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model
Number
Wi-Fi Cellular Blue-
tooth
N
F
C
B
A
F
Broad
com
Core
A12X
Bionic
11-inch iPad
Pro
A1934
(US/CA)
802.11
/a/b/g/n/ac
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
LTE Advanced (Model A1934 and A1895: bands 1, 2, 3, 4, 5, 7, 8,
11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29, 30, 34, 38, 39, 40,
41, 42, 46, 66)
5.0
N/A
Face
ID
Gen.A12X
Bionic
4377
A1979
(China)
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
A1980 Wi-Fi only
A2013
(US/CA)
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
Gigabit-class LTE (Models A2013 and A2014: bands 1, 2, 3, 4, 5, 7,
8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 29, 30, 34, 38, 39, 40, 41,
46, 66, 71)
12.9-inch iPad
Pro (3rd
Gen)
A2014
(US/CA)
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
Gigabit-class LTE (Models A2013 and A2014: bands 1, 2, 3, 4, 5, 7,
8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 29, 30, 34, 38, 39, 40, 41,
46, 66, 71)
N/A
A1876 Wi-Fi only
A1895 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
LTE Advanced (Model A1934 and A1895: bands 1, 2, 3, 4, 5, 7, 8,
11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29, 30, 34, 38, 39, 40,
41, 42, 46, 66)
A1983
(China)
UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100
MHz); GSM/EDGE (850, 900, 1800, 1900 MHz)
Table 1: Devices Covered by the Evaluation
VID: 10937
Page 28 of 172 © 2019 Apple Inc. Version: 1.6
1.5 TOE Architecture
The implementation of TOE architecture can be viewed as a set of layers, which are shown in
Figure 1: Layers of iOS, below. Lower layers contain fundamental services and technologies.
Higher-level layers build upon the lower layers and provide more sophisticated services and
technologies.
Figure 1: Layers of iOS
The individual layers provide the following services.
The Cocoa Touch layer contains key frameworks for building iOS apps. These frameworks
define the appearance of applications (apps). They also provide the basic app infrastructure
and support for key technologies such as multitasking, touch-based input, push notifications,
and many high-level system services. When designing apps, one should investigate the
technologies in this layer first to see if they meet the needs of the developer.
The Media layer contains the graphics, audio, and video technologies you use to implement
multimedia experiences in apps.
The Core Services layer contains fundamental system services for apps. Key among these
services are the Core Foundation and Foundation frameworks, which define the basic types
that all apps use. This layer also contains individual technologies to support features such as
location, iCloud, social media, and networking.
This layer also implements data protection functions that allow apps that work with sensitive
user data to take advantage of the built-in encryption available on some devices. When an
app designates a specific file as protected, the system stores that file in an encrypted format.
While the device is locked, the contents of the file are inaccessible to both the app and to any
potential intruders. However, when the device is unlocked by the user, a decryption key is
created to allow the app to access the file. Other levels of data protection are also available.
The Core OS layer contains the low-level features that most other technologies are built
upon. Even if an app does not use these technologies directly, they are most likely being
used by other frameworks. And in situations where an app needs to explicitly deal with
security or communicating with an external hardware accessory, it does so by using the
frameworks in this layer.
Security related frameworks provided by this layer are:
• the Generic Security Services Framework, providing services as specified in Request for
Comment (RFC) 2743 (Generic Security Service Application Program Interface Version 2,
Update 1) and RFC 4401 (Pseudo Random Function);
• the Local Authentication Framework;
VID: 10937
Page 29 of 172 © 2019 Apple Inc. Version: 1.6
• the Network Extension Framework, providing support for configuring and controlling VPN
tunnels;
• the Security Framework, providing services to manage and store certificates, public and
private keys, and trust policies (this framework also provides the Common Crypto library
for symmetric encryption and hash-based message authentication codes); and
• the System Framework, providing the kernel environment, drivers, and low-level UNIX
interfaces (the kernel manages the virtual memory system, threads, file system, network,
and inter-process communication and is therefore responsible for separating apps from
each other and controlling the use of low-level resources).
The TOE is managed by an MDM solution that enables an enterprise to control and
administer the TOE instances that are enrolled in the MDM solution.
1.5.1 Physical Boundaries
The TOE’s physical boundaries are those of the Mobile Devices.
1.5.2 Security Functions provided by the TOE
The TOE provides the security functionality required by
• [PP_MD_V3.1] with
o [EP_MDM_AGENT_V3.0],
o [MOD-VPN_CLI_V2.1], and
o [PP_WLAN_CLI_EP_V1.0].
1.5.2.1 Cryptographic Support
The TOE provides cryptographic services via the following three cryptographic modules.
• Apple CoreCrypto Cryptographic Module for ARM, v9.0 (User Space)
• Apple CoreCrypto Kernel Cryptographic Module for ARM, v9.0 (Kernel Space)
• Apple Secure Key Store Cryptographic Module, v9.0
The Apple CoreCrypto Cryptographic Module for ARM is designed for library use within
the iOS user space. It is implemented as an iOS dynamically loadable library. The
dynamically loadable library is loaded into the iOS application and its cryptographic functions
are made available to the application. A second instance of this module is used within the
secure enclave to provide cryptographic services there.
Figure 2: Block Diagram of the Apple CoreCrypto Cryptographic Module for ARM below,
shows the boundary of the Apple CoreCrypto Cryptographic Module for ARM within the TOE.
VID: 10937
Page 30 of 172 © 2019 Apple Inc. Version: 1.6
Figure 2: Block Diagram of the Apple CoreCrypto Cryptographic Module for ARM
The cryptographic functions provided include symmetric key generation, encryption and
decryption using the Advanced Encryption Standard (AES) algorithms, asymmetric key
generation and key establishment, cryptographic hashing, and keyed-hash message
authentication.
Note that the Wi-Fi chip, performs the AES functions.
The functions listed below are used to implement the security protocols supported as well as
for the encryption of data-at-rest.
• Random number generation; symmetric key generation
• Symmetric encryption and decryption
• Digital Signature and asymmetric key generation
• Message digest
• Keyed hash
• Key derivation (PBKDF)
• EC Diffie-Hellman
The Apple CoreCrypto Kernel Module for ARM is an iOS kernel extension optimized for
library use within the iOS kernel. Once the module is loaded into the iOS kernel its
cryptographic functions are made available to iOS Kernel services only.
Figure 3: Block Diagram of the Apple CoreCrypto Kernel Module for ARM, following, shows
the boundary of the Apple CoreCrypto Kernel Module for ARM within the TOE.
VID: 10937
Page 31 of 172 © 2019 Apple Inc. Version: 1.6
Figure 3: Block Diagram of the Apple CoreCrypto Kernel Module for ARM
The functions listed below are used to implement the security protocols supported as well as
for the encryption of data-at-rest.
• Random number generation
• Data encryption / decryption
• Signature generation/verification
• Message digest
• Message authentication
• Key derivation
• Key generation
The Apple Secure Key Store Cryptographic Module, v9.0 is a single-chip standalone
hardware cryptographic module running on a multi-chip device and provides services
intended to protect data in transit and at rest.
The cryptographic services provided by the module are as follows.
• Random number generation
• Data encryption / decryption
• Message digest
• Key wrapping
• Key derivation
• Key generation
VID: 10937
Page 32 of 172 © 2019 Apple Inc. Version: 1.6
Figure 4 shows the boundary of the Apple Secure Key Store Cryptographic Module, v9.0 within the
TOE.
Figure 4: Block Diagram of the Apple Secure Key Store Cryptographic Module
1.5.2.2 User Data Protection
User data in files is protected using cryptographic functions, ensuring this data remains
protected even if the device gets lost or is stolen. Critical data (like passcodes used by
applications or application defined cryptographic keys) can be stored in the key chain, which
provides additional protection. Passcode protection and encryption ensure that data-at-rest
remains protected even in the case of the device being lost or stolen.
The Secure Enclave Processor (SEP), a separate CPU that executes a stand-alone operating
system and has separate memory, provides protection for critical security data such as keys.
Data can also be protected such that only the application that owns the data can access it.
1.5.2.3 Identification and Authentication
Except for making emergency calls, answering calls, using the cameras, and using the
flashlight, users need to authenticate using a passcode or a biometric (fingerprint or face). On
power up, or after an update of iOS the user is required to use the passcode authentication
mechanism.
The passcode can be configured for a minimum length, for dedicated passcode policies, and
for a maximum life time. When entered, passcodes are obscured and the frequency of
entering passcodes is limited as well as the number of consecutive failed attempts of entering
the passcode.
The TOE also enters a locked state after a (configurable) time of user inactivity and the user
is required to either enter his passcode or use biometric authentication (fingerprint or face) to
unlock the TOE.
VID: 10937
Page 33 of 172 © 2019 Apple Inc. Version: 1.6
External entities connecting to the TOE via a secure protocol (Extensible Authentication
Protocol Transport Layer Security (EAP-TLS), Transport Layer Security (TLS), IPsec) can be
authenticated using X.509 certificates.
1.5.2.4 Security Management
The security functions listed in Table 4: Management Functions, can be managed either by
the user or by an authorized administrator through an MDM system. This table identifies the
functions that can be managed and indicates if the management can be performed by the
user, by the authorized administrator, or both.
1.5.2.5 Protection of the TSF
Some of the functions the TOE implements to protect the TSF and TSF data are as follows.
• Protection of cryptographic keys—keys used for TOE internal key wrapping and for the
protection of data-at-rest are not exportable. There are provisions for fast and secure
wiping of key material.
• Use of memory protection and processor states to separate applications and protect the
TSF from unauthorized access to TSF resources—in addition, each device includes a
separate system called the "secure enclave" which is the only system that can use the
Root Encryption Key (REK). The secure enclave is a separate CPU that executes a
stand-alone operating system and has separate memory.
• Digital signature protection of the TSF image—all updates to the TSF need to be digitally
signed.
• Software/firmware integrity self-test upon start-up—the TOE will not go operational when
this test fails.
• Digital signature verification for applications
• Access to defined TSF data and TSF services only when the TOE is unlocked
1.5.2.6 TOE Access
The TSF provides functions to lock the TOE upon request and after an administrator-
configurable time of inactivity.
Access to the TOE via a wireless network is controlled by user/administrator defined policy.
1.5.2.7 Trusted Path/Channels
The TOE supports the use of the following cryptographic protocols that define a trusted
channel between itself and another trusted IT product.
• IEEE 802.11-2012
• IEEE 802.1X
• EAP-TLS (1.0,1.1,1.2)
• TLS (1.2)
• IPsec
• Bluetooth (4.0, 4.2, 5.0)
1.5.2.8 Audit
The TOE provides the ability for responses to be sent from the MDM Device Agent to the
MDM Server. These responses are configurable by the organization using a scripting
language given in the Over-the-Air Profile Delivery and Configuration document.
VID: 10937
Page 34 of 172 © 2019 Apple Inc. Version: 1.6
1.5.3 TOE Documentation
Reference Document Name Location
Device Administrator Guidance
[CC_GUIDE] Apple iPad and iPhone Mobile
Devices with iOS 12
Common Criteria Configuration
Guide
https://www.niap-
ccevs.org/st/st_vid10937-agd.pdf
[IOS_CFG]
(2018-09-17)
Configuration Profile Reference https://developer.apple.com/enter
prise/documentation/Configuratio
n-Profile-Reference.pdf
Device User Guidance
[iPhone_UG] iPhone User Guide for iOS 12
(2018)
https://help.apple.com/iphone/12/
[iPad_UG] iPad User Guide for iOS 12
(2018)
https://help.apple.com/ipad/12/
[PASSCODE-Help]
(June 8, 2018)
Use a passcode with your
iPhone, iPad or iPod touch
https://support.apple.com/en-
us/HT204060
Mobile Device Management
[AConfig] Apple Configurator Help (online
guidance)
https://help.apple.com/configurato
r/mac/
[DEP_Guide]
(12-2017)
Apple Deployment Programs
Device Enrollment Program
Guide
https://www.apple.com/business/
docs/DEP_Guide.pdf
[PM_Help]
(2018)
Profile Manager Help https://help.apple.com/profileman
ager/mac/
[IOS_MDM]
(2018-09-17)
Mobile Device Management
Protocol Reference
https://developer.apple.com/enter
prise/documentation/MDM-
Protocol-Reference.pdf
Supporting Documents
[LOGGING] Logging https://developer.apple.com/docu
mentation/os/logging?language=o
bjc
[iOSDeployRef] iOS Deployment Reference https://help.apple.com/deploymen
t/ios/
[IOS_LOGS] Profiles and Logs https://developer.apple.com/bug-
reporting/profiles-and-
logs/?platforms=ios
[MDM_SETTINGS_IT] Mobile device management
settings for IT
https://help.apple.com/deploymen
t/mdm/
VID: 10937
Page 35 of 172 © 2019 Apple Inc. Version: 1.6
Reference Document Name Location
[TRUST_STORE] List of available trusted root
certificates in iOS 12,
macOS10.14, watchOS 5, and
tvOS 12
https://support.apple.com/en-
us/HT209144
[MANAGE_CARDS] Manage the cards that you use
with Apple Pay
https://support.apple.com/en-
us/HT205583
[PAY_SETUP] Set up Apple Pay https://support.apple.com/en-
us/HT204506
App Developer Guidance
[CKTSREF]
(2018)
Certificate, Key, and Trust
Services
https://developer.apple.com/docu
mentation/security/certificate_key
_and_trust_services
[KEYCHAINPG]
(2018)
Keychain Services Programming
Guide
https://developer.apple.com/docu
mentation/security/keychain_servi
ces
[IOS_SEC] iOS Security https://www.apple.com/business/
site/docs/iOS_Security_Guide.pdf
1.5.4 Other References
[BT] Specification of the Bluetooth System
https://www.bluetooth.com/specifications/adopted-specifications
[PP_MD_V3.1] U.S. Government Approved Protection Profile - Protection Profile for Mobile
Device Fundamentals, Version 3.1
https://www.niap-ccevs.org/Profile/Info.cfm?id=417
[EP_MDM_AGENT_V3.0] U.S. Government Approved Protection Profile - Extended Package
for Mobile Device Management Agents Version 3.0
https://www.niap-ccevs.org/Profile/Info.cfm?id=403
[PP_WLAN_CLI_EP_V1.0] Extended Package for WLAN Client Version 1.0
https://www.niap-ccevs.org/Profile/Info.cfm?id=386
[MOD_VPN_CLI_EP_V2.1] PP-Module for VPN Client Version 2.1
https://niap-ccevs.org/Profile/Info.cfm?PPID=419&id=419
VID: 10937
Page 36 of 172 © 2019 Apple Inc. Version: 1.6
2 Conformance Claims
2.1 CC Conformance
This [ST] is conformant to the following CC documents.
• Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1,
Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1,
Revision 5, April 2017: Part 2 extended
• Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1,
Revision 5, April 2017: Part 3 extended
2.2 Protection Profile (PP) Conformance
This [ST] is conformant to the following PPs.
• Protection Profile for Mobile Device Fundamentals, Version 3.1, dated 16 June, 2017
[PP_MD_V3.1] with the following extended package and PP-Modules
o Extended Package for Mobile Device Management Agents Version 3.0, dated 21
November, 2016 [EP_MDM_AGENT_V3.0]
o General Purpose Operating Systems Protection Profile/ Mobile Device
Fundamentals Protection Profile Extended Package (EP) Wireless Local Area
Network (WLAN) Clients, dated 8 February, 2016 [PP_WLAN_CLI_EP_V1.0]
o The PP-Module for Virtual Private Network (VPN) Clients, Version 2.1, dated 5
October, 2017 [MOD_VPN_CLI_V2.1]
Note: This ST matches the use case 4 templates described in [PP_MD_V3.1] and
[EP_MDM_AGENT_V3.0] and use case 1 found in MOD_VPN_CLI_V2.1]
2.2.1 Technical Decisions
The following technical decisions were listed as applicable within the PP-Group. Those that
are not applicable to this evaluation are shown grayed out and also noted in the footnotes.
[PP_MD_V3.1]
[TD0371] Section F.2 [Use Case 2]1
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=381
[TD0369] Long-term trusted channel key material
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=379
[TD0366] Flexibility in Password Conditioning in FCS_COP.1(5)
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=376
[TD0351] Additional methods for DEK formation
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=361
[TD0347] Update of Use Case 2 in MDF PP
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=357
[TD0346] Revision of FMT_SMF_EXT.2 in MDF PP
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=356
[TD0305] Handling of TLS connections with and without mutual authentication
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=311
[TD0304] Update to FCS_TLSC_EXT.1.2
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=310
[TD0301] Updates to Administrator Management and Biometric Authentication
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=307
1 TD0371 is not applicable in this ST
VID: 10937
Page 37 of 172 © 2019 Apple Inc. Version: 1.6
[TD0244] FCS_TLSC_EXT – TLS Client Curves Allowed
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=250
[EP_MDM_AGENT_V3.0]
[TD0237] FAU_GEN.1.1(2) - FMT_UNR_EXT.1 Audit Record Selection-Based
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=243
[PP_WLAN_CLI_EP_V1.0]
[TD0244] FCS_TLSC_EXT – TLS Client Curves Allowed
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=250
[TD0194] Update to audit of FTP_ITC_EXT.1/WLAN
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=198
[MOD_VPN_CLI_V2.1]
[TD0385] FTP_DIT_EXT.1 Assurance Activity Clarification2
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=395
[TD0373] RSA-based key establishment3
https://niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=383
[TD0379] Updated FCS_IPSEC_EXT.1.11 Tests for VPN Client
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=389
[TD0378] TOE/TOE Platform selection in FCS_IPSEC_EXT.1 SFRs
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=388
[TD0362] “Failure of the randomization process” audit4
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=372
[TD0355] FCS_CKM.1/VPN for IKE authentication5
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=365
[TD0330] Curve25519 scheme moved to optional and FFC scheme using DH Group
14 added
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=336
[TD0303] IKEv1 and support for XAUTH6
https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=309
2.3 Conformance Rationale
This [ST] provides exact compliance with the PP-Group. The security problem definition,
security objectives and security requirements in this [ST] are all taken from the PP-Group
performing only operations defined there.
The requirements in the PP, EPs and PP-Module are assumed to represent a complete set of
requirements that serve to address any interdependencies. Given that all of the appropriate
functional requirements given in the PP-Group have been copied into this [ST], the
dependency analysis for the requirements is assumed to be already performed by the PP-
Group authors and is not reproduced in this document.
2 TD0385 is not applicable in this ST
3 TD0373 is not applicable in this ST
4 TD0362 is not applicable in this ST
5 TD0355 is not applicable in this ST
6 TD0303 is not applicable to this ST
VID: 10937
Page 38 of 172 © 2019 Apple Inc. Version: 1.6
3 Security Problem Definition
The security problem definition has been taken from the PP-Group. It is reproduced here for
the convenience of the reader.
3.1 Threats
T.EAVESDROP Network Eavesdropping (PP_MD_V3.1)
An attacker is positioned on a wireless communications channel or elsewhere on the network
infrastructure. Attackers may monitor and gain access to data exchanged between the Mobile
Device and other endpoints.
T.NETWORK_EAVESDROP Network Eavesdropping (EP_MDM_AGENT_V3.0)
Unauthorized entities may intercept communications between the MDM and mobile devices
to monitor, gain access to, disclose, or alter remote management commands. Unauthorized
entities may intercept unprotected wireless communications between the mobile device and
the Enterprise to monitor, gain access to, disclose, or alter TOE data.
T.NETWORK Network Attack (PP_MD_V3.1)
An attacker is positioned on a wireless communications channel or elsewhere on the network
infrastructure. Attackers may initiate communications with the Mobile Device or alter
communications between the Mobile Device and other endpoints in order to compromise the
Mobile Device. These attacks include malicious software update of any applications or
system software on the device. These attacks also include malicious web pages or email
attachments which are usually delivered to devices over the network.
T.NETWORK_ATTACK Network Attack (EP_MDM_AGENT_V3.0)
An attacker may masquerade as MDM Server and attempt to compromise the integrity of the
mobile device by sending malicious management commands.
T.PHYSICAL Physical Access (PP_MD_V3.1)
An attacker, with physical access, may attempt to access user data on the Mobile Device
including credentials. These physical access threats may involve attacks, which attempt to
access the device through external hardware ports, impersonate the user authentication
mechanisms, through its user interface, and also through direct and possibly destructive
access to its storage media.
Note: Defending against device re-use after physical compromise is out of scope for this
protection profile.
T.PHYSICAL_ACCESS Physical Access (EP_MDM_AGENT_V3.0)
The mobile device may be lost or stolen, and an unauthorized individual may attempt to
access user data. Although these attacks are primarily directed against the mobile device
platform, the MDM Agent configures features, which address this threat.
T.FLAWAPP Malicious or Flawed Application (PP_MD_V3.1)
Applications loaded onto the Mobile Device may include malicious or exploitable code. This
code could be included intentionally by its developer or unknowingly by the developer,
perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which
they have access. They may also conduct attacks against the platform’s system software
which will provide them with additional privileges and the ability to conduct further malicious
activities. Malicious applications may be able to control the device's sensors (GPS, cameras,
and microphones) to gather intelligence about the user's surroundings even when those
activities do not involve data resident or transmitted from the device. Flawed applications may
give an attacker access to perform network-based or physical attacks that otherwise would
have been prevented.
T.MALICIOUS_APPS Malicious and Flawed Application (EP_MDM_AGENT_V3.0)
VID: 10937
Page 39 of 172 © 2019 Apple Inc. Version: 1.6
Malicious or flawed application threats exist because apps loaded onto a mobile device may
include malicious or exploitable code. An administrator of the MDM or mobile device user
may inadvertently import malicious code, or an attacker may insert malicious code into the
TOE, resulting in the compromise of TOE or TOE data.
T.PERSISTENT Persistent Presence (PP_MD_V3.1)
Persistent presence on a device by an attacker implies that the device has lost integrity and
cannot regain it. The device has likely lost this integrity due to some other threat vector, yet
the continued access by an attacker constitutes an on-going threat in itself. In this case the
device and its data may be controlled by an adversary at least as well as by its legitimate
owner.
T.BACKUP (EP_MDM_AGENT_V3.0)
An attacker may try to target backups of data or credentials and exfiltrate data. Since the
backup is stored on either a personal computer or end user’s backup repository, it’s not likely
enterprise would detect compromise.
T.TSF_CONFIGURATION (MOD_VPN_CLI_V2.1)
Configuring VPN tunnels is a complex and time-consuming process, and prone to errors if the
interface for doing so is not well-specified or well-behaved. The inability to configure certain
aspects of the interface may also lead to the mis-specification of the desired communications
policy or use of cryptography that may be desired or required for a particular site. This may
result in unintended weak or plaintext communications while the user thinks that their data are
being protected. Other aspects of configuring the TOE or using its security mechanisms (for
example, the update process) may also result in a reduction in the trustworthiness of the VPN
client.
T.TSF_FAILURE (PP_WLAN_CLI_EP_V1.0)
Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g.,
memory management, privileged modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a compromise in more
complex mechanisms, resulting in a compromise of the TSF.
T.UNAUTHORIZED ACCESS (PP_WLAN_CLI_EP_V1.0)
A user may gain unauthorized access to the TOE data and TOE executable code. A
malicious user, process, or external IT entity may masquerade as an authorized entity in
order to gain unauthorized access to data or TOE resources. A malicious user, process, or
external IT entity may misrepresent itself as the TOE to obtain identification and
authentication data.
T.UNAUTHORIZED ACCESS (MOD_VPN_CLI_V2.1)
This PP-Module does not include requirements that can protect against an insider threat.
Authorized users are not considered hostile or malicious and are trusted to follow appropriate
guidance. Only authorized personnel should have access to the system or device that
contains the IPsec VPN client. Therefore, the primary threat agents are the unauthorized
entities that try to gain access to the protected network (in cases where tunnel mode is used)
or to plaintext data that traverses the public network (regardless of whether transport mode or
tunnel mode is used).
The endpoint of the network communication can be both geographically and logically distant
from the TOE, and can pass through a variety of other systems. These intermediate systems
may be under the control of the adversary, and offer an opportunity for communications over
the network to be compromised.
Plaintext communication over the network may allow critical data (such as passwords,
configuration settings, and user data) to be read and/or manipulated directly by intermediate
systems, leading to a compromise of the TOE or to the secured environmental system(s) that
the TOE is being used to facilitate communications with. IPsec can be used to provide
protection for this communication; however, there are myriad options that can be
VID: 10937
Page 40 of 172 © 2019 Apple Inc. Version: 1.6
implemented for the protocol to be compliant to the protocol specification listed in the RFC.
Some of these options can have negative impacts on the security of the connection. For
instance, using a weak encryption algorithm (even one that is allowed by the RFC, such as
DES) can allow an adversary to read and even manipulate the data on the encrypted
channel, thus circumventing countermeasures in place to prevent such attacks. Further, if the
protocol is implemented with little-used or non-standard options, it may be compliant with the
protocol specification but will not be able to interact with other, diverse equipment that is
typically found in large enterprises.
Even though the communication path is protected, there is a possibility that the IPsec peer
could be duped into thinking that a malicious third-party user or system is the TOE. For
instance, a middleman could intercept a connection request to the TOE, and respond to the
request as if it were the TOE. In a similar manner, the TOE could also be duped into thinking
that it is establishing communications with a legitimate IPsec peer when in fact it is not. An
attacker could also mount a malicious man-in-the-middle-type of attack, in which an
intermediate system is compromised, and the traffic is proxied, examined, and modified by
this system. This attack can even be mounted via encrypted communication channels if
appropriate countermeasures are not applied. These attacks are, in part, enabled by a
malicious attacker capturing network traffic (for instance, an authentication session) and
“playing back” that traffic in order to fool an endpoint into thinking it was communicating with a
legitimate remote entity.
T.UNAUTHORIZED_UPDATE (MOD_VPN_CLI_V2.1)
Since the most common attack vector used involves attacking unpatched versions of software
containing well-known flaws, updating the VPN client is necessary to ensure that changes to
threat environment are addressed. Timely application of patches ensures that the client is a
“hard target”, thus increasing the likelihood that product will be able to maintain and enforce
its security policy. However, the updates to be applied to the product must be trustable in
some manner; otherwise, an attacker can write their own “update” that instead contains
malicious code of their choosing, such as a rootkit, bot, or other malware. Once this “update”
is installed, the attacker then has control of the system and all of its data.
Methods of countering this threat typically involve hashes of the updates, and potentially
cryptographic operations (e.g., digital signatures) on those hashes as well. However, the
validity of these methods introduces additional threats. For instance, a weak hash function
could result in the attacker being able to modify the legitimate update in such a way that the
hash remained unchanged. For cryptographic signature schemes, there are dependencies on
1) the strength of the cryptographic algorithm used to provide the signature, and
2) the ability of the end user to verify the signature (which typically involves checking a
hierarchy of digital signatures back to a root of trust (a certificate authority)).
If a cryptographic signature scheme is weak, then it may be compromised by an attacker and
the end user will install a malicious update, thinking that it is legitimate. Similarly, if the root of
trust can be compromised, then a strong digital signature algorithm will not stop the malicious
update from being installed (the attacker will just create their own signature on the update
using the compromised root of trust, and the malicious update will then be installed without
detection).
T.UNDETECTED ACTIONS (PP_WLAN_CLI_EP_V1.0)
Malicious remote users or external IT entities may take actions that adversely affect the
security of the TOE. These actions may remain undetected and thus their effects cannot be
effectively mitigated.
T.USER_DATA_REUSE (MOD_VPN_CLI_V2.1)
Data traversing the TOE could inadvertently be sent to a different user; since these data may
be sensitive, this may cause a compromise that is unacceptable. The specific threat that must
be addressed concerns user data that is retained by the TOE in the course of processing
network traffic that could be inadvertently re-used in sending network traffic to a user other
than that intended by the sender of the original network traffic.
VID: 10937
Page 41 of 172 © 2019 Apple Inc. Version: 1.6
T.TSF_FAILURE (MOD_VPN_CLI_V2.1)
Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g.,
memory management, privileged modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a compromise in more
complex mechanisms, resulting in a compromise of the TSF.
3.2 Assumptions
A.CONFIG (PP_MD_V3.1)
It is assumed that the TOE’s security functions are configured correctly in a manner to ensure
that the TOE security policies will be enforced on all applicable network traffic flowing among
the attached networks.
A.TRUSTED_CONFIG (MOD_VPN_CLI_V2.1)
Personnel configuring the TOE and its operational environment will follow the applicable
security configuration guidance.
A.NOTIFY (PP_MD_V3.1)
It is assumed that the mobile user will immediately notify the administrator if the Mobile
Device is lost or stolen.
A.PRECAUTION (PP_MD_V3.1)
It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of
the Mobile Device.
A.CONNNECTIVITY (EP_MDM_AGENT_V3.0)
The TOE relies on network connectivity to carry out its management activities. The TOE will
robustly handle instances when connectivity is unavailable or unreliable.
A.MOBILE_DEVICE_PLATFORM (EP_MDM_AGENT_V3.0)
The MDM Agent relies upon Mobile platforms and hardware evaluated against the MDFPP
and assured 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.
A.PROPER_ADMIN (EP_MDM_AGENT_V3.0)
One or more competent, trusted personnel who are not careless, willfully negligent, or hostile,
are assigned and authorized as the TOE Administrators, and do so using and abiding by
guidance documentation.
A.TRUSTED_ADMIN (PP_WLAN_CLI_EP_V1.0)
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted
manner.
A.PROPER_USER (EP_MDM_AGENT_V3.0)
Mobile device users are not willfully negligent or hostile and use the device within compliance
of a reasonable Enterprise security policy.
A.NO_TOE_BYPASS (PP_WLAN_CLI_EP_V1.0)
Information cannot flow between the wireless client and the internal wired network without
passing through the TOE.
A.NO_TOE_BYPASS (MOD_VPN_CLI_V2.1)
Information cannot flow onto the network to which the VPN client's host is connected without
passing through the TOE.
A.PHYSICAL (MOD_VPN_CLI_V2.1)
VID: 10937
Page 42 of 172 © 2019 Apple Inc. Version: 1.6
Physical security, commensurate with the value of the TOE and the data it contains, is
assumed to be provided by the environment.
3.3 Organizational Security Policies
An organizational security policy (OSP) is a set of rules, practices, and procedures imposed
by an organization to address its security needs. The following OSPs must be enforced by the
TOE or its operational environment.
P.ADMIN (EP_MDM_AGENT_V3.0)
The configuration of the mobile device security functions must adhere to the Enterprise
security policy.
P.DEVICE_ENROLL (EP_MDM_AGENT_V3.0)
A mobile device must be enrolled for a specific user by the administrator of the MDM prior to
being used in the Enterprise network by the user.
P.NOTIFY (EP_MDM_AGENT_V3.0)
The mobile user must immediately notify the administrator if a mobile device is lost or stolen
so that the administrator may apply remediation actions via the MDM system.
P.ACCOUNTABILITY (EP_MDM_AGENT_V3.0)
Personnel operating the TOE shall be accountable for their actions within the TOE.
VID: 10937
Page 43 of 172 © 2019 Apple Inc. Version: 1.6
4 Security Objectives
The security objectives have been taken from the PP Group. They are reproduced here for
the convenience of the reader.
4.1 Security Objectives for the TOE
O.COMMS Protected Communications (PP_MD_V3.1)
To address the network eavesdropping and network attack threats described in section 3.1,
concerning wireless transmission of Enterprise and user data and configuration data between
the TOE and remote network entities, conformant TOEs will use a trusted communication
path. The TOE will be capable of communicating using one (or more) of these standard
protocols: IPsec, TLS, HTTPS, or Bluetooth. The protocols are specified by RFCs that offer a
variety of implementation choices. Requirements have been imposed on some of these
choices (particularly those for cryptographic primitives) to provide interoperability and
resistance to cryptographic attack.
While conformant TOEs must support all of the choices specified in the ST, they may support
additional algorithms and protocols. If such additional mechanisms are not evaluated,
guidance must be given to the administrator to make clear the fact that they were not
evaluated.
O.STORAGE Protected Storage (PP_MD_V3.1)
To address the issue of loss of confidentiality of user data in the event of loss of a Mobile
Device (T.PHYSICAL), conformant TOEs will use data-at-rest protection. The TOE will be
capable of encrypting data and keys stored on the device and will prevent unauthorized
access to encrypted data.
O.CONFIG Mobile Device Configuration (PP_MD_V3.1)
To ensure a Mobile Device protects user and enterprise data that it may store or process,
conformant TOEs will provide the capability to configure and apply security policies defined
by the user and the Enterprise Administrator. If Enterprise security policies are configured
these must be applied in precedence of user specified security policies.
O.AUTH Authorization and Authentication (PP_MD_V3.1)
To address the issue of loss of confidentiality of user data in the event of loss of a Mobile
Device (T.PHYSICAL), users are required to enter an authentication factor to the device prior
to accessing protected functionality and data. Some non-sensitive functionality (e.g.,
emergency calling, text notification) can be accessed prior to entering the authentication
factor. The device will automatically lock following a configured period of inactivity in an
attempt to ensure authorization will be required in the event of the device being lost or stolen.
Authentication of the endpoints of a trusted communication path is required for network
access to ensure attacks are unable to establish unauthorized network connections to
undermine the integrity of the device.
Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a
delay between unsuccessful attempts.
O.INTEGRITY Mobile Device Integrity (PP_MD_V3.1)
To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-
tests to ensure the integrity of critical functionality, software/firmware and data has been
maintained. The user shall be notified of any failure of these self-tests. (This will protect
against the threat T.PERSISTENT.)
To address the issue of an application containing malicious or flawed code (T.FLAWAPP), the
integrity of downloaded updates to software/firmware will be verified prior to
installation/execution of the object on the Mobile Device. In addition, the TOE will restrict
applications to only have access to the system services and data they are permitted to
VID: 10937
Page 44 of 172 © 2019 Apple Inc. Version: 1.6
interact with. The TOE will further protect against malicious applications from gaining access
to data they are not authorized to access by randomizing the memory layout.
O.PRIVACY End User Privacy and Device Functionality (PP_MD_V3.1)
In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for
both personal activities and enterprise data. Enterprise management solutions may have the
technical capability to monitor and enforce security policies on the device. However, the
privacy of the personal activities and data must be ensured. In addition, since there are
limited controls that the enterprise can enforce on the personal side, separation of personal
and enterprise data is needed. This will protect against the T.FLAWAPP and T.PERSISTENT
threats.
O. APPLY_POLICY (EP_MDM_AGENT_V3.0)
The TOE must facilitate configuration and enforcement of enterprise security policies on
mobile devices via interaction with the mobile OS and the MDM Server. This will include the
initial enrollment of the device into management, through its lifecycle including policy updates
and through its possible unenrollment from management services.
O.ACCOUNTABILITY (EP_MDM_AGENT_V3.0)
The TOE must provide logging facilities which record management actions undertaken by its
administrators.
O. DATA_PROTECTION_TRANSIT (EP_MDM_AGENT_V3.0)
Data exchanged between the MDM Server and the MDM Agent must be protected from being
monitored, accessed, or altered.
O.AUTH_COMM (PP_WLAN_CLI_EP_V1.0)
The TOE will provide a means to ensure that it is communicating with an authorized Access
Point and not some other entity pretending to be an authorized Access Point and will provide
assurance to the Access Point of its identity.
O.CRYPTOGRAPHIC_FUNCTIONS (PP_WLAN_CLI_EP_V1.0)
The TOE shall provide or use cryptographic functions (i.e., encryption/decryption and digital
signature operations) to maintain the confidentiality and allow for detection of modification of
data that are transmitted outside the TOE and its host environment.
O.SYSTEM_MONITORING (PP_WLAN_CLI_EP_V1.0)
The TOE will provide the capability to generate audit data.
O.TOE_ADMINISTRATION (PP_WLAN_CLI_EP_V1.0)
The TOE will provide mechanisms to allow administrators to be able to configure the TOE.
O.TSF_SELF_TEST (PP_WLAN_CLI_EP_V1.0)
The TOE will provide the capability to test some subset of its security functionality to ensure it
is operating properly.
O.WIRELESS_ACCESS_POINT_CONNECTION (PP_WLAN_CLI_EP_V1.0)
The TOE will provide the capability to restrict the wireless access points to which it will
connect.
4.2 Security Objectives for the TOE Environment
OE.CONFIG (PP_MD_V3.1)
TOE administrators will configure the Mobile Device security functions correctly to create the
intended security policy.
OE.TRUSTED_CONFIG (MOD_VPN_CLI_V2.1)
VID: 10937
Page 45 of 172 © 2019 Apple Inc. Version: 1.6
Personnel configuring the TOE and its operational environment will follow the applicable
security configuration guidance.
OE.NOTIFY (PP_MD_V3.1)
The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen.
OE.PRECAUTION (PP_MD_V3.1)
The Mobile User exercises precautions to reduce the risk of loss or theft of the Mobile Device.
OE.IT_ENTERPRISE (EP_MDM_AGENT_V3.0)
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 (EP_MDM_AGENT_V3.0)
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.DATA_PROPER_ADMIN (EP_MDM_AGENT_V3.0)
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted
manner.
OE.TRUSTED_ADMIN (PP_WLAN_CLI_EP_V1.0)
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted
manner.
OE.DATA_PROPER_USER (EP_MDM_AGENT_V3.0)
Users of the mobile device are trained to securely use the mobile device and apply all
guidance in a trusted manner.
OE.WIRELESS_NETWORK (EP_MDM_AGENT_V3.0)
A wireless network will be available to the mobile devices.
OE.NO_TOE_BYPASS (PP_WLAN_CLI_EP_V1.0)
Information cannot flow between external and internal networks located in different enclaves
without passing through the TOE.
OE.NO_TOE_BYPASS (MOD_VPN_CLI_V2.1)
Information cannot flow onto the network to which the VPN client's host is connected without
passing through the TOE.
OE.PHYSICAL (MOD_VPN_CLI_V2.1)
Physical security, commensurate with the value of the TOE and the data it contains, is
assumed to be provided by the environment.
VID: 10937
Page 46 of 172 © 2019 Apple Inc. Version: 1.6
5 Extended Components Definition
The Security Target draws upon the extended components implicitly defined in the PP Group.
VID: 10937
Page 47 of 172 © 2019 Apple Inc. Version: 1.6
6 Security Functional Requirements
This chapter describes the Security Functional Requirements (SFRs) for the TOE. The SFRs
have been taken from the PP-Group with appropriate selections, assignments and
refinements being applied.
For each SFR, the source is indicated in brackets, thus:
{MDF} – The component can be found in [PP_MD_V3.1],
{AGENT} – The component can be found in [PP_MD_AGENT_V3.0]
{WLAN} – The component can be found in [PP_WLAN_CLI_EP_V1.0]
{VPN} – The component can be found in [MOD_VPN_CLI_V2.1]
Selections and assignment operations performed as required by the PP and EPs are marked
in bold.
This Security Target (ST) does not identify selections or assignments already applied in the
PPs, PP-Modules and EPs.
VID: 10937
Page 48 of 172 © 2019 Apple Inc. Version: 1.6
6.1 Security Audit (FAU)
Agent Alerts (FAU_ALT)
FAU_ALT_EXT.2 Extended: Agent Alerts
FAU_ALT_EXT.2.1 {AGENT}
The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the event
of any of the following:
• successful application of policies to a mobile device;
• receiving periodic reachability events;
• no other events
FAU_ALT_EXT.2.2 {AGENT}
The MDM Agent shall queue alerts if the trusted channel is not available.
Audit Data Generation (FAU_GEN)
FAU_GEN.1(1) Audit Data Generation
FAU_GEN.1.1(1) {MDF}
The TSF shall be able to generate an audit record of the following auditable events:
1) Start-up and shutdown of the audit functions;
2) All auditable events for the not selected level of audit;
3) All administrative actions;
4) Start-up and shutdown of the Rich OS;
5) Insertion or removal of removable media;
6) Specifically defined auditable events in Table 1;
7) No other auditable events derived from this profile.
8) No additional auditable events.
Note: For this element, Table 1 refers to Table 1 in [PP_MD_V3.1].
Table 2: Combined mandatory auditable events from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0], below, presents the information given in Table 1 of
[PP_MD_V3.1] combined with Table 2 of [PP_WLAN_CLI_EP_V1.0] as instructed in
[PP_WLAN_CLI_EP_V1.0].
VID: 10937
Page 49 of 172 © 2019 Apple Inc. Version: 1.6
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 None
FAU_GEN.1/WLAN None
FAU_STG.1 None
FAU_STG.4 None
FCS_CKM_EXT.1 None No additional information
FCS_CKM_EXT.2 None
FCS_CKM_EXT.3 None
FCS_CKM_EXT.4 None
FCS_CKM_EXT.4 None
FCS_CKM_EXT.5 None No additional information
FCS_CKM_EXT.6 None
FCS_CKM.1 None No additional information
FCS_CKM.1/WLAN None
FCS_CKM.2(*) None
FCS_CKM.2/WLAN None
FCS_COP.1(*) None
FCS_IV_EXT.1 None
FCS_SRV_EXT.1 None
FCS_STG_EXT.1 Import or destruction of
key
Identity of key. Role and identity of
requestor
No other events
FCS_STG_EXT.2 None
FCS_STG_EXT.3 Failure to verify integrity
of stored key
Identity of key being verified
FCS_TLSC_EXT.1 Failure to establish an
EAP-TLS session
Reason for failure.
Non-TOE endpoint connection
Establishment/terminati
on of an EAP-TLS
session
FDP_DAR_EXT.1 Failure to
encrypt/decrypt data
No additional information
FDP_DAR_EXT.2 Failure to
encrypt/decrypt data
No additional information
FDP_IFC_EXT.1 None No additional information
FDP_STG_EXT.1 Addition or removal of
certificate from Trust
Anchor Database
Subject name of certificate
FIA_PAE_EXT.1 None
FIA_PMG_EXT.1 None
FIA_TRT_EXT.1 None
FIA_UAU_EXT.1 None
FIA_UAU.5 None
FIA_UAU.7 None
FIA_X509_EXT.1 Failure to validate
x.509v3 certificate
Reason for failure of validation
FMT_MOF_EXT.1 None
FMT_SMF_EXT.1/WLAN None
FMT_UNR_EXT.1
(Note: TD0237 is applicable
here)
None No additional information
FPT_AEX_EXT.1 None
FPT_AEX_EXT.2 None
FPT_AEX_EXT.3 None
FPT_JTA_EXT.1 None
FPT_JTA_EXT.1 None
VID: 10937
Page 50 of 172 © 2019 Apple Inc. Version: 1.6
Requirement Auditable Events Additional Audit Record
Contents
FPT_KST_EXT.2 None
FPT_KST_EXT.3 None
FPT_NOT_EXT.1 None No additional information.
FPT_STM.1 None
FPT_TST_EXT.1 Initiation of self-test None
Failure of self-test
FPT_TST_EXT.2(1) Start-up of TOE No additional information
None No additional information
FPT_TST_EXT.1/WLAN Execution of this set of
TSF self-tests.
None
No additional information
FPT_TUD_EXT.1 None
FTA_SSL_EXT.1 None
FTA_TAB.1 None
FTA_WSE_EXT.1/WLAN All attempts to connect
to access points
Identity of access point being
connected to as well as success
and failures (including reason for
failure)
FTP_ITC_EXT.1(3)7 All attempts to establish
a trusted channel
Identification of the non-TOE
endpoint of the channel
Table 2: Combined mandatory auditable events from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0]
FAU_GEN.1.2(1) {MDF}
The TSF shall record within each audit record at least the following information:
1) Date and time of the event;
2) type of event;
3) subject identity;
4) the outcome (success or failure) of the event;
5) additional information in Table 1;
6) no additional information.
Note: For this element, Table 1 refers to Table 1 in [PP_MD_V3.1].
Table 2: Combined mandatory auditable events from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0], above, presents the information given in Table 1 of
[PP_MD_V3.1] combined with Table 2 of [PP_WLAN_CLI_EP_V1.0] as instructed in
[PP_WLAN_CLI_EP_V1.0].
FAU_GEN.1(2) Audit Data Generation
FAU_GEN.1.1(2) {AGENT}
The MDM Agent shall be able to generate an MDM Agent audit record of the following
auditable events:
• startup and shutdown of the MDM Agent,
• change in MDM policy,
• any modification commanded by the MDM Server,
• specifically defined auditable events listed in Table 1,
• no other events.
7 “Detection of modification of channel data” was removed by TD0194
VID: 10937
Page 51 of 172 © 2019 Apple Inc. Version: 1.6
Note: For this element, Table 1 refers to Table 1 in [EP_MDM_AGENT_V3.0].
Table 3: Auditable events from [EP_MDM_AGENT_V3.0] in this ST presents the same
information given in Table 1 of [EP_MDM_AGENT_V3.0].] for the convenience of the reader.
Requirement Auditable Events Additional Audit Record
Contents
FAU_ALT_EXT.2 Type of alert No additional information
FAU_GEN.1 None N/A
FAU_SEL.1 All modifications to the audit
configuration that occur while
the audit collection functions are
operating.
No additional information
FAU_STG_EXT.4
FCS_STG_EXT.1(1)
None N/A
FCS_TLSC_EXT.1 Failure to establish a TLS
session
Reason for failure.
Failure to verify presented
identifier
Presented identifier and
reference identifier
Establishment/termination of a
TLS session
Non-TOE endpoint of
connection
FIA_ENR_EXT.2 Enrollment in management Reference identifier of
MDM Server
FMT_UNR_EXT.18 None No additional information
FMT_POL_EXT.2 Failure of policy validation Reason for failure of
validation
FMT_SMF_EXT.3 Success or failure of function No additional information
FTP_ITC_EXT.1(2)
FTP_ITT_EXT.1
Initiation and termination of
trusted channel
Trusted channel protocol.
Non-TOE endpoint of
connection
Table 3: Auditable events from [EP_MDM_AGENT_V3.0]
FAU_GEN.1.2(2) {AGENT}
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 1;
• no other relevant audit information.
Note: For this element, Table 1 refers to Table 1 in [EP_MDM_AGENT_V3.0].
Table 3: Auditable events from [EP_MDM_AGENT_V3.0], above, presents the same
information given in Table 1 of [EP_MDM_AGENT_V3.0].] for the convenience of the reader.
8 Please see TD0237 which is applicable here.
VID: 10937
Page 52 of 172 © 2019 Apple Inc. Version: 1.6
Security Audit Event Selection (FAU_SEL)
FAU_SEL.1(2) Security Audit Event Selection
FAU_SEL.1.1(2) {AGENT}
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
• none.
Security Audit Event Storage (FAU_STG)
FAU_STG.1 Audit Storage Protection
FAU_STG.1.1 {MDF}
The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
FAU_STG.1.2 {MDF}
The TSF shall be able to prevent unauthorized modifications to the stored audit records in the
audit trail.
FAU_STG.4 Prevention of Audit Data Loss
FAU_STG.4.1 {MDF}
The TSF shall overwrite the oldest stored audit records if the audit trail is full.
VID: 10937
Page 53 of 172 © 2019 Apple Inc. Version: 1.6
6.2 Cryptographic Support (FCS)
Cryptographic Key Management (FCS_CKM)
FCS_CKM.1(1) Cryptographic Key Generation
FCS_CKM.1.1(1) {MDF} {VPN} {AGENT}
The TSF 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 meet FIPS
PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;
• ECC schemes using
o “NIST curves” P-384 and P-256 that meet the following: FIPS PUB 186-4,
“Digital Signature Standard (DSS)”, Appendix B.4,
o Curve25519 schemes that meet the following: [RFC7748]
• 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;
FCS_CKM.1/WLAN Cryptographic Key Generation (Symmetric Keys for
WPA2 Connections)
FCS_CKM.1.1/WLAN {WLAN}
The TSF shall generate symmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm PRF-384 and no other and specified cryptographic
key sizes 128 bits and no other key sizes using a Random Bit Generator as specified in
FCS_RBG_EXT.1 that meet the following: IEE 802.11-2012 and no other standards.
FCS_CKM.1/VPN VPN Cryptographic Key Generation (IKE)
FCS_CKM.1.1/VPN {VPN}9
The VPN Client shall generate asymmetric cryptographic keys used for IKE peer
authentication in accordance with:
• 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 no other curves]
and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength
of 112 bits.
FCS_CKM.2(1) Cryptographic Key Establishment
FCS_CKM.2.1(1) {MDF} {VPN} {AGENT}
The TSF 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”;
9 TD0330 is applicable to this SFR
VID: 10937
Page 54 of 172 © 2019 Apple Inc. Version: 1.6
and:
• Elliptic curve-based key establishment schemes that meets the following:
o 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”.
FCS_CKM.2(2) Cryptographic Key Establishment (While device is locked)
FCS_CKM.2.1(2) {MDF}
The TSF shall perform cryptographic key establishment in accordance with a specified
cryptographic key establishment method:
• Elliptic curve-based key establishment schemes that meets the following:
o RFC 7748, “Elliptic Curves for Security”.
for the purposes of encrypting sensitive data received while the device is locked.
FCS_CKM.2/WLAN WLAN Cryptographic Key Distribution (GTK)
FCS_CKM.2.1/WLAN {WLAN}
The TSF shall decrypt Group Temporal Key in accordance with a specified cryptographic key
distribution method AES Key Wrap in an EAPOL-Key frame that meets the following: RFC
3394 for AES Key Wrap, 802.11-2012 for the packet format and timing considerations and
does not expose the cryptographic keys.
FCS_CKM_EXT.1 Extended: Cryptographic Key Support (REK)
FCS_CKM_EXT.1.1 {MDF}
The TSF shall support mutable hardware REK(s) with a symmetric key of strength 256 bits.
FCS_CKM_EXT.1.2 {MDF}
Each REK shall be hardware-isolated from Rich OS on the TSF in runtime.
FCS_CKM_EXT.1.3 {MDF}
Each REK shall be generated by a RBG in accordance with FCS_RBG_EXT.1.
FCS_CKM_EXT.2 Extended: Cryptographic Key Random Generation
FCS_CKM_EXT.2.1 {MDF}10
All DEKs shall be randomly generated with entropy corresponding to the security strength of
AES key sizes of 256 bits.
FCS_CKM_EXT.3 Extended: Cryptographic Key Generation
FCS_CKM_EXT.3.1 {MDF}
The TSF shall use symmetric KEKs of 128 bit, 256-bit security strength corresponding to at
least the security strength of the keys encrypted by the KEK.
10 TD0351 is applicable to this SFR
VID: 10937
Page 55 of 172 © 2019 Apple Inc. Version: 1.6
FCS_CKM_EXT.3.2 {MDF}11
The TSF shall generate all KEKs using one or more of the following methods:
a) derive the KEK from a Password Authentication Factor using according to
FCS_COP.1.1(5) and
b) generate the KEK using an RBG that meets this profile (as specified in
FCS_RBG_EXT.1).
c) combine the KEK from other KEKs in a way that preserves the effective entropy
of each factor by concatenating the keys and use a KDF (as described in SP
800-56c), encrypting one key with another.
Note: The random number generator on the main device is used.
FCS_CKM_EXT.4 Extended: Key Destruction
FCS_CKM_EXT.4.1 {MDF} {VPN} {WLAN} {AGENT}
The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key
destruction methods:
• by clearing the KEK encrypting the target key,
• 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 block erase that erases the reference to memory that
stores data as well as the data itself.
o For non-volatile flash memory that is wear-leveled, the destruction shall be
executed by a block erase.
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.
FCS_CKM_EXT.4.2 {MDF} {VPN}
The TSF shall destroy all plaintext keying material and critical security parameters when no
longer needed.
FCS_CKM_EXT.5 Extended: TSF Wipe
FCS_CKM_EXT.5.1 {MDF}
The TSF shall wipe all protected data by:
• Cryptographically erasing the encrypted DEKs and/or the KEKs in non-volatile
memory by following the requirements in FCS_CKM_EXT.4.1.
FCS_CKM_EXT.5.2 {MDF}
The TSF shall perform a power cycle on conclusion of the wipe procedure.
FCS_CKM_EXT.6 Extended: Salt Generation
FCS_CKM_EXT.6.1 {MDF}
11 TD0366 is applicable to this SFR
VID: 10937
Page 56 of 172 © 2019 Apple Inc. Version: 1.6
The TSF shall generate all salts using a RBG that meets FCS_RBG_EXT.1.
Note: the salt is generated using the random number generator implemented in the secure
enclave, which like the one implemented in the main device, satisfies the requirements of
FCS_RBG_EXT.1. A proprietary Entropy Assessment Report (EAR) has been provided to
NIAP that gives details of both random number generators.
FCS_CKM_EXT.7 Extended: Cryptographic Key Support (REK)
FCS_CKM_EXT.7.1 {MDF}
A REK shall not be able to be read from or exported from the hardware.
Note: FCS_CKM_EXT.7.1 is included as required by Annex B of the Protection Profile, since
“mutable hardware” is included in FCS_CKM_EXT.1.1 {MDF}.
VID: 10937
Page 57 of 172 © 2019 Apple Inc. Version: 1.6
Cryptographic Operations (FCS_COP)
FCS_COP.1(1) Confidentiality Algorithms
FCS_COP.1.1(1) {MDF} {VPN} {AGENT} {WLAN}
The TSF shall perform encryption/decryption in accordance with a specified cryptographic
algorithm
• AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode,
• AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-
2012), and
• AES-XTS (as defined in NIST SP 800-38E) mode,
• AES Key Wrap (KW) (as defined in NIST SP 800-38F),
• AES-GCM (as defined in NIST SP 800-38D),
• AES-CCM (as defined in NIST SP 800-38C),
and cryptographic key sizes 128-bit key sizes and 256-bit key sizes.
FCS_COP.1(2) Hashing Algorithms
FCS_COP.1.1(2) {MDF} {VPN} {AGENT} {WLAN}
The TSF shall perform cryptographic hashing in accordance with a specified cryptographic
algorithm SHA-1 and SHA-256, SHA-384, SHA-512 and message digest sizes 160 and 256,
384, 512 bits that meet the following: FIPS Pub 180-4.
FCS_COP.1(3) Signature Algorithms
FCS_COP.1.1(3) {MDF} {VPN} {AGENT} {WLAN}
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
and:
• ECDSA schemes using “NIST curves” P-384 and P-256 that meet the following:
FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.
FCS_COP.1(4) Keyed Hash Algorithms
FCS_COP.1.1(4) {MDF} {VPN} {AGENT} {WLAN}
The TSF shall perform keyed-hash message authentication in accordance with a specified
cryptographic algorithm HMAC-SHA-1 and HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-
512 and cryptographic key sizes 400-1120 bits and message digest sizes 160 and 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".
FCS_COP.1(5) Password-Based Key Derivation Functions
FCS_COP.1.1(5) {MDF} {AGENT} {WLAN}12
12 TD0366 is applicable to this SFR.
VID: 10937
Page 58 of 172 © 2019 Apple Inc. Version: 1.6
The TSF shall perform conditioning in accordance with a specified cryptographic algorithm
HMAC-SHA-256 using a salt, and PBKDF2 with a minimum of 50,000 iterations, no other
functions and output cryptographic key sizes 128, 256 that meet the following: NIST SP 800-
132.
Note: The number of iterations is calibrated to take at least 100 to 150 milliseconds and is a
minimum of 50,000. The number of iterations may be greater in some devices.
HTTPS Protocol (FCS_HTTPS)
FCS_HTTPS_EXT.1 Extended: HTTPS Protocol
FCS_HTTPS_EXT.1.1 {MDF} {AGENT}
The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2 {MDF} {AGENT}
The TSF shall implement HTTPS using TLS (FCS_TLSC_EXT.1).
FCS_HTTPS_EXT.1.3 {MDF} {AGENT}
The TSF shall notify the application and not establish the connection if the peer certificate
is deemed invalid.
IPsec Protocol (FCS_IPSEC)
FCS_IPSEC_EXT.1 Extended: IPsec
FCS_IPSEC_EXT.1.1 {VPN}
The TOE shall implement the IPsec architecture as specified in RFC 4301.
FCS_IPSEC_EXT.1.2 {VPN}
The TOE shall implement tunnel mode.
FCS_IPSEC_EXT.1.3 {VPN}
The TOE shall have a nominal, final entry in the SPD that matches anything that is otherwise
unmatched, and discards it.
FCS_IPSEC_EXT.1.4 {VPN}
The TOE shall implement the IPsec protocol ESP as defined by RFC 4303 using the
cryptographic algorithms AES-GCM-128, AES-GCM-256 as specified in RFC 4106, AES-
CBC-128, AES-CBC-256 (both specified by RFC 3602) together with a Secure Hash
Algorithm (SHA)-based HMAC, no other algorithms.
FCS_IPSEC_EXT.1.5 {VPN}
The TOE shall implement the protocol:
• IKEv2 as defined in RFCs 7296 (with mandatory support for NAT traversal as
specified in section 2.23), 4307, and no other RFCs for hash functions.
FCS_IPSEC_EXT.1.6 {VPN}
The TOE shall ensure the encrypted payload in the IKEv2 protocol uses the cryptographic
algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and AES-GCM-128.
VID: 10937
Page 59 of 172 © 2019 Apple Inc. Version: 1.6
FCS_IPSEC_EXT.1.7 {VPN}
The TOE shall ensure that IKEv2 SA lifetimes can be configured by an Administrator
based on length of time. If length of time is used, it must include at least one option that is
24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
FCS_IPSEC_EXT.1.8 {VPN}
The TOE shall ensure that all IKE protocols implement DH groups 14 (2048-bit MODP), 19
(256-bit Random ECP), 20 (384-bit Random ECP), and 5 (1536-bit MODP), 15 (3072-bit
MODP).
FCS_IPSEC_EXT.1.9 {VPN}
The TOE shall generate the secret value x used in the IKE Diffie-Hellman key exchange (“x”
in gx mod p) using the random bit generator specified in FCS_RBG_EXT.1 and having a
length of at least 224,256 or 384 bits.
FCS_IPSEC_EXT.1.10 {VPN}
The TOE shall generate nonces used in IKE exchanges in a manner such that the probability
that a specific nonce value will be repeated during the life a specific IPsec SA is less than 1 in
2^ 112,128, or 192
bits
FCS_IPSEC_EXT.1.11 {VPN}13
The TOE shall ensure that all IKE protocols perform peer authentication using a RSA,
ECDSA that use X.509v3 certificates that conform to RFC 4945 and no other method.
FCS_IPSEC_EXT.1.12 {VPN}14
The TOE shall not establish an SA if the Distinguished Name (DN) and CN matching the
full qualified domain name contained in a certificate does not match the expected value(s)
for the entity attempting to establish a connection.
FCS_IPSEC_EXT.1.13 {VPN}15
The TOE shall not establish an SA if the presented identifier does not match the configured
reference identifier of the peer.
FCS_IPSEC_EXT.1.14 {VPN}
The TOE shall be able to ensure by default that the strength of the symmetric algorithm (in
terms of the number of bits in the key) negotiated to protect the IKEv2 IKE_SA connection is
greater than or equal to the strength of the symmetric algorithm (in terms of the number of
bits in the key) negotiated to protect the IKEv2 CHILD_SA connection.
Initialization Vector Generation (FCS_IV)
FCS_IV_EXT.1 Extended: Initialization Vector Generation
FCS_IV_EXT.1.1 {MDF}
The TSF shall generate IVs in accordance with Table 11: References and IV Requirements
for NIST-approved Cipher Modes.
Note: The referenced Table 11 is found in [PP_MD_V3.1].
13 TD0379 is applicable to this element
14 TD0378 is applicable to this element.
15 TD0378 is applicable to this element.
VID: 10937
Page 60 of 172 © 2019 Apple Inc. Version: 1.6
Random Bit Generation (FCS_RBG)
FCS_RBG_EXT.1(Kernel and User space) Extended: Cryptographic
Operation (Random Bit Generation)
FCS_RBG_EXT.1.1(Kernel and User space) {MDF} {VPN} {WLAN} {AGENT}
The TSF shall perform all deterministic random bit generation services in accordance with
NIST Special Publication 800-90A using CTR_DRBG (AES).
FCS_RBG_EXT.1.2(Kernel and User space) {MDF} {VPN} {WLAN} {AGENT}
The deterministic RBG shall be seeded by an entropy source that accumulates entropy from
a software-based noise source 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.
FCS_RBG_EXT.1.3(Kernel and User space) {MDF} {VPN} {WLAN} {AGENT}
The TSF shall be capable of providing output of the RBG to applications running on the TSF
that request random bits.
FCS_RBG_EXT.1(SEP) Extended: Cryptographic Operation (Random Bit
Generation)
FCS_RBG_EXT.1.1(SEP) {MDF} {VPN} {WLAN} {AGENT}
The TSF shall perform all deterministic random bit generation services in accordance with
NIST Special Publication 800-90A using CTR_DRBG (AES).
FCS_RBG_EXT.1.2(SEP) {MDF} {VPN} {WLAN} {AGENT}
The deterministic RBG shall be seeded by an entropy source that accumulates entropy from
a software-based noise source with a minimum of 128 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.
FCS_RBG_EXT.1.3(SEP) {MDF} {VPN} {WLAN} {AGENT}
The TSF shall be capable of providing output of the RBG to applications running on the TSF
that request random bits.
Cryptographic Algorithm Services (FCS_SRV)
FCS_SRV_EXT.1 Extended: Cryptographic Algorithm Services
FCS_SRV_EXT.1.1 {MDF}
The TSF shall provide a mechanism for applications to request the TSF to perform the
following cryptographic operations:
• All mandatory and selected algorithms with the exception of ECC over curve
25519-based algorithms in FCS_CKM.2(2)
• The following algorithms in FCS_COP.1(1): AES-CBC
• All mandatory and selected algorithms in FCS_COP.1(3)
• All mandatory and selected algorithms in FCS_COP.1(2)
• All mandatory and selected algorithms in FCS_COP.1(4)
• No other cryptographic operations
VID: 10937
Page 61 of 172 © 2019 Apple Inc. Version: 1.6
Cryptographic Key Storage (FCS_STG)
FCS_STG_EXT.1 Extended: Secure Key Storage
FCS_STG_EXT.1.1 {MDF}
The TSF shall provide software-based secure key storage for asymmetric private keys and
symmetric keys, persistent secrets.
FCS_STG_EXT.1.2 {MDF}
The TSF shall be capable of importing keys/secrets into the secure key storage upon request
of the administrator and applications running on the TSF.
FCS_STG_EXT.1.3 {MDF}
The TSF shall be capable of destroying keys/secrets in the secure key storage upon request
of the administrator.
FCS_STG_EXT.1.4 {MDF}
The TSF shall have the capability to allow only the application that imported the key/secret
the use of the key/secret. Exceptions may only be explicitly authorized by a common
application developer.
FCS_STG_EXT.1.5 {MDF}
The TSF shall allow only the application that imported the key/secret to request that the
key/secret be destroyed. Exceptions may only be explicitly authorized by a common
application developer.
FCS_STG_EXT.2 Extended: Encrypted Cryptographic Key Storage16
FCS_STG_EXT.2.1 {MDF} {VPN}
The TSF shall encrypt all DEKs, KEKs, WPA2 (PSKs), IPsec (client certificates) and
Bluetooth keys. and all software-based key storage by KEKs that are
1) Protected by the REK with
a. encryption by a KEK chaining from a REK,
2) Protected by the REK and the password with
b. encryption by a KEK chaining to a REK and the password-derived or
biometric unlocked KEK.
FCS_STG_EXT.2.2 {MDF} {VPN}
DEKs, KEKs, WPA2 (PSKs), IPsec (client certificates) and Bluetooth keys, and all
software-based key storage shall be encrypted using one of the following methods:
• using AES in the Key Wrap (KW) mode.
FCS_STG_EXT.3 Extended: Integrity of Encrypted Key Storage17
FCS_STG_EXT.3.1 {MDF}
The TSF shall protect the integrity of any encrypted DEKs and KEKs, WPA2 (PSKs), IPsec
(client certificates) and Bluetooth keys by an immediate application of the key for
16 TD0369 is applicable to this SFR
17 TD0369 is applicable to this SFR
VID: 10937
Page 62 of 172 © 2019 Apple Inc. Version: 1.6
decrypting the protected data followed by a successful verification of the decrypted data with
a previously known information.
FCS_STG_EXT.3.2 {MDF}
The TSF shall verify the integrity of the MAC of the stored key prior to use of the key.
FCS_STG_EXT.4 Extended: Cryptographic Key Storage
FCS_STG_EXT.4.1 {AGENT}
The MDM Agent shall use the platform provided key storage for all persistent secret and
private keys.
TLS Client Protocol (FCS_TLSC)
FCS_TLSC_EXT.1 Extended: TLS Protocol
FCS_TLSC_EXT.1.1 {MDF} {AGENT}
The TSF shall implement TLS 1.2 (RFC 5246) supporting the following ciphersuites:
• Mandatory 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
• Optional Ciphersuites:
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
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
FCS_TLSC_EXT.1.2 {MDF}18
{AGENT}
The TSF shall verify that the presented identifier matches the reference identifier according to
RFC 6125.
FCS_TLSC_EXT.1.3 {MDF} {AGENT}
The TSF shall not establish a trusted channel if the peer certificate is invalid.
FCS_TLSC_EXT.1.4 {MDF}19
{AGENT}
The TSF shall support mutual authentication using X.509v3 certificates.
FCS_TLSC_EXT.1/WLAN Extended: Extensible Authentication Protocol-
Transport Layer Security (EAP-TLS)
FCS_TLSC_EXT.1.1 {WLAN}
The TSF shall implement TLS 1.0 and TLS 1.1 (RFC4346), TLS 1.2 (RFC 5246) in support of
the EAP-TLS protocol as specified in RFC 5216 supporting the following ciphersuites:
18 TD0304 is applicable to the assurance activities for this SFR
19 TD0305 is applicable to the assurance activities for this SFR
VID: 10937
Page 63 of 172 © 2019 Apple Inc. Version: 1.6
• Mandatory Ciphersuites in accordance with RFC 5246:
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
• Optional Ciphersuites:
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246
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
FCS_TLSC_EXT.1.2 {WLAN}
The TSF shall generate random values used in the EAP-TLS exchange using the RBG
specified in FCS_RBG_EXT.1.
FCS_TLSC_EXT.1.3 {WLAN}
The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1
FCS_TLSC_EXT.1.4 {WLAN}
The TSF shall verify that the server certificate presented includes the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
FCS_TLSC_EXT.1.5 {WLAN}
The TSF shall allow an authorized administrator to configure the list of CAs that are allowed
to sign authentication server certificates that are accepted by the TOE.
FCS_TLSC_EXT.1.6 {WLAN}
The TSF shall allow an authorized administrator to configure the list of algorithm suites that
may be proposed and accepted during the EAP-TLS exchanges.
FCS_TLSC_EXT.2 Extended: TLS Protocol
FCS_TLSC_EXT.2.1 {MDF}20
The TSF shall present the Supported Elliptic Curves Extension in the Client Hello handshake
message with the following NIST curves: secp256r1, secp384r1.
20 TD0244 isapplicable to this element.
VID: 10937
Page 64 of 172 © 2019 Apple Inc. Version: 1.6
6.3 User Data Protection (FDP)
Access Control (FDP_ACF)
FDP_ACF_EXT.1 Extended: Security Access Control
FDP_ACF_EXT.1.1 {MDF}
The TSF shall provide a mechanism to restrict the system services that are accessible to an
application.
FDP_ACF_EXT.1.2 {MDF}
The TSF shall provide an access control policy that prevents application from accessing all
data stored by other application. Exceptions may only be explicitly authorized for such
sharing by a common application developer.
Data-At-Rest Protection (FDP_DAR)
FDP_DAR_EXT.1 Extended: Protected Data Encryption
FDP_DAR_EXT.1.1 {MDF}
Encryption shall cover all protected data.
FDP_DAR_EXT.1.2 {MDF}
Encryption shall be performed using DEKs with AES in the CBC mode with key size 256 bits.
FDP_DAR_EXT.2 Extended: Sensitive Data Encryption
FDP_DAR_EXT.2.1 {MDF}
The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
FDP_DAR_EXT.2.2 {MDF}
The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received
while the product is locked.
FDP_DAR_EXT.2.3 {MDF}
The TSF shall encrypt any stored symmetric key and any stored private key of the
asymmetric key(s) used for the protection of sensitive data according to FCS_STG_EXT.2.1
selection 2.
FDP_DAR_EXT.2.4 {MDF}
The TSF shall decrypt the sensitive data that was received while in the locked state upon
transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that
sensitive data using the symmetric key scheme.
Subset Information Flow Control - VPN (FDP_IFC)
FDP_IFC_EXT.1 Extended: Subset Information Flow Control
FDP_IFC_EXT.1.1 {MDF}
The TSF shall provide an interface which allows a VPN client to protect all IP traffic
using IPsec with the exception of IP traffic required to establish the VPN connection.
VID: 10937
Page 65 of 172 © 2019 Apple Inc. Version: 1.6
FDP_IFC_EXT.1.1 {VPN}
The TSF shall ensure that all IP traffic (other than IP traffic required to establish the VPN
connection) flow through the IPsec VPN client.
Storage of Critical Biometric Parameters (FDP_PBA)
FDP_PBA_EXT.1 Extended: Storage of Critical Biometric Parameters
FDP_PBA_EXT.1.1 {MDF}
The TSF shall protect the authentication template by storing it in the Secure Enclave without
a means to access the template other than obtaining the information whether a biometric
match occurred.
Residual Information Protection (FDP_RIP)
FDP_RIP.2 Full Residual Information Protection
FDP_RIP.2.1 {VPN}
The TOE shall enforce that any previous information content of a resource is made
unavailable upon the allocation of the resource to all objects.
Certificate Data Storage (FDP_STG)
FDP_STG_EXT.1 Extended: User Data Storage
FDP_STG_EXT.1.1 {MDF}
The TSF shall provide protected storage for the Trust Anchor Database.
Inter-TSF User Data Protected Channel (FDP_UPC)
FDP_UPC_EXT.1 Extended: Inter-TSF User Data Transfer Protection
FDP_UPC_EXT.1.1 {MDF}
The TSF provide a means for non-TSF applications executing on the TOE to use TLS,
HTTPS, Bluetooth BR/EDR, and Bluetooth LE to provide a protected communication
channel between the non-TSF application and another 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.
FDP_UPC_EXT.1.2 {MDF}
The TSF shall permit the non-TSF applications to initiate communication via the trusted
channel.
VID: 10937
Page 66 of 172 © 2019 Apple Inc. Version: 1.6
6.4 Identification and Authentication (FIA)
Authentication Failures (FIA_AFL)
FIA_AFL_EXT.1 Extended: Authentication Failure Handling
FIA_AFL_EXT.1.1 {MDF}
The TSF shall consider password and no other as critical authentication mechanisms.
FIA_AFL_EXT.1.2 {MDF}
The TSF shall detect when a configurable positive integer within 2 to 11 of unique
unsuccessful authentication attempts occur related to last successful authentication for each
authentication mechanism.
FIA_AFL_EXT.1.3 {MDF}
The TSF shall maintain the number of unsuccessful authentication attempts that have
occurred upon power off.
FIA_AFL_EXT.1.4 {MDF}
When the defined number of unsuccessful authentication attempts has exceeded the
maximum allowed for a given authentication mechanism, all future authentication attempts
will be limited to other available authentication mechanisms, unless the given mechanism is
designated as a critical authentication mechanism.
FIA_AFL_EXT.1.5 {MDF}
When the defined number of unsuccessful authentication attempts for the last available
authentication mechanism or single critical authentication mechanism has been surpassed,
the TSF shall perform a wipe of all protected data.
FIA_AFL_EXT.1.6 {MDF}
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying
the user that the authentication was unsuccessful.
Bluetooth Authorization and Authentication (FIA_BLT)
FIA_BLT_EXT.1 Extended: Bluetooth User Authorization
FIA_BLT_EXT.1.1 {MDF}
The TSF shall require explicit user authorization before pairing with a remote Bluetooth
device.
FIA_BLT_EXT.2 Extended: Bluetooth Mutual Authentication
FIA_BLT_EXT.2.1 {MDF}
The TSF shall require Bluetooth mutual authentication between devices prior to any data
transfer over the Bluetooth link.
FIA_BLT_EXT.3 Extended: Rejection of Duplicate Bluetooth Connections
FIA_BLT_EXT.3.1 {MDF}
VID: 10937
Page 67 of 172 © 2019 Apple Inc. Version: 1.6
The TSF shall discard connection attempts from a Bluetooth device address (BD_ADDR) to
which a current connection already exists.
FIA_BLT_EXT.4 Extended: Secure Simple Pairing
FIA_BLT_EXT.4.1 {MDF}
The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the controller.
Furthermore, Secure Simple Pairing shall be used during the pairing process if the remote
device also supports it.
Biometric Authentication (FIA_BMG)
FIA_BMG_EXT.1 Extended: Accuracy of Biometric Authentication21
FIA_BMG_EXT.1.1(1) {MDF}(Touch ID Gen.1)
The one-attempt BAF False Accept Rate (FAR) for fingerprint authentication shall not
exceed 1:53K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 78.
FIA_BMG_EXT.1.1(2) {MDF}(Touch ID Gen.2)
The one-attempt BAF False Accept Rate (FAR) for fingerprint authentication shall not
exceed 1:206K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 28.
FIA_BMG_EXT.1.1(3) {MDF}(Touch ID Gen.3)
The one-attempt BAF False Accept Rate (FAR) for fingerprint authentication shall not
exceed 1:231K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 20.
FIA_BMG_EXT.1.1(4) {MDF}(Face ID A11 Bionic)
The one-attempt BAF False Accept Rate (FAR) for face authentication shall not exceed
1:1000K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 20.
FIA_BMG_EXT.1.1(5) {MDF}(Face ID A12 Bionic)
The one-attempt BAF False Accept Rate (FAR) for face authentication shall not exceed
1:1000K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 20.
FIA_BMG_EXT.1.1(6) {MDF}(Face ID A12X Bionic)
The one-attempt BAF False Accept Rate (FAR) for face authentication shall not exceed
1:1000K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 20.
FIA_BMG_EXT.1.2(1) {MDF}(Touch ID Gen.1)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
106,000 within a 1% margin.
FIA_BMG_EXT.1.2(2) {MDF}(Touch ID Gen.2)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
41,200 within a 1% margin.
FIA_BMG_EXT.1.2(3) {MDF}(Touch ID Gen.3)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
46,200 within a 1% margin.
21 TD0301 is applicable to these SFRs
VID: 10937
Page 68 of 172 © 2019 Apple Inc. Version: 1.6
FIA_BMG_EXT.1.2(4) {MDF}(Face ID A11 Bionic)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
338,462 within a 1% margin.
FIA_BMG_EXT.1.2(5) {MDF}(Face ID A12 Bionic)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
296,097 within a 1% margin.
FIA_BMG_EXT.1.2(6) {MDF}(Face ID A12X Bionic)
The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in
726,073 within a 1% margin.
FIA_BMG_EXT.2 Extended: Biometric Enrollment
FIA_BMG_EXT.2.1(1) {MDF}(Touch ID)
The TSF shall only use biometric samples of sufficient quality for enrollment. Sample data
shall have sufficient fingerprint-modality content and no severe structural sensing
artifacts.
FIA_BMG_EXT.2.1(2) {MDF}(Face ID)
The TSF shall only use biometric samples of sufficient quality for enrollment. Sample data
shall have sufficient face-modality content and no severe structural sensing artifacts.
FIA_BMG_EXT.3 Extended: Biometric Verification
FIA_BMG_EXT.3.1(1) {MDF}(Touch ID)
The TSF shall only use biometric samples of sufficient quality for verification. As such, sample
data shall have sufficient fingerprint-modality content and no severe structural sensing
artifacts.
FIA_BMG_EXT.3.1(2) {MDF}(Face ID)
The TSF shall only use biometric samples of sufficient quality for verification. As such, sample
data shall have sufficient face-modality content and no severe structural sensing
artifacts.
FIA_BMG_EXT.5 Extended: Handling Unusual Biometric Templates
FIA_BMG_EXT.5.1 {MDF}
The matching algorithm shall handle properly formatted enrollment templates and/or
authentication templates, especially those with unusual data properties, appropriately. If such
templates contain incorrect syntax, are of low quality, or contain enrollment data considered
unrealistic for a given modality, then they shall be rejected by the matching algorithm and an
error code shall be reported.
Enrollment of Mobile Device into Management (FIA_ENR)
FIA_ENR_EXT.2 Extended: Enrollment of Mobile Device into Management
FIA_ENR_EXT.2.1 {AGENT}
The MDM Agent shall record the reference identifier of the MDM Server during the enrollment
process.
VID: 10937
Page 69 of 172 © 2019 Apple Inc. Version: 1.6
Port Access Entity Authentication (FIA_PAE)
FIA_PAE_EXT.1 Extended: PAE Authentication
FIA_PAE_EXT.1.1 {WLAN}
The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the
“Supplicant” role.
Password Management (FIA_PMG)
FIA_PMG_EXT.1 Extended: Password Management
FIA_PMG_EXT.1.1 {MDF}
The TSF shall support the following for the Password Authentication Factor:
1) Passwords shall be able to be composed of any combination of upper and lower
case letters, numbers, and special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”,
“*”, “(“, “)”;
2) Password length up to 16 characters shall be supported.
Authentication Throttling (FIA_TRT)
FIA_TRT_EXT.1 Extended: Authentication Throttling
FIA_TRT_EXT.1.1 {MDF}
The TSF shall limit automated user authentication attempts by enforcing a delay between
incorrect authentication attempts for all authentication mechanisms selected in
FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be
attempted per 500 milliseconds.
User Authentication (FIA_UAU)
FIA_UAU.5 Multiple Authentication Mechanisms
FIA_UAU.5.1 {MDF}
The TSF shall provide password and fingerprint, face to support user authentication.
Note: iOS does not support hybrid authentication factor
FIA_UAU.5.2 {MDF}
The TSF shall authenticate any user's claimed identity according to the validation of the
user’s password, fingerprint, or face.
Note: The TSS describes authentication rules in more detail.
FIA_UAU.6 Re-Authentication
FIA_UAU.6.1(1) {MDF}
The TSF shall re-authenticate the user via the Password Authentication Factor under the
conditions attempted change to any supported authentication mechanisms.
FIA_UAU.6.1(2) {MDF}
VID: 10937
Page 70 of 172 © 2019 Apple Inc. Version: 1.6
The TSF shall re-authenticate the user via an authentication factor defined in FIA_UAU.5.1
under the conditions TSF-initiated lock, user-initiated lock, and no other conditions.
FIA_UAU.7 Protected authentication feedback
FIA_UAU.7.1 {MDF}
The TSF shall provide only obscured feedback to the device’s display to the user while the
authentication is in progress.
FIA_UAU_EXT.1 Extended: Authentication for Cryptographic Operation
FIA_UAU_EXT.1.1 {MDF}
The TSF shall require the user to present the Password Authentication Factor prior to
decryption of protected data and encrypted DEKs, KEKs and all software-based key
storage at startup.
FIA_UAU_EXT.2 Extended: Timing of Authentication
FIA_UAU_EXT.2.1 {MDF}
The TSF shall allow answering calls, make emergency calls, use the cameras (unless their
use is generally disallowed), and the flashlight on behalf of the user to be performed before
the user is authenticated.
FIA_UAU_EXT.2.2 {MDF}
The TSF shall require each user to be successfully authenticated before allowing any other
TSF-mediated actions on behalf of that user.
X509 Certificates (FIA_X509_EXT)
FIA_X509_EXT.1 Extended: Validation of Certificates
FIA_X509_EXT.1.1 {MDF} {VPN} {AGENT}
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 certificate in the Trust Anchor Database.
• 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 the Online
Certificate Status Protocol (OCSP) as specified in RFC 2560.
• 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 (Conditional) 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.
FIA_X509_EXT.1.2 {MDF} {VPN} {AGENT}
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.
VID: 10937
Page 71 of 172 © 2019 Apple Inc. Version: 1.6
X509 Certificate Authentication (FIA_X509_EXT)
FIA_X509_EXT.2 Extended: X509 Certificate Authentication
FIA_X509_EXT.2.1 {MDF} {VPN} {AGENT}
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
IPsec, and TLS, HTTPS, and code signing for system software updates, code signing for
mobile applications, code signing for integrity verification.
FIA_X509_EXT.2.2 {MDF} {VPN} {AGENT}
When the TSF cannot establish a connection to determine the revocation status of a
certificate, the TSF shall not accept the certificate.
FIA_X509_EXT.2/WLAN Extended: X509 Certificate Authentication (EAP-
TLS)
FIA_X509_EXT.2.1/WLAN {WLAN}
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
EAP-TLS exchanges.
FIA_X509_EXT.2.2 {WLAN}
When the TSF cannot establish a connection to determine the validity of a certificate, the TSF
shall allow the administrator to choose whether to accept the certificate in these cases, allow
the user to choose whether to accept the certificate in these cases.
Request Validation of Certificates (FIA_X509_EXT)
FIA_X509_EXT.3 Extended: Request Validation of Certificates
FIA_X509_EXT.3.1 {MDF} {AGENT}
The TSF shall provide a certificate validation service to applications.
FIA_X509_EXT.3.2 {MDF} {AGENT}
The TSF shall respond to the requesting application with the success or failure of the
validation.
VID: 10937
Page 72 of 172 © 2019 Apple Inc. Version: 1.6
6.5 Security Management (FMT)
Management of Functions in TSF (FMT_MOF)
FMT_MOF_EXT.1 Extended: Management of Security Functions Behavior
FMT_MOF_EXT.1.1 {MDF}
The TSF shall restrict the ability to perform the functions in column 3 of Table 5 to the user.
FMT_MOF_EXT.1.2 {MDF}
The TSF shall restrict the ability to perform the functions in column 5 of Table 5 to the
administrator when the device is enrolled and according to the administrator-configured
policy.
Note: The referenced Table 5 is found in [PP_MD_V3.1].
Trusted Policy Update (FMT_POL)
FMT_POL_EXT.2 Trusted Policy Update
FMT_POL_EXT.2.1 {AGENT}
The MDM Agent shall only accept policies and policy updates digitally signed by the
Enterprise.
FMT_POL_EXT.2.2 {AGENT}
The MDM Agent shall not install policies if the policy signing certificate is deemed invalid.
Specification of Management Functions (FMT_SMF)
FMT_SMF_EXT.1 Extended: Specification of Management Functions
FMT_SMF_EXT.1.1 {MDF}
The TSF shall be capable of performing the following management functions:
VID: 10937
Page 73 of 172 © 2019 Apple Inc. Version: 1.6
Management Function Mandatory
Function
(FMT_SMF_EXT.1)
Restricted
to the User
(FMT_SMF_EXT.1)
Administrator Restricted to
the
Administrator
(FMT_MOF_EXT.1.2)
Function 1:
Configure password policy:
a) minimum password
length
b) minimum password
complexity
c) maximum password
lifetime
Y N Y Y
Function 2:
Configure session locking
policy:
a) screen-lock
enabled/disabled
b) screen lock timeout
c) number of
authentication failures
Y N Y Y
Function 3:
Enable/disable the VPN
protection:
a) across device
b) on a per-app basis
Y (N) (Y) (Y)
Function 4:
Enable/disable Bluetooth, Wi-
Fi, cellular radio, NFC
Y (Y) - (N)
Function 5:
Enable/disable cameras:
a) across device
b) on a per-app basis
Y (Y) (Y) (N)
Function 5:
Enable/disable microphones:
b) on a per-app basis
Y (Y) (Y) (N)
Function 6:
Transition to the locked state
Y N Y N
Function 7:
TSF wipe of protected data
Y N Y N
Function 8:
Configure application
installation policy by
c. denying installation of
applications
Y N Y Y
Function 9:
Import keys/secrets into the
secure key storage
Y (N) (Y) N
Function 10:
Destroy imported keys/secrets
and no other keys/secrets in
the secure key storage
Y (N) (Y) N
VID: 10937
Page 74 of 172 © 2019 Apple Inc. Version: 1.6
Management Function Mandatory
Function
(FMT_SMF_EXT.1)
Restricted
to the User
(FMT_SMF_EXT.1)
Administrator Restricted to
the
Administrator
(FMT_MOF_EXT.1.2)
Function 11:
Import X.509v3 certificates in
the Trust Anchor Database
Y N Y (Y)
Function 12:
Remove imported X509v3
certificates and no other
X509v3 certificates in the
Trust Anchor Database
Y (Y) Y N
Function 13:
Enroll the TOE in management
Y Y N N
Function 14:
Remove applications
Y N Y (Y)
Function 15:
Update system software Y N Y (Y)
Function 16:
Install applications
Y N Y (Y)
Function 17:
Remove Enterprise applications
Y N Y N
Function 18:
Configure the Bluetooth trusted
channel:
a) disable/enable the
Discoverable mode (for
BR/EDR)
b) change the Bluetooth
device name
i. specify minimum level of
security for each pairing. (for
BR/EDR and LE)
Y (Y) (N) (N)
Function 19:
enable/disable display
notifications in the locked state
of:
f. all notifications
Y (Y) (Y) (N)
Function 20
enable data-at rest protection Y (N) (Y) (Y)
Function 22:
enable/disable location
services:
a) across device
b) on a per-app basis
Y (Y) (Y) (N)
Function 23:
Enable/disable the use of
Biometric Authentication Factor
Y (N) (Y) (Y)
Function 28:
Wipe Enterprise data
N (N) (Y) N
Function 30:
Configure whether to establish
a trusted channel or disallow
establishment if the TSF cannot
establish a connection to
determine the validity of a
certificate
N (N) (Y) (N)
VID: 10937
Page 75 of 172 © 2019 Apple Inc. Version: 1.6
Management Function Mandatory
Function
(FMT_SMF_EXT.1)
Restricted
to the User
(FMT_SMF_EXT.1)
Administrator Restricted to
the
Administrator
(FMT_MOF_EXT.1.2)
Function 33:
Configure certificate used to
validate digital signature on
applications
N (N) (Y) (Y)
Function 36:
Configure the unlock banner
N N (Y) (Y)
Function 37:
Configure the auditable items
N N (Y) (Y)
Function 45:
Enable/disable the Always On
VPN protection
N (N) (Y) (Y)
Table 4: Management Functions
Key: “Y” and “N” indicate management functions that are mandated by the PP. Those marked
in parentheses “(Y)” and “(N)” are given as optional in the PP and have been implemented in
the TOE as indicated.
Note: Most of the administrator management functions are implemented by the specification
and installation of Configuration Profiles. Also, for the enforcement of other functions, such as
the password policy, the installation of Configuration Profiles with dedicated values for some
of the payload keys is required.
Note: Function 20: In the evaluated configuration, the TOE has data-at-rest protection natively
enabled once the passcode is set.
Note: Function 21 has not been included in the table since the TOE does not natively support
removable media. Backups can be made using iTunes, and backup encryption can be made
mandatory.
Note: Function 26 has not been included in the table since the TOE does not support a
developer mode.
Note: Function 27 has not been included in the table since the TOE (in its evaluated
configuration) does not support bypass of local user authentication.
Note: Function 32 has not been included in the table since audit review is not implemented on
TOE devices.
Note: Functions 24,25,29,31,34,35,38,39,40,41,42,43,44,46 and 47 have not been included in
the table since the functions are optional.
FMT_SMF_EXT.1/WLAN Specification of Management Functions
FMT_SMF_EXT.1.1/WLAN {WLAN}
The TSF shall be capable of performing the following management functions:
• configure security policy for each wireless network:
• specify the CA(s) from which the TSF will accept WLAN authentication server
certificates(s)
• security type
• authentication protocol
• client credentials to be used for authentication
FMT_SMF.1/VPN Specification of Management Functions {VPN}
FMT_SMF.1.1/VPN {VPN}
VID: 10937
Page 76 of 172 © 2019 Apple Inc. Version: 1.6
The TSF shall be capable of performing the following management functions:
• Specify IPsec-capable network devices to use for connections,
• Specify client credentials to be used for connections,
• Configure the reference identifier of the peer,
• Configuration of IKE protocol version(s) used,
• Configure IKE authentication techniques used,
• Configure the cryptoperiod for the established session keys. The unit of
measure for configuring the cryptoperiod shall be no greater than an hour,
• Configure certificate revocation check,
• Specify the algorithm suites that may be proposed and accepted during the
IPsec exchanges,
• load X.509v3 certificates used by the security functions in [VPNPP],
• ability to update the TOE, and to verify the updates,
• ability to configure all security management functions identified in other
sections of [VPNPP].
FMT_SMF_EXT.2 Extended: Specification of Remediation Actions
FMT_SMF_EXT.2.1 {MDF} 22
The TSF shall offer wipe of all data associated with profiles under management upon
unenrollment and when issuing a remote wipe command.
FMT_SMF_EXT.3 Extended: Specification of Management Functions
FMT_SMF_EXT.3.1 {AGENT}
The MDM Agent shall be capable of interacting with the platform to perform the following
functions:
• administrator-provided management functions in MDF PP;
• Import the certificates to be used for authentication of MDM Agent communications
• no additional functions
FMT_SMF_EXT.3.2 {AGENT}
The MDM Agent shall be capable of performing the following functions:
• Enroll in management;
• Configure whether users can unenroll the agent from management
• no other functions
User Unenrollment Prevention
FMT_UNR_EXT.1 Extended: User Unenrollment Prevention
FMT_UNR_EXT.1.1 {AGENT}
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.
22 TD0346 is applicable to this SFR
VID: 10937
Page 77 of 172 © 2019 Apple Inc. Version: 1.6
6.6 Protection of the TSF (FPT)
Anti-Exploitation Services (FPT_AEX)
FPT_AEX_EXT.1 Extended: Anti-Exploitation Services (ASLR)
FPT_AEX_EXT.1.1 {MDF}
The TSF shall provide address space layout randomization ASLR to applications.
FPT_AEX_EXT.1.2 {MDF}
The base address of any user-space memory mapping will consist of at least 8 unpredictable
bits.
FPT_AEX_EXT.2 Extended: Anti-Exploitation Services (Memory Page
Permissions)
FPT_AEX_EXT.2.1 {MDF}
The TSF shall be able to enforce read, write, and execute permissions on every page of
physical memory.
FPT_AEX_EXT.3 Extended: Anti-Exploitation Services (Overflow
Protection)
FPT_AEX_EXT.3.1 {MDF}
TSF processes that execute in a non-privileged execution domain on the application
processor shall implement stack-based buffer overflow protection.
FPT_AEX_EXT.4 Extended: Domain Isolation
FPT_AEX_EXT.4.1 {MDF}
The TSF shall protect itself from modification by untrusted subjects.
FPT_AEX_EXT.4.2 {MDF}
The TSF shall enforce isolation of address space between applications.
JTAG Disablement (FPT_JTA)
FPT_JTA_EXT.1 Extended: JTAG Disablement
FPT_JTA_EXT.1.1 {MDF}
The TSF shall disable access through hardware to JTAG.
Key Storage (FPT_KST)
FPT_KST_EXT.1 Extended: Key Storage
FPT_KST_EXT.1.1 {MDF}
The TSF shall not store any plaintext key material in readable non-volatile memory.
VID: 10937
Page 78 of 172 © 2019 Apple Inc. Version: 1.6
FPT_KST_EXT.2 Extended: No Key Transmission
FPT_KST_EXT.2.1 {MDF}
The TSF shall not transmit any plaintext key material outside the security boundary of the
TOE.
FPT_KST_EXT.3 Extended: No Plaintext Key Export
FPT_KST_EXT.3.1 {MDF}
The TSF shall ensure it is not possible for the TOE user(s) to export plaintext keys.
Self-Test Notification (FPT_NOT)
FPT_NOT_EXT.1 Extended: Self-Test Notification
FPT_NOT_EXT.1.1 {MDF}
The TSF shall transition to non-operational mode and no other actions when the following
types of failures occur:
• failures of the self-test(s)
• TSF software integrity verification failures
• no other failures.
Reliable Time Stamps (FPT_STM)
FPT_STM.1 Reliable Time Stamps
FPT_STM.1.1 {MDF}
The TSF shall be able to provide reliable time stamps for its own use.
TSF Functionality Testing (FPT_TST)
FPT_TST_EXT.1 Extended: TSF Cryptographic Functionality Testing
FPT_TST_EXT.1.1 {MDF} {AGENT}
The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the
correct operation of all cryptographic functionality.
FPT_TST_EXT.1/VPN Extended: TSF Self-Test
FPT_TST_EXT.1.1 {VPN}
The TOE shall run a suite of self-tests during initial start-up (on power on) to demonstrate the
correct operation of all cryptographic functionality.
FPT_TST_EXT.1.2 {VPN}
The TOE shall provide the capability to verify the integrity of stored TSF executable code
when it is loaded for execution through the use of the cryptographic services specified in
FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), or FIA_X509_EXT.1
FPT_TST_EXT.1/WLAN TSF Cryptographic Functionality Testing {WLAN}
FPT_TST_EXT.1.1 {WLAN}
VID: 10937
Page 79 of 172 © 2019 Apple Inc. Version: 1.6
The TOE shall run a suite of self-tests during initial start-up (on power on) to demonstrate the
correct operation of the TSF.
FPT_TST_EXT.1.2 {WLAN}
The TOE shall provide the capability to verify the integrity of stored TSF executable code
when it is loaded for execution through the use of the TSF-provided cryptographic
services: Random number generation, data encryption / decryption, signature
generation/verification, message digest, message authentication, key derivation, key
generation and key wrapping.
TSF Integrity Testing
FPT_TST_EXT.2 Extended: TSF Integrity Testing
FPT_TST_EXT.2.1(1) {MDF}
The TSF shall verify the integrity of the bootchain up through the Application Processor OS
kernel stored in mutable media prior to its execution through the use of a digital signature
using a hardware-protected asymmetric key.
FPT_TST_EXT.3 Extended: TSF Integrity Testing
FPT_TST_EXT.3.1 {MDF}
The TSF shall not execute code if the code signing certificate is deemed invalid.
Trusted Update (FPT_TUD)
FPT_TUD_EXT.1 Extended: Trusted Update: TSF Version Query
FPT_TUD_EXT.1.1 {MDF} {VPN}
The TSF shall provide authorized users the ability to query the current version of the TOE
firmware/software.
FPT_TUD_EXT.1.2 {MDF} {VPN}
The TSF shall provide authorized users the ability to query the current version of the
hardware model of the device.
FPT_TUD_EXT.1.3 {MDF} {VPN}
The TSF shall provide authorized users the ability to query the current version of installed
mobile applications.
Trusted Update Verification (FPT_TUD_EXT)
FPT_TUD_EXT.2 Extended: Trusted Update Verification
FPT_TUD_EXT.2.1 {MDF}
The TSF shall verify software updates to the Application Processor system software and no
other processor system software using a digital signature by the manufacturer prior to
installing those updates.
FPT_TUD_EXT.2.2 {MDF}
The TSF shall never update the TSF boot integrity key.
VID: 10937
Page 80 of 172 © 2019 Apple Inc. Version: 1.6
FPT_TUD_EXT.2.3 {MDF}
The TSF shall verify that the digital signature verification key used for TSF updates matches
an immutable hardware-protected public key.
FPT_TUD_EXT.2.4 {MDF}
The TSF shall verify mobile application software using a digital signature mechanism prior to
installation.
FPT_TUD_EXT.3 Extended: Trusted Update Verification
FPT_TUD_EXT.3.1 {MDF}
The TSF shall not install code if the code signing certificate is deemed invalid.
FPT_TUD_EXT.4 Extended: Trusted Update Verification
FPT_TUD_EXT.4.1 {MDF}
The TSF shall by default only install mobile applications cryptographically verified by a built-
in X.509v3 certificate.
FPT_TUD_EXT.4.2 {MDF}
The TSF shall verify that software updates to the TSF are a current or later version than the
current version of the TSF.
VID: 10937
Page 81 of 172 © 2019 Apple Inc. Version: 1.6
6.7 TOE Access (FTA)
Session Locking (FTA_SSL)
FTA_SSL_EXT.1 Extended: TSF and User-initiated Locked State
FTA_SSL_EXT.1.1 {MDF}
The TSF shall transition to a locked state after a time interval of inactivity.
FTA_SSL_EXT.1.2 {MDF}
The TSF shall transition to a locked state after initiation by either the user or the
administrator.
FTA_SSL_EXT.1.3 {MDF}
The TSF shall, upon transitioning to the locked state, perform the following operations:
a) clearing or overwriting display devices, obscuring the previous contents;
b) zeroize the decrypted class key for the NSFileProtectionComplete class.
Default TOE Access Banners (FTA_TAB)
FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1 {MDF}
Before establishing a user session, the TSF shall display an advisory warning message
regarding unauthorized use of the TOE.
Wireless Network Access (FTA_WSE)
FTA_WSE_EXT.1 Extended: Wireless Network Access
FTA_WSE_EXT.1.1 {WLAN}
The TSF shall be able to attempt connections only to wireless networks specified as
acceptable networks as configured by the administrator in FMT_SMF_EXT.1.1/WLAN.
VID: 10937
Page 82 of 172 © 2019 Apple Inc. Version: 1.6
6.8 Trusted Path/Channels (FTP)
Trusted Channel Communication (FTP_ITC)
FTP_ITC_EXT.1(1) Extended: Trusted Channel Communication
FTP_ITC_EXT.1.1(1) {VPN}
The TSF shall use 802.11-2012, 802.1X, and EAP-TLS, IPsec, and TLS, HTTPS to provide a
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.
FTP_ITC_EXT.1.2(1) {VPN}
The TSF shall permit the TSF to initiate communication via the trusted channel.
FTP_ITC_EXT.1.3(1) {VPN}
The TSF shall initiate communication via the trusted channel for wireless access point
connections, administrative communication, configured enterprise connections, and OTA
updates
FTP_ITC_EXT.1(2) Extended: Trusted Channel Communication
Note: The Agent EP modifies FTP_ITC_EXT.1(1) and is labeled as
FTP_ITC_EXT.1(2) for clarity.
FTP_ITC_EXT.1.1(2) {AGENT} {MDF}
The TSF shall use HTTPS to provide a 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.
FTP_ITC_EXT.1.2(2) {AGENT} {MDF}
The TSF shall permit the TSF and the MDM Server and no other IT entities to initiate
communication via the trusted channel.
FTP_ITC_EXT.1.3(2) {AGENT} {MDF}
The TSF shall initiate communication via the trusted channel for all communication between
the MDM Agent and the MDM Server and no other communication.
FTP_ITC_EXT.1/WLAN(3) Extended: Trusted Channel Communication
FTP_ITC_EXT.1.1/WLAN(3) {WLAN}
The TSF shall use 802.11-2012, 802.1X, and EAP-TLS to provide a trusted communication
channel between itself and a wireless access point 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.
FTP_ITC_EXT.1.2/WLAN(3) {WLAN}
The TSF shall initiate communication via the trusted channel for wireless access point
connections.
VID: 10937
Page 83 of 172 © 2019 Apple Inc. Version: 1.6
6.9 Security Functional Requirements Rationale
The requirements in the PP-Group are assumed to represent a complete set of requirements
that serve to address any interdependencies. Given that all of the appropriate functional
requirements given in the PPs have been copied into this [ST], the dependency analysis for
the requirements is assumed to be already performed by the PP authors and is not
reproduced in this document.
VID: 10937
Page 84 of 172 © 2019 Apple Inc. Version: 1.6
7 Security Assurance Requirements
The Security Assurance Requirements (SARs) for the TOE are defined in [PP_MD_V3.1].
They consist of the assurance components of Evaluation Assurance Level (EAL1) as defined
in part 3 of the CC augmented by ASE_SPD.1 and ALC_TSU_EXT.1, which is defined in
[PP_MD_V3.1]. These security assurance requirements are also applicable to the
[EP_MDM_AGENT_V3.0], [EP_MDM_AGENT_V3.0], and [PP_WLAN_CLI_EP_V1.0]
The assurance components included in [PP_MD_V3.1] are:
• ASE_CCL.1
• ASE_ECD.1
• ASE_INT.1
• ASE_OBJ.1
• ASE_REQ.1
• ASE_SPD.1
• ASE_TSS.1
• ADV_FSP.1
• AGD_OPE.1
• AGD_PRE.1
• ALC_CMC.1
• ALC_CMS.1
• ALC_TSU_EXT.1
• ATE_IND.1
• AVA_VAN.1
7.1 Security Target Evaluation (ASE)
7.1.1 Conformance Claims (ASE_CCL.1)
ASE_CCL.1.1D
The developer shall provide a conformance claim.
ASE_CCL.1.2D
The developer shall provide a conformance claim rationale.
ASE_CCL.1.1C
The conformance claim shall contain a CC conformance claim that identifies the version of
the CC to which the ST and the TOE claim conformance.
ASE_CCL.1.2C
The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either
CC Part 2 conformant or CC Part 2 extended.
ASE_CCL.1.3C
The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either
CC Part 3 conformant or CC Part 3 extended.
ASE_CCL.1.4C
The CC conformance claim shall be consistent with the extended components definition.
VID: 10937
Page 85 of 172 © 2019 Apple Inc. Version: 1.6
ASE_CCL.1.5C
The conformance claim shall identify all PPs and security requirement packages to which the
ST claims conformance.
ASE_CCL.1.6C
The conformance claim shall describe any conformance of the ST to a package as either
package-conformant or package-augmented.
ASE_CCL.1.7C
The conformance claim rationale shall demonstrate that the TOE type is consistent with the
TOE type in the PPs for which conformance is being claimed.
ASE_CCL.1.8C
The conformance claim rationale shall demonstrate that the statement of the security problem
definition is consistent with the statement of the security problem definition in the PPs for
which conformance is being claimed.
ASE_CCL.1.9C
The conformance claim rationale shall demonstrate that the statement of security objectives
is consistent with the statement of security objectives in the PPs for which conformance is
being claimed.
ASE_CCL.1.10C
The conformance claim rationale shall demonstrate that the statement of security
requirements is consistent with the statement of security requirements in the PPs for which
conformance is being claimed.
ASE_CCL.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
7.1.2 Extended Components Definition (ASE_ECD.1)
ASE_ECD.1.1D
The developer shall provide a statement of security requirements.
ASE_ECD.1.2D
The developer shall provide an extended components definition.
ASE_ECD.1.1C
The statement of security requirements shall identify all extended security requirements.
ASE_ECD.1.2C
The extended components definition shall define an extended component for each extended
security requirement.
ASE_ECD.1.3C
The extended components definition shall describe how each extended component is related
to the existing CC components, families, and classes.
ASE_ECD.1.4C
The extended components definition shall use the existing CC components, families, classes,
and methodology as a model for presentation.
ASE_ECD.1.5C
The extended components shall consist of measurable and objective elements such that
conformance or nonconformance to these elements can be demonstrated.
VID: 10937
Page 86 of 172 © 2019 Apple Inc. Version: 1.6
ASE_ECD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ASE_ECD.1.2E
The evaluator shall confirm that no extended component can be clearly expressed using
existing components.
7.1.3 ST Introduction (ASE_INT.1)
ASE_INT.1.1D
The developer shall provide an ST introduction.
ASE_INT.1.1C
The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a
TOE description.
ASE_INT.1.2C
The ST reference shall uniquely identify the ST.
ASE_INT.1.3C
The TOE reference shall identify the TOE.
ASE_INT.1.4C
The TOE overview shall summarize the usage and major security features of the TOE.
ASE_INT.1.5C
The TOE overview shall identify the TOE type.
ASE_INT.1.6C
The TOE overview shall identify any non-TOE hardware/software/firmware required by the
TOE.
ASE_INT.1.7C
The TOE description shall describe the physical scope of the TOE.
ASE_INT.1.8C
The TOE description shall describe the logical scope of the TOE.
ASE_INT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ASE_INT.1.2E
The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE
description are consistent with each other.
7.1.4 Security Objectives for the Operational Environment (ASE_OBJ.1)
ASE_OBJ.1.1D
The developer shall provide a statement of security objectives.
ASE_OBJ.1.1C
The statement of security objectives shall describe the security objectives for the operational
environment.
ASE_OBJ.1.1E
VID: 10937
Page 87 of 172 © 2019 Apple Inc. Version: 1.6
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
7.1.5 Stated Security Requirements (ASE_REQ.1)
ASE_REQ.1.1D
The developer shall provide a statement of security requirements.
ASE_REQ.1.2D
The developer shall provide a security requirements rationale.
ASE_REQ.1.1C
The statement of security requirements shall describe the SFRs and the SARs.
ASE_REQ.1.2C
All subjects, objects, operations, security attributes, external entities and other terms that are
used in the SFRs and the SARs shall be defined.
ASE_REQ.1.3C
The statement of security requirements shall identify all operations on the security
requirements.
ASE_REQ.1.4C
All operations shall be performed correctly.
ASE_REQ.1.5C
Each dependency of the security requirements shall either be satisfied, or the security
requirements rationale shall justify the dependency not being satisfied.
ASE_REQ.1.6C
The statement of security requirements shall be internally consistent.
ASE_REQ.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
7.1.6 Security Problem Definition (ASE_SPD.1)
ASE_SPD.1.1D
The developer shall provide a security problem definition.
ASE_SPD.1.1C
The security problem definition shall describe the threats.
ASE_SPD.1.2C
All threats shall be described in terms of a threat agent, an asset, and an adverse action.
ASE_SPD.1.3C
The security problem definition shall describe the OSPs.
ASE_SPD.1.4C
The security problem definition shall describe the assumptions about the operational
environment of the TOE.
ASE_SPD.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
VID: 10937
Page 88 of 172 © 2019 Apple Inc. Version: 1.6
7.1.7 TOE Summary Specification (ASE_TSS.1)
ASE_TSS.1.1D
The developer shall provide a TOE summary specification.
ASE_TSS.1.1C
The TOE summary specification shall describe how the TOE meets each SFR.
ASE_TSS.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
ASE_TSS.1.2E
The evaluator shall confirm that the TOE summary specification is consistent with the TOE
overview and the TOE description.
7.2 Development (ADV)
7.2.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.
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.
7.3 Guidance documents (AGD)
7.3.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1D
The developer shall provide operational user guidance.
AGD_OPE.1.1C
VID: 10937
Page 89 of 172 © 2019 Apple Inc. Version: 1.6
The operational user guidance shall describe, for each user role, the user-accessible
functions and privileges that should be controlled in a secure processing environment,
including appropriate warnings.
AGD_OPE.1.2C
The operational user guidance shall describe, for each user role, how to use the available
interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3C
The operational user guidance shall describe, for each user role, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
values as appropriate.
AGD_OPE.1.4C
The operational user guidance shall, for each user role, clearly present each type of security
relevant event relative to the user-accessible functions that need to be performed, including
changing the security characteristics of entities under the control of the TSF.
AGD_OPE.1.5C
The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and
implications for maintaining secure operation.
AGD_OPE.1.6C
The operational user guidance shall, for each user role, describe the security measures to be
followed in order to fulfil 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.
7.3.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1D
The developer shall provide the TOE including its preparative procedures.
AGD_PRE.1.1D
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.2D
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.
VID: 10937
Page 90 of 172 © 2019 Apple Inc. Version: 1.6
7.4 Life-cycle support (ALC)
7.4.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.1C
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
7.4.2 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.2.1D
The developer shall provide a configuration list for the TOE.
ALC_CMS.2.1C
The configuration list shall include the following: the TOE itself; and the evaluation evidence
required by the SARs.
ALC_CMS.2.2C
The configuration list shall uniquely identify the configuration items.
ALC_CMS.2.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
7.4.3 Timely Security Updates (ALC_TSU_EXT.1)
ALC_TSU_EXT.1.1D
The developer shall provide a description in the TSS of how timely security updates are made
to the TOE.
ALC_TSU_EXT.1.1C
The description shall include the process for creating and deploying security updates for the
TOE software/firmware.
ALC_TSU_EXT.1.2C
The description shall express the time window as the length of time, in days, between public
disclosure of a vulnerability and the public availability of security updates to the TOE.
ALC_TSU_EXT.1.3C
The description shall include the mechanisms publicly available for reporting security issues
pertaining to the TOE.
ALC_TSU_EXT.1.4C
The description shall include where users can seek information about the availability of new
updates including details (e.g. CVE identifiers) of the specific public vulnerabilities correct by
each update.
ALC_TSU_EXT.1.1E
The evaluator shall confirm that the information provided meets all requirements for content
and presentation of evidence.
VID: 10937
Page 91 of 172 © 2019 Apple Inc. Version: 1.6
7.5 Tests (ATE)
7.5.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.
7.6 Vulnerability assessment (AVA)
7.6.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.
VID: 10937
Page 92 of 172 © 2019 Apple Inc. Version: 1.6
8 TOE Summary Specification (TSS)
This chapter describes the relevant aspects of how the security functional requirements are
implemented in the security functionality provided by the TOE. This chapter is structured in
accordance with the structuring of the security functional requirements in section 6, Security
Functional Requirements, of this document, which in turn has been taken from the structure
of the description of the security functional requirements in the PP-Group].
The TOE security boundary is described in section 1.5 TOE Architecture, above.
8.1 Mapping to the Security Functional Requirements
Table 5: Mapping of SFR Assurance Activities to the TSS, following, provides a mapping of
the SFRs defined in chapter 6 of this [ST] to the functions implemented by the TOE, referring
to the sections of this TSS where the additional information is given.
VID: 10937
Page 93 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FAU
FAU_ALT_EXT.2 .1 {AGENT} Describes how the alerts are implemented, how the candidate policy updates are
obtained; and the actions that take place for successful (policy update installed)
and unsuccessful (policy update not installed) cases.
Identifies the software components that are performing the processing.
Describes how reachability events are implemented, and if configurable is
selected in FMT_SMF_EXT.3.2.
Clearly indicates who (MDM Agent or MDM Server) initiates reachability events.
8.9 Trusted Path/Channels (FTP)
8.10.2 MDM Agent Alerts
Table 16: MDM Agent Status Commands
8.10.2.3 Alerts on receiving periodic reachability
events
FAU_ALT_EXT.2.2 {AGENT} Describes under what circumstances, if any, the alert may not be generated, how
alerts are queued, and the maximum amount of storage for queued messages.
8.10.2.1 Queuing of Alerts
FAU_GEN.1.1(1){MDF} There is no TSS assurance activity for this SFR. 8.10.1 Audit Records
Table 2: Combined mandatory auditable events
from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0].
FAU_GEN.1.1(2){AGENT} Provides a format for audit records. Each audit record format type must be
covered, along with a brief description of each field.
8.10.1 Audit Records
Table 2: Combined mandatory auditable events
from [PP_MD_V3.1] and
[PP_WLAN_CLI_EP_V1.0].
FAU_GEN.1.2 (1){MDF} There is no TSS assurance activity for this SFR. NA
FAU_GEN.1.2(2){AGENT} Provides a format for audit records, and a brief description of each field. 8.10.1 Audit Records
FAU_SEL.1.1(2) {AGENT} There is no TSS assurance activity for this SFR.
FAU_STG.1.1{MDF} There is no TSS assurance activity for this SFR.
FAU_STG.1.2{MDF} Lists the location of all logs and the access controls of those files such that
unauthorized modification and deletion are prevented.
8.10.1 Audit Records
VID: 10937
Page 94 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FAU_STG.4.1{MDF} Describes the size limits on the audit records, the detection of a full audit trail,
and the action(s) taken by the TSF when the audit trail is full. The action(s)
results in the deletion or overwrite of the oldest stored record.
8.10.1 Audit Records
8.6.2 Configuration Profiles
VID: 10937
Page 95 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS
FCS_CKM.1.1(1)
{MDF} {VPN} {AGENT}
Identifies the key sizes supported by the TOE. If the ST specifies more than one
scheme, it identifies the usage for each scheme.
Table 8: Explanation of usage for cryptographic
functions in the cryptographic modules
FCS_CKM.1.1/WLAN {WLAN} Describes how the primitives defined and implemented by this EP are used by
the TOE in establishing and maintaining secure connectivity to the wireless
clients.
Provides a description of the developer’s method(s) of assuring that their
implementation conforms to the cryptographic standards; this includes not only
testing done by the developing organization, but also any third-party testing that
is performed.
8.9.3 Wireless LAN (WiFi Alliance certificates)
FCS_CKM.1.1/VPN(IKE) {VPN} Describes how the key generation functionality is invoked. 8.3.1 Overview of Key Management.
FCS_CKM.2.1(1)
{MDF} {VPN} {AGENT}
Demonstrates that the supported key establishment schemes correspond to the
key generation schemes identified in FCS_CKM.1.1. If the ST specifies more
than one scheme, it identifies the usage for each scheme.
8.3.1 Overview of Key Management
8.3.1.1 Password based key derivation.
FCS_CKM.2.1(2) {MDF} There is no TSS assurance activity for this SFR.
FCS_CKM.2.1/WLAN {WLAN} Describes how the Group Temporal Key (GTK) is unwrapped prior to being
installed for use on the TOE using the AES implementation specified in this EP.
8.9.3 Wireless LAN
8.9.3 Wireless LAN (WiFi Alliance certificates)
VID: 10937
Page 96 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_CKM_EXT.1.1 {MDF}
FCS_CKM_EXT.1.2 {MDF}
FCS_CKM_EXT.1.3 {MDF}
Shows that a REK is supported by the TOE.
Includes a description of the protection provided by the TOE for a REK.
Includes a description of the method of generation of a REK.
Describes how any reading, import, and export of that REK is prevented.
Describes how encryption/decryption/derivation actions are isolated so as to
prevent applications and system-level processes from reading the REK while
allowing encryption/decryption/derivation by the key.
Describes how the Rich OS is prevented from accessing the memory containing
REK key material, which software is allowed access to the REK, how any other
software in the execution environment is prevented from reading that key
material, and what other mechanisms prevent the REK key material from being
written to shared memory locations between the Rich OS and the separate
execution environment.
If key derivation is performed using a REK, the TSS describes the key derivation
function and the approved derivation mode and the key expansion algorithm
according to FCS_CKM_EXT.3.2.
Documents that the generation of a REK meets the FCS_RBG_EXT.1.1 and
FCS_RBG_EXT.1.2 requirements. If REK(s) is/are generated on-device, the TSS
shall include a description of the generation mechanism including what triggers a
generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and
whether a separate instance of the RBG is used for REK(s).
Section 8.2.1 The Secure Enclave
Section 8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
The proprietary EAR (On file with NIAP) has
analyzed the random bit generator (RBG) used
in the production environment for compliance to
the requirements defined in FCS_RBG_EXT.1.
FCS_CKM_EXT.2.1 {MDF} Describes how the functionality described by FCS_RBG_EXT.1 is invoked to
generate DEKs.
Figure 5: Key Hierarchy in iOS
8.2 Hardware Protection Functions
8.3 Cryptographic Support.
VID: 10937
Page 97 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_CKM_EXT.3.1 {MDF
FCS_CKM_EXT.3.2 {MDF}
Describes the formation of all KEKs and that the key sizes match those
described by the ST author.
Describes that each key (DEKs, software-based key storage, and KEKs) is
encrypted by keys of equal or greater security strength using one of the selected
methods.
If a KDF is used, the evaluator shall ensure that the TSS includes a description of
the key derivation function and shall verify the key derivation uses an approved
derivation mode and key expansion algorithm according to SP 800-108.
8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
This RBG in the Secure Enclave has been
analyzed for compliance with the requirements
of FCS_RBG_EXT.1 in the proprietary EAR,
which has been provided to NIAP.
FCS_CKM_EXT.4.1
{MDF} {VPN} {WLAN} {AGENT}
FCS_CKM_EXT.4.2
{MDF}{VPN}
Lists each type of plaintext key material (DEKs, software-based key storage,
KEKs, trusted channel keys, passwords, etc.) and its generation and storage
location.
Describes when each type of key material is cleared (for example, on system
power off, on wipe function, on disconnection of trusted channels, when no
longer needed by the trusted channel per the protocol, when transitioning to the
locked state, and possibly including immediately after use, while in the locked
state, etc.).
Lists, for each type of key, the type of clearing procedure that is performed
(cryptographic erase, overwrite with zeros, overwrite with random pattern, or
block erase).
If different types of memory are used to store the materials to be protected, the
TSS describes the clearing procedure in terms of the memory in which the data
are stored.
See 8.3.1 Overview of Key Management
Table 6: Summary of keys and persistent
secrets in iOS 12.
Table 7: Summary of keys and persistent
secrets used by the Agent
FCS_CKM_EXT.5.1 {MDF}
FCS_CKM_EXT.5.2 {MDF}
Describes how the device is wiped; and the type of clearing procedure that is
performed (cryptographic erase or overwrite) and, if overwrite is performed, the
overwrite procedure (overwrite with zeros, overwrite three or more times by a
different alternating pattern, overwrite with random pattern, or block erase).
If different types of memory are used to store the data to be protected, the TSS
describes the clearing procedure in terms of the memory in which the data are
stored.
See 8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
VID: 10937
Page 98 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_CKM_EXT.6.1 {MDF} Contains a description regarding the salt generation, including which algorithms
on the TOE require salts. The salt is generated using an RBG described in
FCS_RBG_EXT.1.
For PBKDF derivation of KEKs, this assurance activity may be performed in
conjunction with FCS_CKM_EXT.3.2.
See 8.2 Hardware Protection Functions
FCS_CKM_EXT.7.1 {MDF} See FCS_CKM_EXT.1. See FCS_CKM_EXT.1
FCS_COP.1.1(1)
{MDF} {VPN} {AGENT} {WLAN}
There is no TSS assurance activity for this SFR.
FCS_COP.1.1(2)
{MDF} {VPN} {AGENT} {WLAN}
Documents the association of the hash function with other TSF cryptographic
functions.
8.3 Cryptographic Support
Table 8: Explanation of usage for cryptographic
functions in the cryptographic modules
CAVS certificates listed in the Assurance Activity
Report
FCS_COP.1.1(3)
{MDF} {VPN} {AGENT} {WLAN}
There is no TSS assurance activity for this SFR.
FCS_COP.1.1(4)
{MDF} {VPN} {AGENT} {WLAN}
Specifies the following values used by the keyed-hash message authentication
code (HMAC) function: key length, hash function used, block size, and output
MAC length used.
If any manipulation of the key is performed in forming the submask that will be
used to form the KEK, that process shall be described.
Table 8: Explanation of usage for cryptographic
functions in the cryptographic modules
8.3 Cryptographic Support
8.4.8 Keyed Hash
FCS_COP.1.1(5)
{MDF} {AGENT} {WLAN}
Describes the method by which the password is first encoded and then fed to the
SHA algorithm.
Describes the settings for the algorithm (padding, blocking, etc.) and are
supported by the selections in this component as well as the selections
concerning the hash function itself.
Describes how the output of the hash function is used to form the submask that
will be input into the function and is the same length as the KEK as specified in
FCS_CKM_EXT.3.
8.3.1 Overview of Key Management
8.3.1.1 Password based key derivation
VID: 10937
Page 99 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_HTTPS_EXT.1.1
{MDF} {AGENT}
FCS_HTTPS_EXT.1.2
{MDF} {AGENT}
FCS_HTTPS_EXT.1.3
{MDF} {AGENT}
There is no TSS assurance activity for this SFR.
FCS_IPSEC_EXT.1.1 {VPN} Describes how the IPsec capabilities are implemented and how a packet is
processed.
Details the relationship between the client and the underlying platform, including
which aspects are implemented by the client, and those that are provided by the
underlying platform.
Describes how the client interacts with the platforms network stack.
If the SPD is implemented by the client, then the TSS describes how the SPD is
implemented and the rules for processing both inbound and outbound packets in
terms of the IPsec policy.
Describes the rules that are available and the resulting actions available after
matching a rule.
Describes how the available rules and actions form the SPD using terms defined
in RFC 4301 such as BYPASS, DISCARD, and PROTECT actions is sufficient to
determine which rules will be applied given the rule structure implemented by the
TOE.
The description of rule processing (for both inbound and outbound packets) is
sufficient to determine the action that will be applied, especially in the case where
two different rules may apply. This description shall cover both the initial packets
(that is, no security association (SA) is established on the interface or for that
particular packet) as well as packets that are part of an established SA.
If the SPD is implemented by the underlying platform, then the TSS describes
how the client interacts with the platform to establish and populate the SPD,
including the identification of the platform's interfaces that are used by the client.
8.9.4 VPN
8.9.4.1 AlwaysOn VPN
8.9.4.2 IPsec General
FCS_IPSEC_EXT.1.2{VPN} States that the VPN can be established to operate in tunnel mode and/or
transport mode (as selected).
8.9.4 VPN
8.9.4.3 IPsec Characteristics
VID: 10937
Page 100 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_IPSEC_EXT.1.3{VPN} Describes how a packet is processed against the SPD and that if no “rules” are
found to match, that a final rule exists, either implicitly or explicitly, that causes
the network packet to be discarded.
8.9.4 VPN
8.9.4.2 IPsec General
FCS_IPSEC_EXT.1.4{VPN} States that the algorithms AES-GCM-128, AES-GCM-256, AES-CBC-128 and
AES-CBC-256 are implemented.
8.9.4 VPN
8.9.4.3 IPsec Characteristics
FCS_IPSEC_EXT.1.5 {VPN} States that IKEv2 is implemented. 8.9.4 VPN
8.9.4.3 IPsec Characteristics
FCS_IPSEC_EXT.1.6{VPN} Identifies the algorithms used for encrypting the IKEv2 payload ( AES-CBC-128,
AES-CBC-256, AES-GCM-128, AES-GCM-256).
8.9.4 VPN
8.9.4.3 IPsec Characteristics
FCS_IPSEC_EXT.1.7{VPN} There is no TSS assurance activity for this SFR.
FCS_IPSEC_EXT.1.8{VPN} Lists the supported DH groups
Describes how a particular DH group is specified/negotiated with a peer.
8.9.4 VPN
8.9.4.3 IPsec Characteristics
8.9.4.5 IKE
FCS_IPSEC_EXT.1.9{VPN}
FCS_IPSEC_EXT.1.10{VPN}
Describes, for each DH group supported, the process for generating "x" (as
defined in FCS_IPSEC_EXT.1.9) and each nonce.
Indicates that the random number generated that meets the requirements in this
PP-Module is used, and that the length of "x" and the nonces meet the
stipulations in the requirement.
8.9.4 VPN
8.9.4.5 IKE
FCS_IPSEC_EXT.1.11{VPN}
FCS_IPSEC_EXT.1.12{VPN}
FCS_IPSEC_EXT.1.13{VPN}
Identifies RSA and/or ECDSA as being used to perform peer authentication.
Describes how the TOE compares the peer’s presented identifier to the reference
identifier, including whether the certificate presented identifier is compared to the
ID payload presented identifier, which field(s) of the certificate are used as the
presented identifier (DN, Common Name, or SAN), and, if multiple fields are
supported, the logical order comparison.
If the ST author assigned an additional identifier type, the TSS description shall
also include a description of that type and the method by which that type is
compared to the peer’s presented certificate.
8.9.4 VPN
8.9.4.3 IPsec Characteristics
8.9.4.4 Peer authentication
VID: 10937
Page 101 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_IPSEC_EXT.1.14{VPN} Describes the potential strengths (in terms of the number of bits in the symmetric
key) of the algorithms that are allowed for the IKE and ESP exchanges.
Describes the checks that are done when negotiating IKEv2 CHILD_SA suites to
ensure that the strength (in terms of the number of bits of key in the symmetric
algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA
this is protecting the negotiation.
8.9.4 VPN
8.9.4.5 IKE
FCS_IV_EXT.1.1 {MDF} Describes the encryption of all keys.
Describes that the formation of the IVs for each key encrypted by the same KEK
meets FCS_IV_EXT.1.
Section 8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
FCS_RBG_EXT.1.1
{MDF}{VPN}{WLAN}{AGENT}
FCS_RBG_EXT.1.2
{MDF}{VPN}{WLAN}{AGENT}
FCS_RBG_EXT.1.3
{MDF}{VPN}{WLAN}{AGENT}
There is no TSS assurance activity for this SFR. A proprietary Entropy Assessment Report (EAR)
has been produced and is on file with NIAP.
FCS_SRV_EXT.1.1 {MDF} There is no TSS assurance activity for this SFR.
FCS_STG_EXT.1.1 {MDF}
FCS_STG_EXT.1.2 {MDF}
FCS_STG_EXT.1.3 {MDF}
FCS_STG_EXT.1.4 {MDF}
FCS_STG_EXT.1.5 {MDF}
Describes that the TOE implements the required secure key storage.
Contains a description of the key storage mechanism that justifies the selection
of “mutable hardware” or “software-based”.
8.3.1 Overview of Key Management
8.4.6, Keychain Data Protection
FCS_STG_EXT.2.1{MDF}{VPN} Includes a key hierarchy description of the protection of each DEK for data-at-
rest, of software-based key storage, of long-term trusted channel keys, and of
KEK related to the protection of the DEKs, long-term trusted channel keys, and
software-based key storage. This description includes a diagram of the hierarchy
implemented by the TOE indicates how the functionality described by
FCS_RBG_EXT.1 is invoked to generate DEKs (FCS_CKM_EXT.2), the key size
(FCS_CKM_EXT.2 and FCS_CKM_EXT.3) for each key, how each KEK is
formed (generated, derived, or combined according to FCS_CKM_EXT.3), the
integrity protection method for each encrypted key (FCS_STG_EXT.3), and the
IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1).
8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
VID: 10937
Page 102 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FCS_STG_EXT.2.1{MDF}{VPN} States in the key hierarchy description in that each DEK and software-stored key
is encrypted according to FCS_STG_EXT.2.
8.3.1 Overview of Key Management
Figure 5: Key Hierarchy in iOS
FCS_STG_EXT.3.1 {MDF}
FCS_STG_EXT.3.2 {MDF}
States in the key hierarchy description that each encrypted key is integrity
protected according to one of the options in FCS_STG_EXT.3.
8.3.1 Overview of Key Management
FCS_STG_EXT.4.1{AGENT} Lists each persistent secret (credential, secret key) and private key needed to
meet the requirements in the ST, for what purpose it is used, and, for each
platform listed as supported in the ST, how it is stored.
States that the Agent calls a platform-provided API to store persistent secrets
and private keys.
8.3.1 Overview of Key Management
8.3.1.1 Password based Key derivation
8.3.2 Storage of Persistent Secrets and Private
Keys by the Agent
FCS_TLSC_EXT.1.1
{MDF}{AGENT}
Provides a description of the implementation of this protocol in the TSS to ensure
that the ciphersuites supported are specified and include those listed for this
component.
8.9.1 EAP-TLS and TLS
FCS_TLSC_EXT.1.2
{MDF} {AGENT}
Describes the client’s method of establishing all reference identifiers from the
application-configured reference identifier, including which types of reference
identifiers are supported and whether IP addresses and wildcards are supported.
Identifies whether and the manner in which certificate pinning is supported or
used by the TOE.
8.9.1 EAP-TLS and TLS
FCS_TLSC_EXT.1.3
{MDF}{AGENT}
There is no TSS assurance activity for this SFR.
FCS_TLSC_EXT.1.4
{MDF}{AGENT}
Describes (for FIA_X509_EXT.2. the use of client-side certificates for TLS mutual
authentication.
8.5.2 Certificates
FCS_TLSC_EXT.1.1 {WLAN}
FCS_TLSC_EXT.1.2 {WLAN}
FCS_TLSC_EXT.1.3 {WLAN}
FCS_TLSC_EXT.1.4 {WLAN}
FCS_TLSC_EXT.1.5 {WLAN}
FCS_TLSC_EXT.1.6 {WLAN}
Describes the implementation of this protocol in the TSS to ensure that the
ciphersuites supported are specified.
The ciphersuites specified include those listed for this component.
8.5.2 Certificates
8.9.1 EAP-TLS and TLS
FCS_TLSC_EXT.2.1 {MDF} Describes the Supported Elliptic Curves Extension and whether the required
behavior is performed by default or may be configured.
8.9.1 EAP-TLS and TLS
VID: 10937
Page 103 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FDP
FDP_ACF_EXT.1.1 {MDF} Lists all system services available for use by an application.
Describes how applications interface with these system services, and the means
by which these system services are protected by the TSF.
Describes which of the following categories each system service falls in:
• No applications are allowed access
• Privileged applications are allowed access
• Applications are allowed access by user authorization
• All applications are allowed access
Describes how privileges are granted to third-party applications.
Describes for both types of privileged applications, how and when the privileges
are verified and how the TSF prevents unprivileged applications from accessing
those services.
Identifies for any services for which the user may grant access, whether the user
is prompted for authorization when the application is installed, or during runtime.
8.4.1 Protection of Files
8.4.2 Application Access to Files
8.4.5 Restricting Applications Access to
Services
FDP_ACF_EXT.1.2 {MDF} Describes which data sharing is permitted between applications, which data
sharing is not permitted, and how disallowed sharing is prevented.
8.4.1 Protection of Files and
8.4.2 Application Access to Files
8.4.5 Restricting Applications Access to
Services
FDP_DAR_EXT.1.1{MDF}
FDP_DAR_EXT.1.2 {MDF}
Indicates which data is protected by the DAR implementation and what data is
considered TSF data. This data includes all protected data.
8.3.1 Overview of Key Management
8.4.6 Keychain Data Protection
Figure 5: Key Hierarchy in iOS
FDP_DAR_EXT.2.1 {MDF} Describes which data stored by the TSF is treated as sensitive.
Describes the mechanism that is provided for applications to use to mark data
and keys as sensitive.
Contains information reflecting how data and keys marked in this manner are
distinguished from data and keys that are not.
8.4.6 Keychain Data Protection
Table 9: Keychain to File-system Mapping
VID: 10937
Page 104 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FDP_DAR_EXT.2.2 {MDF} Describes the process of receiving sensitive data while the device is in a locked
state.
Indicates if sensitive data that may be received in the locked state is treated
differently than sensitive data that cannot be received in the locked state.
Describes the key scheme for encrypting and storing the received data, which
must involve an asymmetric key and must prevent the sensitive data-at-rest from
being decrypted by wiping all key material used to derive or encrypt the data.
8.4.6 Keychain Data Protection
Table 9: Keychain to File-system Mapping
FDP_DAR_EXT.2.3 {MDF} Includes the symmetric encryption keys in the key hierarchy section for (DEKs)
used to encrypt sensitive data.
Includes the protection of any private keys of the asymmetric pairs.
Describes that any private keys that are not wiped and are stored by the TSF are
stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the
REK and password-derived or biometric-unlocked KEK.
8.4.6 Keychain Data Protection
Table 9: Keychain to File-system Mapping
FDP_DAR_EXT.2.4 {MDF} Includes a description of the actions taken by the TSF for the purposes of DAR
upon transitioning to the unlocked state.
Describes that these actions minimally include decrypting all received data using
the asymmetric key scheme and re-encrypting with the symmetric key scheme
used to store data while the device is unlocked.
8.4.6 Keychain Data Protection
Table 9: Keychain to File-system Mapping
FDP_IFC_EXT.1.1 {MDF} Describes the routing of IP traffic through processes on the TSF when a VPN
client is enabled.
Indicates which traffic does not go through the VPN and which traffic does and
that a configuration exists for each baseband protocol in which only the traffic
identified by the ST author as necessary for establishing the VPN connection
(IKE traffic and perhaps HTTPS or DNS traffic) is not encapsulated by the VPN
protocol (IPsec).
Describes any differences in the routing of IP traffic when using any supported
baseband protocols (e.g. Wi-Fi or, LTE).
8.9.4.1 AlwaysOn VPN
VID: 10937
Page 105 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FDP_IFC_EXT.1.1{VPN} Describes the routing of IP traffic through processes on the TSF when a VPN
client is enabled.
Indicates which traffic does not go through the VPN and which traffic does and
that a configuration exists for each baseband protocol in which only the traffic
identified by the ST author as necessary for establishing the VPN connection
(IKE traffic and perhaps HTTPS or DNS traffic) is not encapsulated by the VPN
protocol (IPsec).
Identifies in the TSS section any differences in the routing of IP traffic when using
any supported baseband protocols (e.g. WiFi or, LTE).
8.9.4.1 AlwaysOn VPN
FDP_PBA_EXT.1.1{MDF} Describes the activities that happen during biometric authentication. 8.6.3 Biometric Authentication Factors
FDP_RIP.2.1 {VPN} Describes (for each supported platform) the extent to which the client processes
network packets and addresses the FDP_RIP.2 requirement.
8.2.2 Memory Protection
8.7.5 Domain Isolation
FDP_STG_EXT.1.1 {MDF} Describes the Trust Anchor Database implemented that contain certificates used
to meet the requirements of this PP.
Contains information pertaining to how certificates are loaded into the store, and
how the store is protected from unauthorized access in accordance with the
permissions established in FMT_SMF_EXT.1 and FMT_MOF_EXT.1.1.
8.5.2 Certificates
FDP_UPC_EXT.1.1 {MDF}
FDP_UPC_EXT.1.2 {MDF}
Describes that all protocols listed in the TSS are specified and included in the
requirements in the ST.
8.9 Trusted Path/Channels (FTP)
VID: 10937
Page 106 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FIA
FIA_AFL_EXT.1.1 {MDF}
FIA_AFL_EXT.1.2 {MDF}
FIA_AFL_EXT.1.3 {MDF}
FIA_AFL_EXT.1.4 {MDF}
FIA_AFL_EXT.1.5 {MDF}
FIA_AFL_EXT.1.6 {MDF}
Describes that a value corresponding to the number of unsuccessful
authentication attempts since the last successful authentication is kept for each
Authentication Factor interface.
Describes if and how this value is maintained when the TOE loses power, either
through a graceful powered off or an ungraceful loss of power and that if the
value is not maintained, the interface is after another interface in the boot
sequence for which the value is maintained.
If the TOE supports multiple authentication mechanisms, the description also
includes how the unsuccessful authentication attempts for each mechanism
selected in FIA_UAU.5.1 is handled.
Describes if each authentication mechanism utilizes its own counter or if multiple
authentication mechanisms utilize a shared counter. If multiple authentication
mechanisms utilize a shared counter, the evaluator shall verify that the TSS
describes this interaction.
Describes how the process used to determine if the authentication attempt was
successful and that that the counter would be updated even if power to the
device is cut immediately following notifying the TOE user if the authentication
attempt was successful or not.
8.6.2 Configuration Profiles
8.5 Identification and Authentication (FIA)
FIA_BLT_EXT.1.1 {MDF} Describes when user permission is required for Bluetooth pairing, and that this
description mandates explicit user authorization via manual input for all Bluetooth
pairing, including application use of the Bluetooth trusted channel and situations
where temporary (non-bonded) connections are formed.
8.9.2 Bluetooth
FIA_BLT_EXT.2.1 {MDF} Describes how data transfer of any type is prevented before the Bluetooth pairing
is completed.
Specifically calls out any supported RFCOMM and L2CAP data
transfer mechanisms
8.9.2 Bluetooth
VID: 10937
Page 107 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FIA_BLT_EXT.3.1 {MDF} Describes how Bluetooth connections are maintained such that two devices with
the same Bluetooth device address are not simultaneously connected and such
that the initial connection is not superseded by any following connection
attempts.
8.9.2 Bluetooth
FIA_BLT_EXT.4.1 {MDF} There is no TSS assurance activity for this SFR.
FIA_BMG_EXT.1.1(1)
{MDF}(Touch ID Gen.1)
FIA_BMG_EXT.1.1(2)
{MDF}(Touch ID Gen.2 and
Gen.3)
FIA_BMG_EXT.1.1(3)
{MDF}(Face ID A 11 Bionic)
FIA_BMG_EXT.1.1(4)
{MDF}(Face ID A12 Bionic)
FIA_BMG_EXT.1.1(5)
{MDF}(Face ID A12X Bioinic)
Contains evidence supporting the testing and calculations completed to
determine the FAR and FRR.
Contains evidence of how many imposters were used for testing, whether online
or offline testing was used and if offline testing was completed, evidence
describing the differences between the biometric system used for testing and the
TOE in the evaluated configuration, if any.
Describes how imposters are compared to enrolled users.
8.5.1 Biometric Authentication
Note: Some of the required, related information
has been provided to NIAP in a separate
proprietary ST.
FIA_BMG_EXT.1.2(1)
{MDF}(Touch ID)
FIA_BMG_EXT.1.2(2)
{MDF}(Face ID)
Indicates which SAFAR the TOE is targeting and contains evidence supporting
the calculations, per Appendix H.3, completed to determine the SAFAR.
Contains evidence of how the authentication factors interact, per FIA_UAU.5.2
and FIA_AFL_EXT.1.
Contains the combination(s) of authentication factors needed to meet the
SAFAR, and the number of attempts for each authentication factor the TOE is
configured to allow.
8.5.1 Biometric Authentication
Note: Some of the required, related information
has been provided to NIAP in a separate
proprietary ST.
FIA_BMG_EXT.2.1(1)
{MDF}(Touch ID)
FIA_BMG_EXT.2.1(2)
{MDF}(Face ID)
Describes how the quality of samples used to create the authentication template
at enrollment are verified. As well as the quality standard that the validation
method uses to perform the assessment.
8.5.1.4 Biometric Sample Quality
FIA_BMG_EXT.3.1(1)
{MDF}(Touch ID)
FIA_BMG_EXT.3.1(2)
{MDF}(Face ID)
Describes how the quality of samples used to verify authentication are verified.
As well as the quality standard that the validation method uses to perform the
assessment.
8.5.1.4 Biometric Sample Quality
FIA_BMG_EXT.5.1 {MDF} Describes how the matching algorithm addresses properly formatted templates
with unusual data properties, incorrect syntax, or low quality.
8.5.1.4 Biometric Sample Quality
VID: 10937
Page 108 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FIA_ENR_EXT.2.1 {AGENT} Describes which types of reference identifiers are acceptable and how the
identifier is specified.
8.5.3 MDM Server Reference ID
Table 10: MDM Server Reference Identifiers
FIA_PAE_EXT.1.1 {WLAN} There is no TSS assurance activity for this SFR.
FIA_PMG_EXT.1.1 {MDF} There is no TSS assurance activity for this SFR.
FIA_TRT_EXT.1.1 {MDF} Describes the method by which authentication attempts are not able to be
automated.
Describes either how the TSF disables authentication via external interfaces
(other than the ordinary user interface) or how authentication attempts are
delayed in order to slow automated entry and shall ensure that this delay totals at
least 500 milliseconds over 10 attempts for all authentication mechanisms
selected in FIA_UAU.5.1.
8.5 Identification and Authentication (FIA)
FIA_UAU.5.1 {MDF}
FIA_UAU.5.2 {MDF}
Describes each mechanism provided to support user authentication and the rules
describing how the authentication mechanism(s) provide authentication.
8.5 Identification and Authentication (FIA)
FIA_UAU.6.1(1) {MDF} There is no TSS assurance activity for this SFR.
FIA_UAU.6.1(2) {MDF} There is no TSS assurance activity for this SFR.
FIA_UAU.7.1 {MDF} Describes the means of obscuring the authentication entry, for all authentication
methods specified in FIA_UAU.5.1.
8.5 Identification and Authentication (FIA)
FIA_UAU_EXT.1.1 {MDF} Describes the process for decrypting protected data and keys and that this
process requires the user to enter a Password Authentication Factor and, in
accordance with FCS_CKM_EXT.3, derives a KEK, which is used to protect the
software-based secure key storage and (optionally) DEK(s) for sensitive data, in
accordance with FCS_STG_EXT.2.
8.3.1 Overview of Key Management
FIA_UAU_EXT.2.1 {MDF}
FIA_UAU_EXT.2.2 {MDF}
Describes the actions allowed by unauthorized users in the locked state. 8.5 Identification and Authentication (FIA)
VID: 10937
Page 109 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FIA_X509_EXT.1.1
{MDF} {VPN} {AGENT}
FIA_X509_EXT.1.2
{MDF} {VPN} {AGENT}
Describes where the check of validity of the certificates takes place.
describes the certificate path validation algorithm.
8.5.2 Certificates
FIA_X509_EXT.2.1
{MDF} {VPN} {AGENT}
FIA_X509_EXT.2.2 {MDF}
{VPN} {AGENT}
Describes how the TOE chooses which certificates to use, and any necessary
instructions in the administrative guidance for configuring the operating
environment so that the TOE can use the certificates.
Describes the behavior of the TOE when a connection cannot be established
during the validity check of a certificate used in establishing a trusted channel.
describes any distinctions between trusted channels.
8.5.2 Certificates
FIA_X509_EXT.2.1/WLAN
{WLAN}
Describes how the TOE chooses which certificates to use, and any necessary
instructions in the administrative guidance for configuring the operating
environment so that the TOE can use the certificates.
Describes the behavior of the TOE when a connection cannot be established
during the validity check of a certificate used in establishing a trusted channel.
Describes any distinctions between trusted channels.
8.9.3 Wireless LAN.
FIA_X509_EXT.2.2 {WLAN} See FIA_X509_EXT.2.1 See FIA_X509_EXT.2.1
FIA_X509_EXT.3.1
{MDF} {AGENT}
There is no TSS assurance activity for this SFR.
FIA_X509_EXT.3.2
{MDF} {AGENT}
There is no TSS assurance activity for this SFR.
VID: 10937
Page 110 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FMT
FMT_MOF_EXT.1.1 {MDF} Describes those management functions that may only be performed by the user
and that the TSS does not include an Administrator API for any of these
management functions.
Table 4: Management Functions
FMT_MOF_EXT.1.2 {MDF} Describes those management functions that may be performed by the
Administrator, including how the user is prevented from accessing, performing, or
relaxing the function (if applicable), and how applications/APIs are prevented
from modifying the Administrator configuration.
Describes any functionality that is affected by administrator-configured policy and
how.
Table 4: Management Functions
8.6.2 Configuration Profiles
FMT_POL_EXT.2.1 {AGENT} Describes how the candidate policies are obtained by the MDM Agent; the
processing associated with verifying the digital signature of the policy updates;
and the actions that take place for successful (signature was verified) and
unsuccessful (signature could not be verified) cases.
Identifies the software components that are performing the processing.
8.6.2 Configuration Profiles
FMT_POL_EXT.2.2 {AGENT} See FIA_X509_EXT.1.1 and FIA_X509_EXT.2.1 See FIA_X509_EXT.1.1 & FIA_X509_EXT.2.1
FMT_SMF_EXT.1.1 {MDF} Describes all management functions, what role(s) can perform each function, and
how these functions are (or can be) restricted to the roles identified by
FMT_MOF_EXT.1.
8.6 Specification of Management Functions
(FMT)
Table 4: Management Functions
Function 1:
Defines the allowable policy options: the range of values for both password
length and lifetime, and a description of complexity to include character set and
complexity policies.
8.5 Identification and Authentication (FIA)
8.6.2 Configuration Profiles
Function 2:
Defines the range of values for both timeout period and number of authentication
failures for all supported authentication mechanisms.
8.5 Identification and Authentication (FIA)
8.6.2 Configuration Profiles
Function 3:
There is no TSS assurance activity for this SFR.
VID: 10937
Page 111 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
Function 4:
Describes each radio and an indication of if the radio can be enabled/disabled
along with what role can do so.
Describes the frequency ranges at which each radio operates is included in the
TSS.
8.6.5 Radios
Table 1: Devices Covered by the Evaluation
Table 4: Management Functions
Function 5:
Describes each collection device and an indication of if it can be
enabled/disabled along with what role can do so.
8.6.2 Configuration Profiles
8.6.6 Audio and Visual collection devices
Table 4: Management Functions
Function 6:
There is no TSS assurance activity for this function.
Function 7:
There is no TSS assurance activity for this function.
Function 8:
Describes the allowable application installation policy options based on the
selection included in the ST.
8.6.2 Configuration Profiles
Function 9:
Describes each category of keys/secrets that can be imported into the TSF’s
secure key storage.
8.3.1 Overview of Key Management
Table 6: Summary of keys and persistent
secrets in iOS 12
Function 10:
See Function 9
See Function 9
Function 11:
There is no TSS assurance activity for this function.
Function 12:
Describes each additional category of X.509 certificates and their use within the
TSF.
8.5.2 Certificates
VID: 10937
Page 112 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
Function 13:
Describes each management function that will be enforced by the enterprise
once the device is enrolled.
8.6.2 Configuration Profiles
Function 14:
Indicates which applications can be removed along with what role can do so
8.6.2 Configuration Profiles
Function 15:
There is no TSS assurance activity for this function.
Function 16:
There is no TSS assurance activity for this function.
Function 17:
There is no TSS assurance activity for this function.
Function 18:
Describes the Bluetooth profiles and services supported and the Bluetooth
security modes and levels supported by the TOE.
Describes the method by which the level of security for pairings are managed,
including whether the setting is performed for each pairing or is a global setting.
8.9.2 Bluetooth
Function e), h) and j) are NOT selected.
Function i) is selected.
Function 19:
There is no TSS assurance activity for this function.
Function 22:
There is no TSS assurance activity for this function.
Function 23:
States if the TOE supports a BAF.
Describes the procedure to enable/disable the BAF.
8.6.3 Biometric Authentication Factors
Function 28
There is no TSS assurance activity for this function.
VID: 10937
Page 113 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
Function 30:
There is no TSS assurance activity for this function.
Function 33:
There is no TSS assurance activity for this function.
Function 36:
Describes any restrictions in banner settings.
8.8.3 Lock Screen / Access Banner Display
Function 37:
There is no TSS assurance activity for this function.
Function 45:
Contains guidance to configure the VPN as Always-On.
8.9.4.1 AlwaysOn VPN
FMT_SMF_EXT.1.1/WLAN
{WLAN}
There is no TSS assurance activity for this SFR.
FMT_SMF.1.1/VPN {VPN} Describes the client credentials and how they are used by the TOE. 8.6.7 VPN Certificate Credentials
8.9.4.4 Peer authentication
FMT_SMF_EXT.2.1 {MDF} Describes all available remediation actions, when they are available for use, and
any other administrator-configured triggers, and how the remediation actions are
provided to the administrator.
8.3.1 Overview of Key Management
8.6.4 Unenrollment
FMT_SMF_EXT.3.1 {AGENT} Describes the any assigned functions and that these functions are documented
as supported by the platform.
Lists any differences between management functions and policies for each
supported Mobile Device.
8.6.1 Enrollment
FMT_SMF_EXT.3.2 {AGENT} Describes the methods in which the MDM Agent can be enrolled.
Makes clear if the MDM Agent supports multiple interfaces for enrollment and
configuration.
8.6.1 Enrollment
8.6.4 Unenrollment
FMT_UNR_EXT.1.1 {AGENT} Describes the mechanism used to prevent users from unenrolling or the
remediation actions applied when unenrolled.
8.6.4 Unenrollment
VID: 10937
Page 114 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT
FPT_AEX_EXT.1.1 {MDF}
FPT_AEX_EXT.1.2 {MDF}
Describes how the 8 bits are generated and provides a justification as to why
those bits are unpredictable.
8.7.5 Domain Isolation
FPT_AEX_EXT.2.1 {MDF} Describes of the memory management unit (MMU), and documents the ability of
the MMU to enforce read, write, and execute permissions on all pages of virtual
memory.
8.7.5 Domain Isolation
FPT_AEX_EXT.3.1 {MDF} Describes the stack-based buffer overflow protections implemented in the TSF
software which runs in the non-privileged execution mode of the application
processor.
Contains an inventory of TSF binaries and libraries, indicating those that
implement stack-based buffer overflow protections as well as those that do not.
provides a rationale for those binaries and libraries that are not protected in this
manner.
8.7.5 Domain Isolation
8.11 Inventory of TSF binaries and libraries
Note: The inventory is considered proprietary
and has been provided to NIAP in a separate
proprietary ST.
FPT_AEX_EXT.4.1 {MDF}
FPT_AEX_EXT.4.2 {MDF}
Describes the mechanisms that are in place that prevents non-TSF software from
modifying the TSF software or TSF data that governs the behavior of the TSF.
Describes how the TSF ensures that the address spaces of applications are kept
separate from one another.
If no USSD or MMI codes are available, description of the method by which
actions prescribed by these codes are prevented.
Documents any TSF data which may be accessed and modified over a wired
interface in auxiliary boot modes.
Describes data, which is modified in support of update or restore of the device.
Describes the means by which unauthorized and undetected modification (that is,
excluding cryptographically verified updates per FPT_TUD_EXT.2) of the TSF
data over the wired interface in auxiliary boots modes is prevented.
8.7.5 Domain Isolation
VID: 10937
Page 115 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT_JTA_EXT.1.1 {MDF} Explains the location of the JTAG ports on the TSF, to include the order of the
ports (i.e. Data In, Data Out, Clock, etc.).
Describes how access to the JTAG is controlled by a signing key.
Describes when the JTAG can be accessed, i.e. what has the access to the
signing key.
8.7.2 Joint Test Action Group (JTAG)
Disablement
FPT_KST_EXT.1.1 {MDF} Contains a description of the activities that happen on power-up and password
authentication relating to the decryption of DEKs, stored keys, and data.
Describes how the cryptographic functions in the FCS requirements are being
used to perform the encryption functions, including how the KEKs, DEKs, and
stored keys are unwrapped, saved, and used by the TOE so as to prevent
plaintext from being written to non-volatile storage.
Describes, for each power-down scenario how the TOE ensures that all keys in
non-volatile storage are not stored in plaintext.
Describes how other functions available in the system ensure that no
unencrypted key material is present in persistent storage.
Describes that key material is not written unencrypted to the persistent storage.
For each BAF selected in FIA_UAU.5.1, describes the activities that happen on
biometric authentication, relating to the decryption of DEKs, stored keys, and
data. In addition, how the system ensures that the biometric keying material is
not stored unencrypted in persistent storage.
8 TOE Summary Specification (TSS)
8.3.1 Overview of Key Management
8.2.1 The Secure Enclave
VID: 10937
Page 116 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT_KST_EXT.2.1 {MDF} Describes the TOE security boundary.
Contains a description of the activities that happen on power-up and password
authentication relating to the decryption of DEKs, stored keys, and data.
Describes how other functions available in the system ensure that no
unencrypted key material is transmitted outside the security boundary of the
TOE.
Describes that key material is not transmitted outside the security boundary of
the TOE.
For each BAF selected in FIA_UAU.5.1 contains a description of the activities
that happen on biometric authentication, including how any plaintext material,
including critical security parameters and results of biometric algorithms, are
protected and accessed.
Describes how functions available in the biometric algorithms ensure that no
unencrypted plaintext material, including critical security parameters and
intermediate results, is transmitted outside the security boundary of the TOE or to
other functions or systems that transmit information outside the security
boundary of the TOE.
8 TOE Summary Specification (TSS)
8.3.1 Overview of Key Management
8.2.1 The Secure Enclave
FPT_KST_EXT.3.1 {MDF} Provides a statement of their policy for handling and protecting keys.
Describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys
stored in the secure key storage.
8.2.1 The Secure Enclave
FPT_NOT_EXT.1.1{MDF} Describes critical failures that may occur and the actions to be taken upon these
critical failures.
8.7.9 Self-Tests
FPT_STM.1.1{MDF} Lists each security function that makes use of time.
Describes how the time is maintained and considered reliable in the context of
each of the time related functions.
Identifies whether the TSF uses a NTP server or the carrier’s network time as the
primary time sources.
8.7.7 Time
VID: 10937
Page 117 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT_TST_EXT.1.1
{MDF} {AGENT}
Specifies the self-tests that are performed at start-up. This description must
include an outline of the test procedures conducted by the TSF.
Includes any error states that they TSF may enter when self-tests fail, and the
conditions and actions necessary to exit the error states and resume normal
operation
Indicates these self-tests are run at start-up automatically, and do not involve any
inputs from or actions by the user or operator.
The self-tests includes algorithm self-tests. The algorithm self-tests will typically
be conducted using known answer tests.
8.7.9 Self-Tests
FPT_TST_EXT.1.1 /VPN {VPN}
FPT_TST_EXT.1.2 {VPN}
Details the self-tests that are run by the TSF on start-up; this description includes
an outline of what the tests are actually doing makes an argument that the tests
are sufficient to demonstrate that the TSF is operating correctly.
Identifies and describes any of the tests that are performed by the TOE platform,
describes how the integrity of stored TSF executable code is cryptographically
verified when it is loaded for execution.
Makes an argument that the tests are sufficient to demonstrate that the integrity
of stored TSF executable code has not been compromised.
Describes the actions that take place for successful (e.g. hash verified) and
unsuccessful (e.g., hash not verified) cases.
8.7.9 Self-Tests describes in detail the self-tests
that are run by the TSF on start-up
VID: 10937
Page 118 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT_TST_EXT.1.1 {WLAN}
FPT_TST_EXT.1.2 {WLAN}
Details the self-tests that are run by the TSF on start-up; this description includes
an outline of what the tests are actually doing (e.g., rather than saying "memory
is tested", a description similar to "memory is tested by writing a value to each
memory location and reading it back to ensure it is identical to what was written"
shall be used).
Makes an argument that the tests are sufficient to demonstrate that the TSF is
operating correctly.
Describes how to verify the integrity of stored TSF executable code when it is
loaded for execution.
Makes an argument that the tests are sufficient to demonstrate that the integrity
of stored TSF executable code has not been compromised. The evaluator also
ensures that the TSS (or the operational guidance) describes the actions that
take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not
verified) cases.
8.7.9 Self-Tests
FPT_TST_EXT.2.1(1) {MDF}
FPT_TST_EXT.3.1 {MDF}
Describes the boot procedures, including a description of the entire bootchain, of
the software for the TSF’s Application Processor.
Describes that before loading the bootloader(s) for the operating system and the
kernel, all bootloaders and the kernel software itself is cryptographically verified.
For each additional category of executable code verified before execution,
describes how that software is cryptographically verified.
Contains a justification for the protection of the cryptographic key or hash,
preventing it from being modified by unverified or unauthenticated software.
Describes the protection afforded to the mechanism performing the cryptographic
verification.
8.7.1 Secure Boot
FPT_TUD_EXT.1.1 {MDF}{VPN}
FPT_TUD_EXT.1.2 {MDF}{VPN}
FPT_TUD_EXT.1.3 {MDF}{VPN}
There is no TSS assurance activity for this SFR.
VID: 10937
Page 119 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FPT_TUD_EXT.2.1 {MDF}
FPT_TUD_EXT.2.2 {MDF}
FPT_TUD_EXT.2.3 {MDF}
Describes all TSF software update mechanisms for updating the system
software.
Includes a description of the digital signature verification of the software before
installation and that installation fails if the verification fails.
All software and firmware involved in updating the TSF is described and, if
multiple stages and software are indicated, that the software/firmware
responsible for each stage is indicated and that the stage(s) which perform
signature verification of the update are identified.
Describes the method by which the digital signature is verified and that the public
key used to verify the signature is either hardware-protected or is validated to
chain to a public key in the Trust Anchor Database.
If hardware-protection is selected, the method of hardware-protection is
described and the justification why the public key may not be modified by
unauthorized parties.
Describes that software updates to system software running on other processors
(The SEP) is verified, the evaluator shall verify that these other processors are
listed in the TSS and that the description includes the software update
mechanism for these processors, if different than the update.
8.7.3 Secure Software Update
FPT_TUD_EXT.2.4 {MDF} Describes how mobile application software is verified at installation and uses a
digital signature
8.7.3 Secure Software Update
FPT_TUD_EXT.3.1 {MDF} See FPT_TUD_EXT.2.3 and FPT_TUD_EXT.4.1 See FPT_TUD_EXT.2.3 & FPT_TUD_EXT.4.1
FPT_TUD_EXT.4.1 {MDF} Describes how mobile application software is verified at installation using a digital
signature by a code signing certificate.
8.5.2 Certificates.
FPT_TUD_EXT.4.2 {MDF} Describes the mechanism that prevents the TSF from installing software updates
that are an older version that the currently installed version.
8.7.3 Secure Software Update
VID: 10937
Page 120 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FTA
FTA_SSL_EXT.1.1 {MDF}
FTA_SSL_EXT.1.2 {MDF}
FTA_SSL_EXT.1.3 {MDF}
Describes the actions performed upon transitioning to the locked state.
Describes the information allowed to be displayed to unauthorized users.
8.7.6 Device Locking
8.6.2 Configuration Profiles
8.3.1 Overview of Key Management
FTA_TAB.1.1 {MDF} Describes when the banner is displayed. 8.8.3 Lock Screen / Access Banner Display
FTA_WSE_EXT.1.1 {WLAN} Specifically defines all of the attributes that can be used to specify acceptable
networks (access points).
8.8.2 Restricting Access to Wireless Networks
VID: 10937
Page 121 of 172 © 2019 Apple Inc. Version: 1.6
SFR TSS Requirements from Assurance Activities TSS Section /Reference
FTP
FTP_ITC_EXT.1.1(1) {VPN}
FTP_ITC_EXT.1.2(1) {VPN}
FTP_ITC_EXT.1.3(1) {VPN}
Describes the details of the TOE connecting to access points, VPN Gateways,
and other trusted IT products in terms of the cryptographic protocols specified in
the requirement, along with TOE-specific options or procedures that might not be
reflected in the specifications.
All protocols listed in the TSS are specified and included in the requirements in
the ST.
If OTA updates are selected, the TSS shall describe which trusted channel
protocol is initiated by the TOE and is used for updates.
Table 14: Protocols used for trusted channels
8.7.3 Secure Software Update.
FTP_ITC_EXT.1.1(2)
{AGENT} {MDF}
FTP_ITC_EXT.1.2(2)
{AGENT} {MDF}
FTP_ITC_EXT.1.3(2)
{AGENT} {MDF}
The TSS indicates the methods of Agent-Server communication along with how
those communications are protected.
Describes that all protocols listed in the TSS in support of remote TOE
administration are consistent with those specified in the requirement, and are
included in the requirements in the ST.
8.5.2 Certificates
8.5.3 MDM Server Reference ID
FTP_ITC_EXT.1.1/WLAN (3)
{WLAN}
FTP_ITC_EXT.1.2/WLAN (3)
{WLAN}
Describes the details of the TOE connecting to an access point in terms of the
cryptographic protocols specified in the requirement, along with TOE-specific
options or procedures that might not be reflected in the specification.
All protocols listed in the TSS are specified and included in the requirements in
the ST.
8.9.3 Wireless LAN
8.9.1 EAP-TLS and TLS
Table 5: Mapping of SFR Assurance Activities to the TSS
VID: 10937
Page 122 of 172 © 2019 Apple Inc. Version: 1.6
8.2 Hardware Protection Functions
8.2.1 The Secure Enclave
The Secure Enclave is a coprocessor fabricated in the Apple A8, A8X, A9, A9X, A10 Fusion,
A10X Fusion, A11 Bionic, A12 Bionic, and A12X Bionic processors. It utilizes its own secure
boot and personalized software update separate from the application processor. It provides
all cryptographic operations for Data Protection key management and maintains the integrity
of Data Protection even if the kernel has been compromised.
The Secure Enclave uses encrypted memory and includes a hardware random number
generator. Its microkernel is based on the L4 family, a second-generation microkernel
generally used to implement UNIX-like operating systems, with modifications by Apple.
Communication between the Secure Enclave and the application processor is isolated to an
interrupt-driven mailbox and shared memory data buffers. Note that only a small dedicated
amount of memory used for communication between the secure enclave and the main system
is shared. The main system has no access to other memory areas of the secure enclave and
no keys or key material may be exported.
Each Secure Enclave is provisioned during fabrication with its own Unique ID (UID) that is not
accessible to other parts of the system and is not known to Apple. When the device starts up,
an ephemeral key is created, entangled with its UID, and used to encrypt the Secure
Enclave’s portion of the device’s memory space.
Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a
key entangled with the UID and an anti-replay counter.
The UID also serves as the REK for the whole device.
In addition to the UID also the Group Key (GID) and Apple's root certificate are provisioned
during manufacturing. The GID is only unique per device type and is used in the secure
software update process. Apple's root certificate is used to verify the integrity and authenticity
of software during the secure boot process and for updates of the system software.
The Secure Enclave has its own physical noise source and random number generator which
is used for generating the salt value for the password-based key generation function
(PBKDF), which uses AES with the device UID as the key for the pseudorandom function
(PRF). The counter is calculated such that it takes between 100 and 150 milliseconds to
execute the function. While the counter value therefore may vary per device type, it is larger
than 10,000 for each device type. The salt (128 bit) is regenerated every time the passcode
changes. The salt value is stored AES encrypted with the UID in the system keybag.
Other salt values used for functions in iOS are generated using the True Random Number
Generator (TRNG) of the application processor. This includes nonces used in the generation
of DSA signatures as well as nonces required for the Wi-Fi and TLS protocol.
8.2.2 Memory Protection
iOS uses the read and write protection for memory pages provided by the advanced Reduced
Instruction Set (RISC) machine (ARM) processor for separating applications from the kernel
and to provide a sandbox for each application.
Further protection is provided by iOS using ARM’s Execute Never (XN) feature, which marks
memory pages as non-executable. Memory pages marked as both writable and executable
can be used only by apps under tightly controlled conditions: the kernel checks for the
presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap
call can be made to request an executable and writable page, which is given a randomized
address.
VID: 10937
Page 123 of 172 © 2019 Apple Inc. Version: 1.6
8.3 Cryptographic Support
8.3.1 Overview of Key Management
Each TOE comes with a unique 256-bit AES key called the UID. This key is stored in the
Secure Enclave and is not accessible by the "regular" processor. Even the software in the
Secure Enclave cannot read the UID. It can only request encryption and decryption
operations performed by a dedicated AES engine accessible only from the Secure Enclave.
For processors up to and including the A8/A8X processor the UID itself is generated outside
of the device in the production environment using a protected system with a random number
generator that complies with the requirements of NIST Special Publication 800-90A and is
seeded appropriately. (See FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 for the random
number generator used to generate the REK). For later processors the UID is generated
during production using the hardware SP800-90A DRBG of the TOE CPU.
The UID is used to derive two other keys, called "key 0x89B" and "key 0x835". These two
keys are derived during the first boot by encrypting defined constants with the UID. “key
0x89B" and "key 0x835” are used to wrap two other keys: the "EMF key" (the file system
master key, wrapped by "key 0x89B") and the "DKey" (the device key, wrapped by "key
0x835") in accordance with the requirements of NIST SP 800-38F.
Both the “EMF key” and the “Dkey” are stored in block 0 of the flash memory, which is also
called the "effaceable storage.” This area of flash memory can be wiped very quickly. Both
the “EMF key” and the “Dkey” are generated using the random number generator of the
secure enclave (used to seed the CTR_DRBG) when iOS is first installed or after the device
has been wiped.
With the exception of the UIDs for processors up to and including the A8/A8X, all keys are
generated using an internal entropy source, seeding a deterministic random number
generator (DRNG) (CTR_DRBG). System entropy is generated from timing variations during
boot, and additionally from interrupt timing once the device has booted. Keys generated
inside the Secure Enclave use its true hardware random number generator based on multiple
ring oscillators used to seed the CTR_DRBG.
The EMF key is used as a master key used for the encryption of file system metadata. The
EMF key is generated using the random number generator of the secure enclave when iOS is
first installed or after the device has been wiped. Also, all class keys are generated in the
secure enclave and passed to the iOS kernel in wrapped form only.
The Dkey is used within the key hierarchy to directly wrap the class keys that can be used
when the device is locked. For class keys that can only be used when the device is unlocked
the class keys are wrapped with the XOR of the DKey and the passcode key.
Every time a file on the data partition is created, a new 256-bit AES key (the "per-file" key) is
created using the hardware random number generator of the secure enclave. Files are
encrypted using this key with AES in cipher block chaining (CBC) mode where the
initialization vector (IV) is calculated with the block offset into the file, encrypted with the
secure hash algorithm (SHA)-1 hash of the per-file key. (FCS_RBG_EXT.1 for the data
encryption keys).
Each per-file key is wrapped (in the secure enclave) with the class key of the file's class and
then stored in the metadata of the file. Key wrapping uses AES key wrapping per RFC 3394.
Class keys themselves are wrapped either with device key only (for the class
NSFileProtectionNone) or are wrapped with a key derived from the device key and the
passcode key using XOR. This key wrapping is also performed within the secure enclave.
Each file belongs to one of the following classes with its associated class key.
NSFileProtectionComplete
The class key is protected with a key derived from the user passcode and the device UID.
Shortly after the user locks a device (10 seconds, if the "Require Password" setting is
'Immediately'), the decrypted class key is erased, rendering all data in this class inaccessible
until the user enters the passcode again.
VID: 10937
Page 124 of 172 © 2019 Apple Inc. Version: 1.6
NSFileProtectionCompleteUnlessOpen
Some files may need to be written while the device is locked. A good example of this is a mail
attachment downloading in the background. This behavior is achieved by using asymmetric
elliptic curve cryptography (ECDH over Curve25519). iOS implements this by generating a
device-wide asymmetric key pair and then protects the private key of this pair by encrypting it
with the class key for the NSFileProtectionCompleteUnlessOpen class. Note that this class
key can only be unwrapped when the device is unlocked since it requires the passcode to be
entered which then is used in the key derivation function (KDF) for that generates the key
encryption key (KEK) for this class key as described above. The device-wide asymmetric key
pair is generated within the secure enclave.
When receiving data to be protected when the device is in the locked state, the application
can create a file with the file attribute NSFileProtectionCompleteUnlessOpen. In this case iOS
generates another asymmetric key pair within the secure enclave (per file object used to store
the data). The device-wide public key and the file object private key are then used to generate
a shared secret (using one-pass DH (Diffie-Hellman) as described in NIST SP 800-56A). The
KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1
of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral
and static public keys, respectively. SHA-256 is used as the hashing function. The key
generated in that fashion is used as the symmetric key to encrypt the data. The object private
key and the shared secret are cleared when the file is closed and only the object public key is
stored with the file object.
To read the file, the per file object shared secret is regenerated using the device-wide private
key and the per file object public key.
Unwrapping of the device-wide private key can only be performed when the correct passcode
has been entered, since the device-wide private key is wrapped with a key that can only be
unwrapped with a class key that itself can only be unwrapped when the passcode is
available. The guidance given in section D.3.3 of MDFPP Version 3 allows a key agreement
scheme to be used. The key agreement scheme implemented uses elliptic curve Diffie
Hellman (ECDH) over Curve25519. When the correct passcode has been entered, the files
with sensitive data received while the device was in the locked state get the per-file key re-
wrapped with the NSFileProtectionCompleteUnlessOpenclass key. It is up to the application
to check when the device is unlocked and then cause iOS to re-wrap the file encryption key
with the class key for the NSFileProtectionComplete class by changing the file's
NSFileProtectionKey attribute to NSFileProtectionComplete.
Protected Until First User Authentication
This class behaves in the same way as Complete Protection, except that the decrypted class
key is not removed from memory when the device is locked. The protection in this class has
similar properties to desktop full-volume encryption and protects data from attacks that
involve a reboot. This is the default class for all third-party app data not otherwise assigned to
a Data Protection class.
NSFileProtectionNone
This class key is wrapped only with the device key and is kept in Effaceable Storage. Since
all the keys needed to decrypt files in this class are stored on the device, the encryption only
affords the benefit of fast remote wipe. If a file is not assigned a Data Protection class, it is
still stored in encrypted form (as is all data on an iOS device).
Keychain data is protected using a class structure similar to the one used for files. Those
classes have behaviors equivalent to the file Data Protection classes but use distinct keys.
In addition, there are Keychain classes with the additional extension "ThisDeviceOnly". Class
keys for those classes are wrapped with a key that is also derived from the Device Key which,
when copied from a device during backup and restored on a different device, will make them
useless.
The keys for both file and Keychain Data Protection classes are collected and managed in
keybags. iOS uses the following four keybags: system, backup, escrow, and iCloudBackup.
The keys are stored in the System keybag and some keys are stored in the Escrow keybag,
VID: 10937
Page 125 of 172 © 2019 Apple Inc. Version: 1.6
which are used for device update and by MDM, are relevant for functions defined in
[PP_MD_V3.1].
The system keybag is where the wrapped class keys used in normal operation of the device
are stored. For example, when a passcode or biometric authentication factor is entered, the
NSFileProtectionComplete key is loaded from the system keybag and unwrapped. It is a
binary plist stored in the No Protection class, but whose contents are encrypted with a key
held in Effaceable Storage. In order to give forward security to keybags, this key is wiped and
regenerated each time a user changes their passcode.
The AppleKeyStore kernel extension manages the system keybag and can be queried
regarding a device’s lock state. It reports that the device is unlocked only if all the class keys
in the system keybag are accessible and have been unwrapped successfully.
Table 6: Summary of keys and persistent secrets in iOS 12, summarizes the storage for keys
in persistent storage.
Key / Persistent Secret Purpose Storage
(for all devices)
UID REK for device
Key entanglement
Secure enclave
Salt (128 bit) Additional input to one
way functions
AES encrypted in the
system keybag
key 0x89B Wrapping of EMF key Block 0 of the flash
memory. (Effaceable
storage.)
Secure enclave
key 0x835 Wrapping of DKey Block 0 of the flash
memory. (Effaceable
storage.)
Secure enclave
EMF key A master key used for
the encryption of file
system metadata
Stored in wrapped
form in persistent
storage
NSFileProtectionCompleteUnlessOpen
device-wide asymmetric key pair
Writing files while the
device is locked
Stored in wrapped
form in Persistent
storage
CompleteUntilFirstUserAuthentication Stored in wrapped
form in persistent
storage
NSFileProtectionCompleteUnlessOpen Writing files while the
device is locked: KDF
static public keys
Stored in wrapped
form in persistent
storage
AfterFirstUnlock Stored in wrapped
form in persistent
storage
AfterFirstUnlockThisDeviceOnly Stored in wrapped
form in persistent
storage
WhenUnlocked Stored in wrapped
form in persistent
storage
WhenUnlockedThisDeviceOnly Stored in wrapped
form in persistent
storage
Dkey Stored in wrapped
form in persistent
storage
NSFileProtectionNone Stored in wrapped
form in persistent
storage
VID: 10937
Page 126 of 172 © 2019 Apple Inc. Version: 1.6
Key / Persistent Secret Purpose Storage
(for all devices)
NSFileProtectionComplete class key User device lock Stored in wrapped
form in persistent
storage
Individual keys for files and Keychains Stored in wrapped
form in persistent
storage
Biometric templates (Touch ID and Face
ID)
Stored in wrapped
form in persistent
storage
DH Group parameters Used as part of
IKE/IPsec key
establishment
RAM
User IPsec X.509v3 Certificate Keys Used to authenticate
IKE/IPsec sessions
Persistently stored
encrypted in the
platform key chain
CA IPsec X.509v3 Certificate Public Keys Persistently stored
encrypted in the
platform key chain
IKEv2 IKE_SA Encryption Keys Used to encrypt
IKE/IPsec traffic
RAM
IKEv2 IKE_SA Integrity Keys Used to verify the
integrity of IKE/IPsec
traffic.
RAM
IKEv2 CHILD_SA Encryption Keys Used to encrypt
IKE/IPsec traffic
RAM
IKEv2 CHILD_SA Integrity Keys Used to verify the
integrity of IKE/IPsec
traffic.
RAM
Table 6: Summary of keys and persistent secrets in iOS 12
8.3.1.1 Password based key derivation
The TOE implements PBKDF2 to derive a key from a user's passcode. The derived key is
256 bits in size. After the PBKDF2 operation, the derived key is entangled with the device's
hardware UID key to form the root encryption key used to unwrap the user keybag holding the
class keys for the file system data protection. Only when the unwrapping of the user keybag
is successful, the user is considered authenticated.
The PBKDF2 is implemented as specified in SP800-132 following option 2.b. defined in
section 5.4 of the standard. The password is inserted directly into the PBKDF2 function
without any pre-processing. The PBKDF2 implementation uses HMAC SHA-256 as core.
The Password-based key derivation is performed using a minimum of 50,000 iterations.
Note: The number of iterations is calibrated to take at least 100 to 150 milliseconds and is a
minimum of 50,000. The number of iterations may be greater in some devices.
8.3.2 Storage of Persistent Secrets and Private Keys by the Agent
The MD (Mobile Device) Agent calls the Apple iOS API on the device in order to store keys
and persistent secrets in the Keychain; which are therefore stored in wrapped form in
persistent storage, as described above.
Table 7: Summary of keys and persistent secrets used by the Agent, summarizes the keys
and persistent secrets stored for the Agent. They are used on all devices listed in this [ST].
VID: 10937
Page 127 of 172 © 2019 Apple Inc. Version: 1.6
Key /
Persistent
Secret
Purpose Storage
(for all devices)
TLS keys Protecting MDM Protocol
communications with the MDM
Server
Stored on the device in wrapped form
in persistent storage
Device Push
Token
The device push token is received
when registering with the Apple Push
Notification Service (APNS) in order
to have an unambiguous identifier in
APNS.
The token is not stored on the device
but sent to the MDM server. The
MDM server stores it to be able to
contact the device.
UDID Unique Device ID Stored in wrapped form in persistent
storage
PushMagic The magic string that must be
included in the push notification
message. This value is generated by
the device.
Stored in wrapped form in persistent
storage
Device identity
certificate
The device presents its identity
certificate for authentication when it
connects to the check-in server.
Stored in wrapped form in persistent
storage
Certificate
Payload
https://developer.apple.com/library/io
s/featuredarticles/iPhoneConfiguratio
nProfileRef/Introduction/Introduction.
html#//apple_ref/doc/uid/TP4001020
6-CH1-SW248
Stored in wrapped form in persistent
storage
Profile
encryption key
A profile can be encrypted so that it
can only be decrypted using a private
key previously installed on a device.
Stored in wrapped form in persistent
storage
GUID Volume Purchase Program (VPP)
Account Protection
A random UUID should be standard
8-4-4-4-12 formatted UUID string and
must be unique for each installation
of your product
Stored in wrapped form in persistent
storage
Table 7: Summary of keys and persistent secrets used by the Agent
VID: 10937
Page 128 of 172 © 2019 Apple Inc. Version: 1.6
Figure 5: Key Hierarchy in iOS, provides an overview on the key management hierarchy
implemented in iOS.
Figure 5: Key Hierarchy in iOS
The Data Protection API can be used by applications to define the class a new file belongs to
by using the NSFileProtectionKey attribute and setting its value to one of the classes
described above. When the device is locked, a new file can only be created in the classes
NSFileProtectionNone and NSFileProtectionCompleteUnlessOpen.
Note that the UID is not accessible by any software and that the two keys 'Key 0x89B' and
'Key 0x835' are both derived by encrypting defined values (identical for all devices) with the
UID. Both are stored in the Secure Enclave. All other keys shown in the figure are stored in
wrapped form in persistent storage and unwrapped when needed.
To summarize:
VID: 10937
Page 129 of 172 © 2019 Apple Inc. Version: 1.6
• All keys are managed and maintained in the Secure Enclave Processor, a dedicated
execution environment with its own operating system that is completely separated from
iOS. Both can interact with each other using a mailbox system detailed in section 8.2.1.
• All file system items and all key chain items are stored in encrypted form only.
• File system metadata is encrypted using the EMF key.
• Files and key chain items are encrypted with individual keys. Those keys are wrapped
with the class key of the class, the file, or the Keychain to which the item belongs.
• Files and key chain items belonging to the classes 'NSFileProtectionNone' (files) and
'Always' or 'AlwaysThisDeviceOnly' are encrypted with keys that are wrapped with the
Dkey only. Those items can be accessed (decrypted) before the user is authenticated.
For all other classes the passcode key (which is derived from the user's passcode) is
used in the generation of the wrapping key used for those classes and therefore
decrypting those items is only possible when the user has correctly entered his
passphrase.
• All decryption errors are handled in compliance with NIST Special Publication 800-56B.
• When a wipe command is issued, protected data is wiped by erasing the top level
KEKs. Since all data-at-rest is encrypted with one of those keys, the device is wiped.
iOS performs the following activities to protect the keys used for file encryption.
Every time the TOE is booted, the TOE does the following.
• An ephemeral AES key (256 bit) is created in the secure enclave using the random
number generator of the secure enclave.
• The (wrapped) Dkey and (wrapped) EMF key (both 256-bit keys) are loaded by the iOS
kernel from the effaceable storage and sent to the secure enclave.
• The secure enclave unwraps the Dkey and the EMF key.
• The secure enclave wraps the Dkey with the newly generated ephemeral key.
• The secure enclave stores the ephemeral key in the storage controller. This area is not
accessible by the iOS kernel.
When iOS accesses a file, the following operations are performed.
• The iOS kernel first extracts the file metadata (which are encrypted with the EMF key)
and sends them to the secure enclave.
• The secure enclave decrypts the file metadata and sends it back to the iOS kernel.
• The iOS kernel determines which class key to use and sends the class key (which is
wrapped with the Dkey, or with the XOR of the Dkey and the Passcode Key) and the
file key (which is wrapped with the class key) to the secure enclave.
• The secure enclave unwraps the file key and re-wraps it with the ephemeral key and
sends this wrapped key back to the iOS kernel.
• The iOS kernel sends the file access request (read or write) together with the wrapped
file key to the storage controller.
• The storage controller uses its internal implementation of AES, decrypts the file key,
and then decrypts (when the operation is read) or encrypts (when the operation is write)
the data during its transfer from/to the flash memory.
The following summarize the storage location for key material.
• The UID is stored in the firmware of the secure enclave in a section not accessible by
any program in the secure enclave or the main processor. The processor in the secure
enclave can only be used to encrypt and decrypt data (using AES256) using the UID as
a key.
• Keys 0x89B and 0x835 are stored in the secure enclave.
VID: 10937
Page 130 of 172 © 2019 Apple Inc. Version: 1.6
• The EMF key, Dkey and the class keys are stored in the effaceable area, all in wrapped
form only. As explained, they are never available in clear in the main processor system.
• File keys and Keychain item keys are stored in non-volatile memory, but in wrapped
form only. As explained they are never available in the clear in the main processor
system.
• The system and the applications can store private keys in Keychain items. They are
protected by the encryption of the Keychain item.
• Symmetric keys used for TLS, HTTPS, or Wi-Fi sessions are held in RAM only. They
are generated and managed using one of the two libraries, Apple CoreCrypto Kernel
Cryptographic Module for ARM and Apple CoreCrypto Cryptographic Module for ARM,
or by the AES implementation within the Wi-Fi chip. The functions of those libraries,
such as memset (0), also perform the clearing of those keys after use.
VID: 10937
Page 131 of 172 © 2019 Apple Inc. Version: 1.6
8.3.3 Randomness extraction step
“Concatenating the keys and using a KDF (as described in (SP 800- 56C)” is selected in
FCS_CKM_EXT.3 Extended: Cryptographic Key Generation.
The TOE implements the KDF following the specification in RFC 5869. The KDF defined in
this RFC complies with the extraction and expansion KDFs specified in SP800-56C. This
RFC exactly specifies the order of the concatenation of the input data used for the extraction
steps as well as the data concatenation and the counter maintenance of the expansion
phase.
Extraction
HKDF-Extract(salt, IKM) -> PRK
Options:
Hash a hash function; HashLen denotes the length
of the hash function output in octets
Inputs:
salt optional salt value (a non-secret random
value);
if not provided, it is set to a string of
HashLen zeros.
IKM input keying material
Output:
PRK a pseudorandom key (of HashLen octets
The output PRK is calculated as follows:
PRK = HMAC-Hash(salt, IKM)
Expansion
HKDF-Expand(PRK, info, L) -> OKM
Options:
Hash a hash function; HashLen denotes the length
of the hash function output in octets
Inputs:
PRK a pseudorandom key of at least HashLen octets
(usually, the output from the extract step)
info optional context and application specific
information
(can be a zero-length string)
L length of output keying material in octets
(<= 255*HashLen)
VID: 10937
Page 132 of 172 © 2019 Apple Inc. Version: 1.6
Output:
OKM output keying material (of L octets)
The output OKM is calculated as follows:
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
where:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...
(where the constant concatenated to the end of each T(n)
is a single octet.)
The implementation of the KDF uses HMAC SHA-256 for both the extraction as well as the
expansion phase.
The salt length as well as the output key length of the KDF are 256 bits, which in every case
is larger than the parameters given in tables 1-3 of SP 800-56C.
VID: 10937
Page 133 of 172 © 2019 Apple Inc. Version: 1.6
8.3.4 Explanation of usage for cryptographic functions
Table 8: Explanation of usage for cryptographic functions below, enumerates the various cryptographic
functions specified in the SFRs and maps them to their implementation.
VID: 10937
SFR Cryptographic
Function
Algorithm Modes / Notes Key/Curve sizeImplementation Module
FCS_CKM.1(1)
Cryptographic
Key
Generation Asymmetric key pair
generation
RSA KeyGen
[FIPS 186-4]
2048-bit,
3072-bit
Generic Apple CoreCrypto User
Space
ECDSA KeyGen
[FIPS 186-4]
Note: Curve 25519 cannot
be CAVS tested.
P-256,
P-384,
Curve25519
Generic Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
DSA KeyGen
[FIPS 186-4]
2048-bit Generic Apple CoreCrypto User
Space
FCS_CKM.1/VPN
Asymmetric key pair
generation
RSA KeyGen
[FIPS 186-4]
2048-bit,
3072-bit
Generic Apple CoreCrypto User
Space
ECDSA KeyGen
[FIPS 186-4]
P-256,
P-384
Generic Apple CoreCrypto User
Space
FCS_CKM.2(1)
Key establishment RSA
[SP 800-56B]
Note: This is not CAVS
tested since it is not yet
supported by the CAVS tool.
Apple CoreCrypto User
Space
ECC Key Establishment
(KAS-ECC)
[SP800-56A]
P-256,
P-384
Generic Apple CoreCrypto User
Space
Apple SEP SKS
FFC Key Establishment
(KAS-FFC)
[SP800-56A]
Generic Apple CoreCrypto User
Space
VID: 10937
SFR Cryptographic
Function
Algorithm Modes / Notes Key/Curve sizeImplementation Module
FCS_CKM.2(2)
Key establishment RFC 7748 The curves specified in
RFC7748 are not NIST
approved and cannot be
tested using the CAVS tool.
Curve25519 Apple SEP SKS
FCS_COP.1(1)
Symmetric
encryption/decryption
AES
[FIPS 197]
CCM/CCMP,
GCM
[SP800-38C] (CCM, CCMP),
[SP800-38D] (GCM)
128-bit
256-bit
Assembler VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
CBC, XTS
[SP800-38A] (CBC),
[SP800-38E] (XTS)
128-bit
256-bit
Assembler PAA Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
KW
[SP800-38F] (KW)
[SP800-38F]
128-bit
256-bit
Assembler Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
CBC
[SP800-38A]
(CBC)
128-bit,
256-bit
SKG SEP Hardware
CCM
[SP800-38C] (CCM)
128-bit Broadcom WiFi chip N/A
FCS_COP.1(2)
Hashing SHS
[FIPS 180-4]
SHA-1,
SHA-256,
SHA-384,
SHA-512
VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
VID: 10937
SFR Cryptographic
Function
Algorithm Modes / Notes Key/Curve sizeImplementation Module
FCS_COP.1(3)
Digital signature
generation;
Digital signature
verification
RSA SigGen and SigVer
[FIPS 186-4]
Using
SHA-1 (SigVer only),
SHA-256,
SHA-384,
SHA-512
2048-bit,
3072-bit
Generic Apple CoreCrypto User
Space
RSA SigVer
[FIPS 186-4]
Using
SHA-1,
SHA-256,
SHA-384,
SHA-512
2048-bit,
3072-bit
Generic Apple CoreCrypto Kernel
Space
ECDSA SigGen and
SigVer
[FIPS 186-4]
Using
SHA-1 (SigVer only),
SHA-256,
SHA-384,
SHA-512
P-256,
P-384
Generic Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
VID: 10937
SFR Cryptographic
Function
Algorithm Modes / Notes Key/Curve sizeImplementation Module
FCS_COP.1(4)
Keyed-hash HMAC
[FIPS 198-1]
HMAC-SHA-1,
Block size: 512
Output MAC: 160
400, 480,
512, 560
640 bits
VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
HMAC-SHA-256,
Block size: 512
Output MAC: 256
400, 480,
512, 560
640 bits
VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
HMAC-SHA-384,
Block size: 1024
Output MAC: 384
880, 960,
1024,1040
1120 bits
VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
HMAC-SHA-512,
Block size: 1024
Output MAC: 512
880, 960,
1024,1040
1120 bits
VNG Apple CoreCrypto User
Space
Apple CoreCrypto Kernel
Space
Apple SEP SKS
FCS_RBG_EXT.1
(Kernel
and
User
space)
Random number
generation;
Symmetric key
generation
CTR_DRBG
(AES)
[SP800-90A]
AES-128 256-bit Assembler_ VNG Apple CoreCrypto User
Space and Kernel Space
FCS_RBG_
EXT.1(SEP)
Random number
generation;
Symmetric key
generation.
CTR_DRBG
(AES)
[SP800-90A]
AES-128 128-bit Assembler_ VNG Apple SEP SKS
AES-256 256-bit Hardware DRBG SEP Hardware
Table 8: Explanation of usage for cryptographic functions in the cryptographic modules
VID: 10937
The following SFRs list algorithms that cannot currently be tested by the NIST CAVS tool.
• FCS_CKM.1(1) Cryptographic Key Generation Curve25519
• FCS_CKM.1/WLAN PRF-384 [IEE 802.11-2012]
• FCS_CKM.2(1) RSA [SP 800-56B]
• FCS_CKM.2/WLAN AES Key Wrap in an EAPOL-Key frame [RFC 3394],[802.11-2012]
• FCS_CKM.2(2) RFC 7748
• FCS_COP.1(5) PBKDF2 [NIST SP 800-132]
VID: 10937
Page 139 of 172 © 2019 Apple Inc. Version: 1.6
8.4 User Data Protection (FDP)
The Core System Services available for user data protection are those of Protection of Files
and Application access to Files, described below in 8.4.1 and 8.4.2. These are applicable to
all applications on the TOE which are all allowed access to these two System Services.
A further set of high-level system services are presented to applications and monitored by
iOS allowing users to grant access to these services, or not.
8.4.1 Protection of Files
When a new file is created on an iOS device, it’s assigned a class by the app that creates it.
Each class uses different policies to determine when the data is accessible. As described
above each class has a dedicated class key which is stored in wrapped form. Note that for
the classes other than 'No Protection' to work the user must have an active passcode lock set
for the device.
The basic classes and policies are described below.
Complete Protection (referred to as "class A" in some documents)
Files in this class can only be accessed when the device is unlocked.
Protected Unless Open (referred to as "class B" in some documents)
This class is for files that may need to be written while the device is locked.
Protected Until First User Authentication (referred to as "class C" in some documents)
This class is for files that are protected until the user has successfully authenticated. Unlike
the 'Complete Protection' class, the class key for this class is not wiped when the device is
locked, but after a re-boot the user has to authenticate before files in this class can be
accessed. So, once the user has authenticated after reboot the key is available until the
device is shutdown or rebooted.
No Protection (referred to as "class D" in some documents)
Files in this class can be always accessed. Still the files themselves are encrypted using a file
specific key, but this key can be unwrapped without using the passcode key derived from the
user's passcode or biometric authentication factor.
Note: class A, class B and class C keys require that the user has defined a PIN. Unless he
has done this only class D keys exist.
All data in files is considered private data, since all files are encrypted. Sensitive data is data
protected with a class A or class B key since this data is not accessible when the device is
locked.
8.4.2 Application Access to Files
An iOS app’s interactions with the file system are limited mostly to the directories inside the
app’s sandbox. During installation of a new app, the installer creates a number of containers
for the app. Each container has a specific role. The bundle container holds the app’s bundle,
whereas the data container holds data for both the application and the user. The data
container is further divided into a number of directories that the app can use to sort and
organize its data. The app may also request access to additional containers—for example,
the iCloud container—at runtime.
When a built-in app application is removed, all of its files, including any related user data and
configuration files are also removed. For any third-party applications, deleting an app (as
opposed to “offloading” an application) deletes both the application and all related data from
the mobile device.
8.4.3 Declaring the Required Device Capabilities of an Application
All applications must declare the device-specific capabilities they need to run. The value of
the UIRequiredDeviceCapabilities key is either an array or dictionary that contains additional
keys identifying features your app requires (or specifically prohibits). If you specify the value
VID: 10937
Page 140 of 172 © 2019 Apple Inc. Version: 1.6
of the key using an array, the presence of a key indicates that the feature is required; the
absence of a key indicates that the feature is not required and that the app can run without it.
If a dictionary is specified instead, each key in the dictionary must have a Boolean value that
indicates whether the feature is required or prohibited. A value of true indicates the feature is
required and a value of false indicates that the feature must not be present on the device.
8.4.4 App Groups
Apps and extensions owned by a given developer account can share content when
configured to be part of an App Group. It is up to the developer to create the appropriate
groups on the Apple Developer Portal and include the desired set of apps and extensions.
Once configured to be part of an App Group, apps have access to the following.
• A shared container for storage, which will stay on the device as long as at least one
app from the group is installed
• Shared preferences
• Shared Keychain items
The Apple Developer Portal guarantees that App Group IDs are unique across the app
ecosystem.
8.4.5 Restricting Applications Access to Services
The TOE allows a user to restrict the services an application can access. The services that
can be restricted on a per-app basis are as follows.
Applications prompt the mobile device user to grant permission for the application to use
system services when they are installed, Subsequently, mobile device users can perform
access control for applications using the following system services through the Settings »
Privacy interface.
• Location Services
• Contacts
• Calendars
• Reminders
• Photos
• Bluetooth Sharing
• Microphone
• Speech Recognition
• Camera
• Health
• HomeKit
• Media & Apple Music
• Motion & Fitness
8.4.6 Keychain Data Protection
Many apps need to handle passwords and other short but sensitive bits of data, such as keys
and login tokens. The iOS Keychain provides a secure way to store these items.
The Keychain is implemented as an SQLite database stored on the file system. There is only
one database; the securityd daemon determines which Keychain items each process or app
can access. Keychain access APIs result in calls to the daemon, which queries the app’s
“keychain-access-groups” and the “application-identifier” entitlement. Rather than limiting
access to a single process, access groups allow Keychain items to be shared between apps.
VID: 10937
Page 141 of 172 © 2019 Apple Inc. Version: 1.6
Keychain items can only be shared between apps from the same developer. This is managed
by requiring third-party apps to use access groups with a prefix allocated to them through the
iOS Developer Program, or in iOS 12, via application groups. The prefix requirement and
application group uniqueness are enforced through code signing, Provisioning Profiles, and
the iOS Developer Program. iOS provides a user interface (UI) in the Settings dialog that
allows importing of keys for use for Apple-provided applications such as Safari or VPN.
Keychain data is protected using a class structure similar to the one used in file Data
Protection. These classes have behaviors equivalent to file Data Protection classes, but use
distinct keys and are part of APIs that are named differently.
Table 9: Keychain to File-system Mapping, shows the Keychain classes and their equivalent
file system classes.
Keychain data
protection class
File data protection class
When unlocked NSFileProtectionComplete
While locked NSFileProtectionCompleteUnlessOpen
After first unlock NSFileProtectionCompleteUntilFirstUserAuthentication
Always NSFileProtectionNone
Table 9: Keychain to File-system Mapping
In addition, there are the Keychain data protection classes with the additional
"ThisDeviceOnly" added to their class name. Keychain items in those classes cannot be
moved to a different device using backup and restore; key chain items in those classes are
bound to the device.
Among the data stored in Keychain items are digital certificates used for setting up VPN
connections and certificates and private keys installed by the Configuration Profile.
Keychains can use access control lists (ACLs) to set policies for accessibility and
authentication requirements. Items can establish conditions that require user presence by
specifying that they can’t be accessed unless authenticated entering the device’s passcode.
ACLs are evaluated inside the Secure Enclave and are released to the kernel only if their
specified constraints are met.
Further information is found in section 1.5.2.5 Protection of the TSF.
8.4.7 VPN
VPN packet processing is handled by the TOE.
Since all the TSF binaries and libraries are protected from stack-based buffer overflow (See
8.7.5, Domain Isolation) it can determined that no data will be reused when processing
network packets.
Note: To protect the device from vulnerabilities in network processor firmware, network
interfaces including Wi-Fi and baseband have limited access to application processor
memory. When USB or secure digital input output (SDIO) is used to interface with the
network processor, the network processor cannot initiate Direct Memory Access (DMA)
transactions to the application processor. When PCIe is used, each network processor is on
its own isolated PCIe bus. An input–output memory management unit (IOMMU) on each PCIe
bus limits the network processor’s DMA access to pages of memory containing its network
packets or control structures.
8.4.8 Keyed Hash
The TSF performs keyed-hash message authentication in accordance with HMAC-SHA-1,
HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. It uses key sizes 128 to 256 bit and
message digest sizes 160 and 256, 384, 512 bits.
VID: 10937
Page 142 of 172 © 2019 Apple Inc. Version: 1.6
8.5 Identification and Authentication (FIA)
The user of the device is authenticated using a passcode, fingerprint, or facial authentication
factor. Except for making emergency calls, answering calls, using the cameras, and using the
flashlight, users need to authenticate using an authentication factor provided above. All
passcode entries are obscured by a dot symbol for each character as the user input occurs.
Biometric authentication inputs do not produce feedback to the user unless an input is
rejected. When an invalid fingerprint sample is given or cannot be authenticated, a simple
error message is returned to the user to try again. If three invalid biometric samples are
presented the device will offer passcode entry. After five invalid biometric samples are
presented passcode authentication is required.
For Face ID, when an invalid facial sample is given or cannot be authenticated, the user
needs to swipe up before a second attempt can occur and passcode entry will be presented
to the user as an option. After five invalid Face ID attempts, the device will vibrate and
passcode entry must be used.
The following passcode policies can be defined for managed devices.
• The minimum length of the passcode
• The minimum number of special characters a valid passcode must contain
• The maximum number of consecutive failed attempts to enter the passcode (which can
be value between 2 and 11, the default is 11)
• The number of minutes for which the device can be idle before it gets locked by the
system
• The maximum number of days a passcode can remain unchanged
• The size of the passcode history (the maximum value is 50)
Those parameters for the passcode policy can be defined in the Passcode Policy Payload
section of a Configuration Profile defined by a system administrator for a managed device.
For details see section 8.6, Specification of Management Functions (FMT), below.
Devices that support Touch ID do not support Face ID. The passcode and the device’s
biometric authentication method cannot be combined for two-factor authentication. In
addition, the following behavior applies to biometric authentication methods. A passcode must
be supplied for additional security validation under any of the following conditions.
• The device has just been turned on or restarted.
• The device hasn’t been unlocked for more than 48 hours.
• The passcode hasn’t been used to unlock the device in the last 156 hours (six and a
half days) and Face ID hasn’t unlocked the device in the last 4 hours.
• The device has received a remote lock command.
• After five unsuccessful attempts to match.
• After initiating power off/Emergency SOS.
The number of failed authentication attempts is maintained in a system file which will persist
in the event of graceful or ungraceful loss of power to the TOE. The counter maintaining the
number of failed consecutive logon attempts is increased by one immediately once the TOE
has identified that the passcode is incorrect. The increment of the counter is completed
before the UI informs the user about the failed logon attempt.
The time between consecutive authentication attempts, including biometric authentication
factors, is at least the time it takes the PBKDF2 function to execute. This is calibrated to be at
least 80 milliseconds. In addition, for Touch ID, the TOE enforces a five second delay
between repeated failed authentication attempts. When a user exceeds the number of
consecutive failed passcode login attempts, the user's partition is erased (by erasing the
encryption key). The OS partition is mounted READONLY upon boot and is never modified
during the use of the TOE except during a software update or restore. Note that entering the
same incorrect passcode multiple times consecutively causes the failed login counter to
VID: 10937
Page 143 of 172 © 2019 Apple Inc. Version: 1.6
increment only once for those multiple attempts even though these are all failed login
attempts.
Additionally, authentication credentials which include biometric samples are not stored on the
TOE in any location. Successful authentication attempts are achieved exclusively by a
successful key derivation that decrypts the keybag in the Secure Enclave Processor with the
respective class keys.
8.5.1 Biometric Authentication
8.5.1.1 Accuracy of Biometric Authentication
All validation of biometric authentication factors is conducted in the form of an off-line test.
Fingerprint data used in these tests were collected separately for each sensor generation
using multiple devices, the production version of the sensor and its firmware. The software
(i.e. primarily the biometric algorithms) is based on production code corresponding to the
given iOS release.
For efficiency reasons the test is not run on the production hardware, but it is instead
emulated on a different platform in a cloud computation infrastructure. A special testing step
is performed to assure equality of results between the emulated and production run on the
same input data.
In the case of multiple authentication for Face ID tests were performed in portrait mode only.
The False Acceptance Rate (FAR), which is further defined in [PP_MD_V3.1], test protocols
differ between sensor generations as follows.
• For Gen.1 a full cross-comparison scheme is used. Each user is enrolled and each
template is attacked by all other user data.
• For Gen.2 and Gen.3 a partial cross-comparison is done. In this scheme test population
is split between users and imposters. Users are enrolled and each template is attacked
by all imposter data.
Validation of Face ID follows the methodology established for Touch ID also using offline
testing. The FAR was evaluated by full cross-comparison of all subjects in the datasets. The
datasets contained fully labeled data.
Data was collected from a wide range of subjects. Facial expression variations were collected
from each subject as well as variations in environmental factors. Variations in subject age,
ethnicity, and gender were also introduced into the dataset as well as subjects that exhibited
familial relationships such as siblings. Offline testing was performed with data that simulates
a normal presentation -- near frontal view, no obstructions, within nominal range (20-45 cm).
8.5.1.2 Rule of 3 Discussion
The size of the test population differs between sensor generations of both Touch ID as well
as for Face ID on the given processors. In all cases, there are enough unique subjects to
fulfill the Rule of 3.
The actual tests are run on datasets covering more fingers per subject (and in the case and
also more attempts per impostor. Therefore, the actual number of imposter attempts is much
greater than number of unique attempts. Each imposter has a similar contribution to the
result. We assume that in combination with, for Touch ID, a small sensor area this approach
improves quality and variability of the database.
8.5.1.3 Accuracy of Biometric Authentication: SAFAR
The overall System Authentication False Acceptance Rate (SAFAR), which is further defined
in [PP_MD_V3.1] is derived from tests run for FIA_BMG_EXT.1.1 as noted in section 8.5.1.1,
above.
Since iOS 12 allows the use of 5 fingerprint attempts or 10 attempts of 6-digit passcode, the
value of SAFAR is dominated by fingerprint SAFAR for 5 attempts.
VID: 10937
Page 144 of 172 © 2019 Apple Inc. Version: 1.6
Similarly, iOS 12 allows the use of 5 facial identification attempts or 10 attempts of 6-digit
passcode, value of SAFAR is dominated by Face ID SAFAR for 5 attempts.
Since each mobile device contains no more than one BAF, the interaction of BAFs is not an
issue for the calculation.
8.5.1.4 Biometric Sample Quality
In iOS 12, sample quality is inspected before it is passed to the matcher algorithm for both
Touch ID and Face ID. In general, the inspection is based on the following.
For Touch ID
• Deciding what portion of the sensor is covered by the finger. Sensor regions containing
very weak signal are considered not covered. Samples with high number of such
regions are rejected.
• Assessing the level of residual fixed-pattern noise. Samples where the noise could
significantly alter the fingerprint pattern are rejected.
• Detection and removal of regions affected by image discontinuity caused by finger
motion. Samples with many regions affected by motion are rejected.
For Face ID
• User is attending the device
• No significant depth holes in the depth map
• Anti-Spoofing network to reject physical spoofs
• For enrollment
o No occlusions detected (e.g. hand covering face)
o Face within certain pose angles
o User attending device
o No significant depth holes in the depth map
o Anti-spoofing network to reject physical spoofs
The validation of the discussed mechanism is performed regularly for each major iOS
release. The test is based on specialized datasets containing different levels of coverage and
different artifacts. These samples are fed to the biometric system and it is confirmed whether
the sample is correctly passed or rejected from the processing as expected.
Additionally, the biometric system is tested by feeding artificially created images containing
different geometric patterns.
8.5.2 Certificates
There are a number of certificates used by the TOE. First there is the Apple certificate used to
verify the integrity and authenticity of software updates. This certificate is installed in ROM
during manufacturing.
Other certificates used for setting up trusted channels or decrypt/verify protected e-mail can
be imported by a user (if allowed by the policy) or installed using Configuration Profiles.
Certificates can be installed for the following.
• IPsec
• TLS
• EAP-TLS, other supported EAP protocols
Note that only IPsec, TLS, and EAP-TLS are addressed by [PP_MD_V3.1]. Certificates have
a certificate type that defines their respective application area. This ensures that only
certificates defined for a specific application area are used. In addition, the database
VID: 10937
Page 145 of 172 © 2019 Apple Inc. Version: 1.6
containing trust anchors for all certificates is protected via integrity check and write protection.
The certificate types supported by the TOE are as follows.
• AppleX509Basic
• AppleSSL
• AppleSMIME
• AppleEAP
• AppleIPsec
• AppleCodeSigning
• AppleIDValidation
• AppleTimeStamping
External entities can be authenticated using a digital certificate. Out of the box, iOS includes a
number of preinstalled root certificates.
Code signing certificates need to be assigned by Apple and can be imported into a device.
The issue of such a certificate can be by app developers or by enterprises that want to deploy
apps from their MDM to managed devices. All apps must have a valid signature that can be
verified by a code signing certificate before they are installed on a device.
iOS can update certificates wirelessly, if any of the preinstalled root certificates become
compromised. To disable this, there is a restriction that prevents over-the-air certificate
updates.
The list of supported certificate and identity formats are:
• X.509 certificates with RSA keys, and
• File extensions cer, .crt, .der, .p12, and .pfx.
To use a root certificate that isn’t preinstalled, such as a self-signed root certificate created by
the organization managing the TOE, they can be distributed using one of the following
methods.
• When reviewed and accepted by the user
• Using the Configuration Profile
• Downloaded from a web site
When attempting to establish a connection using a remote certificate, the certificate is first
checked to ensure it is valid. Certificates are validated against the common name (CN)
portion of the distinguished name (DN). If the CN does not match the corresponding domain
name system (DNS) or IP Address of the server being accessed, validation and subsequently
the connection will fail. If the certificate is valid, the attempt to establish the connection
continues. If the certificate is invalid, the next step is up to the application. The application
should provide an indication to the user that the certificate is invalid and options to accept or
reject.
TLS is implemented as a stack that can be utilized by third-party applications. The API
informs the calling application that the certificate is not valid. For example, Safari will display a
message to the user that the remote certificate validation failed and allow the user to examine
the certificate with the option to allow the connection or not.
iOS can be configured to disable the user option to accept invalid TLS certificates using the
"Allow user to accept untrusted TLS certificates" setting.
8.5.3 MDM Server Reference ID
The initial MDM Payload contains a mandatory ServerURL string. The URL that the device
contacts to retrieve device management instructions must begin with the https:// URL
scheme, and may contain a port number (for example ":1234").
VID: 10937
Page 146 of 172 © 2019 Apple Inc. Version: 1.6
The MDM check-in protocol is used during initialization to validate a device's eligibility for
MDM enrollment and to inform the MDM server that a device’s Push Token has been
updated. If a check-in server URL is provided in the MDM payload, the check-in protocol is
used to communicate with that check-in server. If no check-in server URL is provided, the
main MDM Server URL is used instead.
A managed Mobile Device uses an identity to authenticate itself to the MDM Server over TLS
(Secure Sockets Layer (SSL)). This identity can be included in the profile as a Certificate
payload, or can be generated by enrolling the device with Simple Certificate Enrollment
Protocol (SCEP)23
. Each MDM Server must be registered with Apple at the MDM Server
Device Enrollment Program (DEP) management portal. The DEP provides details about the
server entity to identify it uniquely throughout the organization deploying the MDM Server.
Each server can be identified by either its system-generated UUID or by a user-provided
name assigned by one of the organization’s users. Both the UUID and server name must be
unique within the organization. Registered MDM servers can include third party servers. iOS
devices automatically connect to the MDM Server during setup if the device is enrolled into
the DEP and is assigned to an MDM Server. During the device enrollment, the MDM
enrollment service returns a JavaScript Object Notation (JSON) dictionary with the keys to
mobile devices shown in Table 10: MDM Server Reference Identifiers, following.
Key Value
server_name An identifiable name for the MDM Server
server_uuid A system-generated server identifier
admin_id Apple ID of the person who generated the current tokens that
are in use
facilitator_id Legacy equivalent to the admin_id key. This key is deprecated
and may not be returned in future responses.
org_name The organization name
org_email The organization email address
org_phone The organization phone
org_address The organization address
Table 10: MDM Server Reference Identifiers
8.6 Specification of Management Functions (FMT)
In FMT_SMF_EXT.3.1 “no additional functions" is selected and so these are not documented
in this [ST] as supported by the platforms.
Since all the Mobile Devices specified in this [ST] use iOS, there are no differences between
supported management functions and policies between the different mobile devices. The
supported management functions for iOS are described in [iOS_CFG].
Table 4: Management Functions, describes all management functions of the devices as well
as the MDM Agent that are available when the device is enrolled in MDM.
8.6.1 Enrollment
The methods by which an MDM Agent can be enrolled are as follows.
• Manually, using Apple's Profile Manager
• Manually, using Apple Configurator 2
• Distributing an enrollment profile via email, or a web site
• Device Enrollment Program (This is an automated and enforced method of
automatically enrolling new devices.)
23 More information about SCEP can be found at https://datatracker.ietf.org/doc/draft-nourse-scep/
VID: 10937
Page 147 of 172 © 2019 Apple Inc. Version: 1.6
A more detailed description is found in section 8.5.3, above. In addition, the enrollment
process is discussed in the MDM Protocol reference [iOS_MDM].
8.6.2 Configuration Profiles
The TOE can be configured using "Configuration Profiles" that are installed on the TOE.
Configuration Profiles are XML files that may contain settings for a number of configurable
parameters. For details on the different payloads and keys that can be defined see the
document "Configuration Profile Key Reference" ([iOS_CFG]) that can be downloaded from
the Apple web site.
Configuration Profiles are processed by iOS.
The PayloadRemovalDisallowed key allows to prevent manual removal of profiles installed
through an MDM server. Such profiles cannot be removed using the Profiles preference pane,
nor the profiles command line tool even when run as root. Only the MDM server can remove
such profiles. Profiles installed manually, with PayloadRemovalDisallowed set to true, can be
removed manually, but only by using administrative authority.
Configuration profiles can be deployed in one of five different ways:
• using the Apple Configurator 2 tool,
• via an email message,
• via a web page,
• using over-the-air configuration as described in [iOS OTAConfig], and
• using over-the-air configuration via a MDM Server.
To preserve the integrity, authenticity, and confidentiality of Configuration Profiles they can be
required to be digitally signed and encrypted.
Managed items relevant for this [ST] that have to be configured using Configuration Profiles
are as follows.
• The password policy—the administrator can define this using the Passcode Policy
Payload and
o define the minimum password length,
o define requirements for the password complexity,
o define the maximum password lifetime,
o define the maximum time of inactivity after which the device is locked
automatically, and
o define the maximum number of consecutive authentication failures after which
the device is wiped.
• The VPN policy as follows:
o specify that VPN is always on,
o define the authentication method (certificate), and
o specification of certificates or shared keys.
• The Wi-Fi policy as follows:
o the EAP types allowed,
o the service set identifiers (SSIDs) allowed to connect to,
o the encryption type(s) allowed, and
o enabling/disabling Wi-Fi hotspot functionality.
• General restrictions as follows:
VID: 10937
Page 148 of 172 © 2019 Apple Inc. Version: 1.6
o allowing or disallowing specific services (e. g. remote backup) or using devices
like the cameras,
o allowing or disallowing notifications when locked, and
o allowing or disallowing a prompt when an untrusted certificate is presented in a
TLS/HTTPS connection.
Note that the microphones cannot be disabled in general but a user can restrict access to the
microphones on a per-app basis.
Other functions that can be enabled/disabled by an administrator are:
• the installation of applications by a user,
• the possibility to perform backups to iCloud,
• the ability to submit diagnostics automatically,
• the ability to use the fingerprint device (Touch ID) for user authentication,
• the ability to see notifications on the lock screen,
• the ability to take screen shots,
• the ability to accept untrusted TLS certificates, and
• the ability to perform unencrypted backups (via iTunes).
Further restrictions can be enforced for enrolled devices. Those include:
• the ability to modify the account,
• the ability to modify the cellular data usage,
• the ability to pair with a host other than the supervision host,
• the ability for the user to install Configuration Profiles or certificates interactively, and
• the ability for the user to use 'Enable Restrictions' interface.
A user can access management functions available to him via the menus of the graphical
user interface. The functions he can perform are described in [iPhone_UG] and [iPad_UG].
Configuration profiles can also be deployed such that users are unable to override or remove
restrictions set in place by Administrators or MDM Administrators. Depending on the behavior
defined in the Configuration Profile, users will be unable to access, perform, or relax
management functions defined in Table 4: Management Functions. In the most restrictive
mode, users will not be able to access the options to alter the above functionality at all. In less
restrictive modes, the user is only able to select more secure options.
8.6.3 Biometric Authentication Factors (BAFs)
The enrollment and management of biometric authentication factors and credentials is
detailed in the [iPhone_UG] and [iPad_UG] respectively.
Enrollment for Touch ID is typically accomplished during initial device configuration but can
also be performed using the Settings»Touch ID & Passcode menus. Multiple fingerprints may
be enrolled, named, and deleted from this menu. In order to remove a specific finger, a user
must tap the finger for removal followed by delete fingerprint. Users may place a finger on the
Touch ID sensor to determine which biometric credential entry it is mapped. Users may also
disable Touch ID selectively for applications or entirely from the Settings»Touch ID &
Passcode menu and turning off one or more of the corresponding options.
• Unlock
• Apple Pay
• iTunes & App Store
Enrollment for Face ID is typically accomplished during initial device configuration but can
also be performed using the Settings»Face ID & Passcode menu by selecting the “Set up
VID: 10937
Page 149 of 172 © 2019 Apple Inc. Version: 1.6
Face ID” option. Users can enroll an alternate appearance for Face ID, for a total of two
enrollments. Users may remove Face ID biometric samples from the Settings»Face ID &
Passcode and selecting the “Reset Face ID” option, this action resets both alternate
appearances. Users may also disable Face ID selectively for applications or entirely from the
Settings»Touch ID & Passcode menu and turning off one or more of the corresponding
options.
• Unlock
• Apple Pay
• iTunes & App Store
• Safari AutoFill
When enrolling, naming, and deleting BAFs the passcode must be successfully entered
before changes can be made.
8.6.4 Unenrollment
The Configuration Profile Key Reference, [iOS_CFG], describes unenrollment options for the
mobile device user through specifying the key "PayloadRemovalDisallowed". This is an
optional key. If present and set to true the user cannot delete the profile unless the profile has
a removal password and the user provides it.
It is up to the mobile device administrator to ensure that this key is set appropriately.
In supervised mode the MDM payload can be locked to the device.
In addition, [iOS_MDM] describes the additional ability to restrict the installation and removal
of Configuration Profiles from other sources. This is achieved using the AccessRights key
which has a value of a logical OR of the following bits.
Required
• 1—Allow inspection of installed Configuration Profiles
• 2—Allow installation and removal of Configuration Profiles
• 4—Allow device lock and passcode removal
• 8—Allow device erase
• 16—Allow query of Device Information (device capacity, serial number)
• 32—Allow query of Network Information (phone/SIM numbers, MAC addresses)
• 64—Allow inspection of installed provisioning profiles
• 128—Allow installation and removal of provisioning profiles
• 256—Allow inspection of installed applications
• 512—Allow restriction-related queries
• 1024—Allow security-related queries
• 2048—Allow manipulation of settings
• 4096—Allow app management
Note that the AccessRights key may not be zero. If bit 2 is specified, then bit 1 must also be
specified. If bit 128 is specified, then bit 64 must also be specified.
8.6.5 Radios
The following radios are found in the TOE.
• Cellular
• WiFi
• Bluetooth
VID: 10937
Page 150 of 172 © 2019 Apple Inc. Version: 1.6
• NFC (iPhone devices only)
These are fully described, including the frequencies employed, in Table 1: Devices Covered
by the Evaluation.
As indicated in Table 4: Management Functions, users can enable/disable these radios.
8.6.6 Audio and Visual collection devices
The following audio and visual collection devices are found in the TOE.
• Cameras
• Microphones
Table 4: Management Functions describes the roles that can enable/disable them.
8.6.7 VPN Certificate Credentials
For VPN, X509 certificate-based authentication is allowed in the evaluated configuration.
These credentials (X.509 certificates) are used by the device when connecting to the IPsec
VPN infrastructure.
8.7 Protection of the TSF (FPT)
8.7.1 Secure Boot
Each step of the startup process contains components that are cryptographically signed by
Apple to ensure integrity and that proceed only after verifying the chain of trust. This includes
the bootloaders, kernel, kernel extensions, and baseband firmware. This secure boot chain
helps ensure that the lowest levels of software aren’t tampered with.
When an iOS device is turned on, its application processor immediately executes code from
read-only memory known as Boot ROM. This immutable code, known as the hardware root of
trust, is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code
contains the Apple Root CA public key, which is used to verify that the iBoot bootloader is
signed by Apple before allowing it to load. This is the first step in the chain of trust where
each step ensures that the next is signed by Apple. When the iBoot finishes its tasks, it
verifies and runs the iOS kernel. For devices with an A9 or earlier A-series processor, an
additional Low-Level Bootloader (LLB) stage is loaded and verified by the Boot ROM and in
turn loads and verifies iBoot.
A failure of the Boot ROM to load LLB (on older devices) or iBoot (on newer devices) results
in the device entering DFU mode. In the case of a failure in LLB or iBoot to load or verify the
next step, startup is halted and the device displays the connect to iTunes screen. This is
known as recovery mode. In either case, the device must be connected to iTunes through
USB and restored to factory default settings.
The Boot Progress Register (BPR) is used by the Secure Enclave to limit access to user data
in different modes and is updated before entering the following modes:
• Recovery Mode: Set by iBoot on devices with Apple A10, S2, and newer system on
chip (SoCs)
• DFU Mode: Set by Boot ROM on devices with an A12 SoC
8.7.2 Joint Test Action Group (JTAG) Disablement
The mobile devices of iPhones and iPads use a 2-staged interface that resembles the
functionality of JTAG but does not implement the JTAG protocol.
The Apple development environment that is JTAG-like is based on the following.
• To use this JTAG-like interface, a development-fused device is required. This implies
that certain hardware fuses were not blown during the manufacturing process. Only
with these development-interface related fuses intact, the JTAG-like interface is
technically reachable.
VID: 10937
Page 151 of 172 © 2019 Apple Inc. Version: 1.6
• When having a development-fused device, the Apple developers are given a special
Lightning cable that contains some additional computing logic. This cable establishes a
serial channel with the mobile device's JTAG-like interface reachable on development-
fused devices. This Lightning cable connects to the development machine's USB port
and allows subsequent access by development tools. The serial link allows access to
the serial console of the mobile device. The serial console, however, does not allow
access on a production fused device. On a development-fused device, the root account
is enabled and an SSH server is listening. The SSH server is accessible via the serial
link and allows the developer to access the root account for development including
uploading of software or modifying of installed software.
8.7.3 Secure Software Update
Software updates to the TOE are released regularly to address emerging security concerns
and also provide new features; these updates are provided for all supported devices
simultaneously. Users receive iOS update notifications on the device and through iTunes, and
updates are delivered wirelessly, encouraging rapid adoption of the latest security fixes.
The startup process described above helps ensure that only Apple-signed code can be
installed on a device. To prevent devices from being downgraded to older versions that lack
the latest security updates, iOS uses a process called System Software Authorization. If
downgrades were possible, an attacker who gains possession of a device could install an
older version of iOS and exploit a vulnerability that’s been fixed in the newer version.
On a device with an A8 or later A-series processor, the Secure Enclave coprocessor also
utilizes System Software Authorization to ensure the integrity of its software and prevent
downgrade installations.
iOS software updates can be installed using iTunes or over-the-air (OTA) on the device via
HTTPS trusted channel. With iTunes, a full copy of iOS is downloaded and installed. OTA
software updates download only the components required to complete an update, improving
network efficiency, rather than downloading the entire OS. Additionally, software updates can
be cached on a local network server running the caching service on OS X Server so that iOS
devices do not need to access Apple servers to obtain the necessary update data.
During an iOS upgrade, iTunes (or the device itself, in the case of OTA software updates)
connects to the Apple installation authorization server and sends it a list of cryptographic
measurements for each part of the installation bundle to be installed (for example, LLB, iBoot,
the kernel, and OS image), a random anti-replay value (nonce), and the device’s unique ID
(ECID).
The authorization server checks the presented list of measurements against versions for
which installation is permitted and, if it finds a match, adds the ECID to the measurement and
signs the result. The server passes a complete set of signed data to the device as part of the
upgrade process. Adding the ECID “personalizes” the authorization for the requesting device.
By authorizing and signing only for known measurements, the server ensures that the update
takes place exactly as provided by Apple.
The boot-time, chain-of-trust evaluation verifies that the signature comes from Apple and that
the measurement of the item loaded, combined with the device’s ECID, matches what was
covered by the signature.
These steps ensure that the authorization is for a specific device and that an old iOS version
from one device can’t be copied to another. The nonce prevents an attacker from saving the
server’s response and using it to tamper with a device or otherwise alter the system software.
Note that this ensures the integrity and authenticity of software updates. A TLS trusted
channel is provided for this process.
8.7.4 Security Updates
Apple generally does not disclose, discuss, or confirm security issues until a full investigation
is complete and any necessary patches or releases are available. Once an issue has been
confirmed and a patch has been made available references containing technical details on
the patches / Common Vulnerabilities and Exposures (CVEs), etc are released. Apple also
VID: 10937
Page 152 of 172 © 2019 Apple Inc. Version: 1.6
distributes information about security issues in its products through security advisories.
Advisories are provided through the security-announce mailing list. Resources include the
following.
Contact Apple About Security Issues
https://support.apple.com/en-us/HT201220
Apple Security Updates (Advisories)
https://support.apple.com/en-us/HT201222
Security-Announce Mailing List (receive Apple security advisories through)
https://lists.apple.com/mailman/listinfo/security-announce/
8.7.5 Domain Isolation
The TOE does not support Unstructured Supplementary Service Data (USSD) or Man-
Machine Interface (MMI) codes and also does not support auxiliary boot modes.
All applications are executed in their own domain or 'sandbox' which isolates the application
from other applications and the rest of the system. Stack-based buffer overflow protection is
implemented for every sandbox. They are also restricted from accessing files stored by other
applications or from making changes to the device configuration. Each application has a
unique home directory for its files, which is randomly assigned when the application is
installed. If a third-party application needs to access information other than its own, it does so
only by using services explicitly provided by iOS.
Stack-based buffer overflow protection implementations in iOS include the following.
• Automatic reference counting (ARC): a memory management system that handles
the reference count of objects automatically at compile time
• Address space layout randomization (ASLR): discussed below
• Stack-smashing protection: by utilizing a canary on the stack (Apple recommends
that developers compile applications using the -fstack-protector-all compiler flag.)
System files and resources are also shielded from the user’s apps. The majority of iOS runs
as the non-privileged user “mobile,” as do all third-party apps. The entire OS partition is
mounted as read-only. Unnecessary tools, such as remote login services, aren’t included in
the system software, and APIs do not allow apps to escalate their own privileges to modify
other apps or iOS itself.
Access by third-party apps to user information and features is controlled using declared
entitlements. Entitlements are key value pairs that are signed in to an app and allow
authentication beyond runtime factors like a UNIX user ID. Since entitlements are digitally
signed, they cannot be changed. Entitlements are used extensively by system apps and
daemons to perform specific privileged operations that would otherwise require the process to
run as root. This greatly reduces the potential for privilege escalation by a compromised
system application or daemon.
Address space layout randomization (ASLR) protects against the exploitation of memory
corruption bugs. All TSF binaries and libraries use ASLR to ensure that all memory regions
are randomized upon launch. Xcode, the iOS development environment, automatically
compiles third-party programs with ASLR support turned on. Address space layout
randomization is used for every sandbox used to execute applications in. There are 8 bits of
randomness taken from the application processor TRNG involved in the randomization, the
seed for the RNG comes from the seed that also feeds the approved DRBG for cryptographic
use.
In addition, the Memory Management Unit (MMU) supports memory address translation using
a translation table maintained by the OS kernel. For each page, the MMU maintains flags that
allow or deny the read, write or execution of data. Execution in this case allows the CPU to
fetch instructions from a given page.
8.7.6 Device Locking
The TOE is locked after a configurable time of user inactivity or upon request of the user.
When the device is locked, the class key for the 'Complete Protection' class is wiped 10
VID: 10937
Page 153 of 172 © 2019 Apple Inc. Version: 1.6
seconds after locking, making files in that class inaccessible. This also applies for the class
key of the 'Accessible when unlocked' Keychain class.
The lock screen of a device can be defined and set for supervised devices by an
administrator using Apple Configurator 2 or an MDM service.
The TOE can be locked remotely either via the iCloud "Lost Mode" function or by an MDM
system if the device is enrolled in management.
8.7.7 Time
The following security functional requirements make use of time.
• ALC_TSU_EXT
• FAU_GEN.1.2
• FIA_UAU.7
• FIA_X509_EXT.1.1
• FIA_X509_EXT.3.1
• FMT_SMF_EXT.1.1 Function 1:
• FMT_SMF_EXT.1.1 Function 2:
• FPT_STM.1.1
• FTA_SSL_EXT.1
When the device starts and the "Set Automatically" setting is set on the device the following
services are used to synchronize the real-time clock on the device.
For A8 and later platforms the devices set time by GPS, unless GPS is unavailable, in which
case the Apple NTP server will be used.
In the evaluated configuration the “Set Automatically” setting must be set.
When configured and maintained according to the Network, Identity and Time Zone (NITZ),
Global Positioning Satellites (GPS), Network Time Protocol (NTP) standards or the cellular
carrier time service the time may be considered reliable.
8.7.8 Inventory of TSF Binaries and Libraries
All user space binaries (applications as well as shared libraries) are subject to address space
layout randomization. The logic is implemented in the binary loader and agnostic of a
particular file or its contents. An inventory of TSF binaries and libraries has been provided to
NIAP since the list is considered proprietary.
8.7.9 Self-Tests
Self-tests are performed by the three cryptographic modules included in the TOE.
These tests are sufficient to demonstrate that the TSF is operating correctly since they
include each of the cryptographic modules included in the TSF. If the self-tests fail then the
TSF will not operate.
8.7.9.1 Apple iOS CoreCrypto Cryptographic Module for ARM
The module performs self-tests to ensure the integrity of the module and the correctness of
the cryptographic functionality at start up. In addition, the random bit generator requires
continuous verification. The FIPS Self-Tests application runs all required module self-tests.
This application is invoked by the iOS startup process upon device power on.
The execution of an independent application for invoking the self-tests in the
libcorecrypto.dylib makes use of features of the iOS architecture: the module, implemented in
libcorecrypto.dylib, is linked by libcommoncrypto.dylib which is linked by libSystem.dylib. The
libSystem.dylib is a library that must be loaded into every application for operation. The library
is stored in the kernel cache and therefore is not available in the file system as directly visible
VID: 10937
Page 154 of 172 © 2019 Apple Inc. Version: 1.6
files. iOS ensures that there is only one physical instance of the library and maps it to all
application linking to that library. In this way, the module always stays in memory. Therefore,
the self-test during startup time is sufficient as it tests the module instance loaded in memory
which is subsequently used by every application on iOS.
All self-tests performed by the module are listed and described in this section.
Power-Up Self-Tests
The following tests are performed each time the Apple CoreCrypto Cryptographic Module for
ARM starts and must be completed successfully for the module to operate in the FIPS
approved mode. If any of the following tests fail, the device powers itself off. To rerun the self-
tests on demand, the user must reboot the device.
Cryptographic Algorithm Tests
Algorithm Modes Test
AES implementations selected by the
module for the corresponding environment
AES-128
ECB, CBC,
GCM, XTS
KAT
Separate encryption / decryption
operations are performed
DRBG (CTR_DRBG) N/A KAT
HMAC-SHA-1, HMAC-SHA-256, HMAC-
SHA-512
N/A KAT
RSA
SIG(ver),
SIG(gen)
Pair-wise consistency checks
Encrypt / decrypt
KAT, Separate encryption
/decryption operations are
performed
ECDSA
Signature
Generation,
Signature
Verification
Pair-wise consistency checks
Diffie-Hellman “Z” computation N/A KAT
EC Diffie-Hellman “Z” computation N/A KAT
Table 11: Apple CoreCrypto Cryptographic Module for
ARM Cryptographic Algorithm Tests
Software / Firmware Integrity Tests
A software integrity test is performed on the runtime image of the Apple CoreCrypto
Cryptographic Module for ARM. The CoreCrypto’s HMAC-SHA-256 is used as an FIPS
approved algorithm for the integrity test. If the test fails, then the device powers itself off.
Critical Function Tests
No other critical function test is performed on power up.
Conditional Tests
The following sections describe the conditional tests supported by the Apple CoreCrypto
Cryptographic Module for ARM.
• Pair-wise Consistency Test
The Apple CoreCrypto Cryptographic Module for ARM does generate asymmetric keys
and performs all required pair-wise consistency tests, the encryption/decryption as well
as signature verification tests, with the newly generated key pairs.
• SP 800-90A Assurance Tests
The Apple CoreCrypto Cryptographic Module for ARM performs a subset of the
VID: 10937
Page 155 of 172 © 2019 Apple Inc. Version: 1.6
assurance tests as specified in section 11 of SP 800-90A, in particular it complies with
the mandatory documentation requirements and performs known-answer tests and
prediction resistance.
• Critical Function Test
No other critical function test is performed conditionally.
8.7.9.2 Apple CoreCrypto Kernel Cryptographic Module for ARM
The module performs self-tests to ensure the integrity of the module and the correctness of
the cryptographic functionality at start up. In addition, the DRBG requires continuous
verification. The FIPS Self-Tests functionality runs all required module self-tests. This
functionality is invoked by the iOS Kernel startup process upon device initialization. If the self-
tests succeed, the Apple CoreCrypto Kernel Cryptographic Module for ARM instance is
maintained in the memory of the iOS Kernel on the device and made available to each calling
kernel service without reloading. All self-tests performed by the module are listed and
described in this section.
Power-Up Tests
The following tests are performed each time the Apple CoreCrypto Kernel Cryptographic
Module for ARM starts and must be completed successfully for the module to operate in the
FIPS approved mode. If any of the following tests fails the device shuts down automatically.
To run the self- tests on demand, the user may reboot the device.
Cryptographic Algorithm Tests
Algorithm Modes Test
AES implementations selected
by the module for the
corresponding environment
AES-128
ECB, CBC, XTS
KAT
Separate encryption / decryption operations
are performed
DRBG (CTR_DRBG) N/A KAT
HMAC-SHA-1, HMAC-SHA-
256, HMAC-SHA-512
N/A KAT
ECDSA
Signature
Generation,
Signature
Verification
pair-wise consistency test
RSA
Signature
Verification
KAT
Table 12: Apple CoreCrypto Kernel Cryptographic Module for
ARM Cryptographic Algorithm Tests
Software/Firmware Integrity Tests
A software integrity test is performed on the runtime image of the Apple CoreCrypto Kernel
Cryptographic Module for ARM. The CoreCrypto’s HMAC-SHA256 is used as an Approved
algorithm for the integrity test. If the test fails, then the device powers itself off.
Critical Function Tests
No other critical function test is performed on power up.
Conditional Tests
The following sections describe the conditional tests supported by the Apple CoreCrypto
Kernel Cryptographic Module for ARM.
• Continuous Random Number Generator Test
The Apple CoreCrypto Kernel Cryptographic Module for ARM performs a continuous
VID: 10937
Page 156 of 172 © 2019 Apple Inc. Version: 1.6
random number generator test, whenever CTR_DRBG is invoked. In addition, the seed
source implemented in the operating system kernel also performs a continuous self-
test.
• Pair-wise Consistency Test
The Apple CoreCrypto Kernel Cryptographic Module for ARM generates asymmetric
ECDSA key pairs and performs all required pair-wise consistency tests (signature
generation and verification) with the newly generated key pairs.
• SP800-90A Assurance Tests
The Apple CoreCrypto Kernel Cryptographic Module for ARM performs a subset of the
assurance tests as specified in section 11 of SP800-90A, in particular it complies with
the mandatory documentation requirements and performs known-answer tests and
prediction resistance.
• Critical Function Test
No other critical function test is performed conditionally.
8.7.9.3 Apple Secure Key Store Cryptographic Module v9.0
FIPS 140-2 requires that the module perform self-tests to ensure the integrity of the module
and the correctness of the cryptographic functionality at start up. In addition, the noise source
feeding the random bit generator requires continuous verification. The module runs all
required module self-tests pertaining to the firmware. This self-test is invoked automatically
when starting the module. In addition, during startup of the hardware, the hardware DRBG
invokes its independent self-test.
The occurrence of a self-test error in either the firmware or the hardware DRBG triggers an
immediate shutdown of the device preventing any operation.
All self-tests performed by the module are listed and described in this section.
Power-Up Tests
The following tests are performed each time the Apple iPad and iPhone Mobile Devices with
iOS 12 starts and must be completed successfully for the module to operate in the FIPS
approved mode. If any of the following tests fails the device powers itself off. To rerun the
self-tests on demand, the user must reboot the device.
VID: 10937
Page 157 of 172 © 2019 Apple Inc. Version: 1.6
Cryptographic Algorithm Tests
Algorithm Modes Test
AES Implementation selected by the module for the
corresponding environment
AES-128
ECB, CBC KAT24
Separate encryption / decryption
operations are performed
AES SKG Hardware Accelerator Implementation
AES-128
ECB, CBC KAT
Separate encryption / decryption
operations are performed
Hardware DRBG (CTR_DRBG) N/A KAT
HMAC-SHA-1, HMAC-SHA-256,
HMAC-SHA-512
N/A KAT25
ECDSA SIG(ver),
SIG(gen)
PCT
EC Diffie-Hellman “Z” computation N/A KAT
Table 13: Apple Secure Key Store v9.0 Cryptographic Algorithm Tests
Software / Firmware Integrity Tests
A software integrity test is performed on the runtime image of the Apple iPad and iPhone
Mobile Devices with iOS 12. The module’s HMAC-SHA-256 is used as a FIPS approved
algorithm for the integrity test. If the test fails, then the device powers itself off.
Critical Function Tests
No other critical function test is performed on power up.
Conditional Tests
The following sections describe the conditional tests supported by the Apple iPad and iPhone
Mobile Devices with iOS 12.
• Pair-wise Consistency Test
The Apple iPad and iPhone Mobile Devices with iOS 12 perform pair-wise
consistency tests on asymmetric keys generated for ECDSA cipher.
• SP 800-90A Assurance Tests
The Apple iPad and iPhone Mobile Devices with iOS 12 perform a subset of the
assurance tests as specified in section 11 of SP 800-90A, in particular it complies
with the mandatory documentation requirements and perform known-answer tests
and prediction resistance.
• Critical Function Test
No other critical function test is performed conditionally
8.8 TOE Access (FTA)
8.8.1 Session Locking
iOS devices can be configured to transit to a locked state after a configurable time interval of
inactivity. This time can be defined by an administrator using a Configuration Profile.
Displaying notifications when in the locked state can be prohibited via the
allowLockScreenNotificationsView key in the Restrictions Payload of a Configuration Profile.
24 Self-test is subject to the "selector" approach for the different implementations of AES.
25 Self-test is subject to the "selector" approach for the different implementations of SHA.
VID: 10937
Page 158 of 172 © 2019 Apple Inc. Version: 1.6
8.8.2 Restricting Access to Wireless Networks
Users and administrators can restrict the wireless networks an iOS device connects to. Using
the Configuration Profile administrators can define the wireless networks the device is
allowed to connect to and the EAP types allowed for authentication. This also includes the
following attributes.
• Specification of the CA(s) from which the TSF will accept WLAN authentication server
certificates(s)
• Security type
• Authentication protocol
• Client credentials to be used for authentication
For the list of radios supported by each device see Table 1: Devices Covered by the
Evaluation. The standards listed there define the frequency ranges.
8.8.3 Lock Screen / Access Banner Display
An advisory warning message regarding unauthorized use of the TOE can be defined using
an image that is presented during the lock screen. Configuration for this is described in
FMT_SMF_EXT.1.1 Function 36.
Since the banner is an image there are no character limitations, information is restricted to
what can be included in an image appropriate to the device display.
8.9 Trusted Path/Channels (FTP)
The TOE provides secured (encrypted and mutually authenticated) communication channels
between itself and other trusted IT products through the use of 802.11-2012, 802.1X, EAP-
TLS, TLS, and IPsec.
Protocol ST requirements Used for
802.11-2012 FTP_ITC_EXT.1.1(1) {MDF} {VPN}
FTP_ITC_EXT.1.1(3) {WLAN}
Wireless access points
802.1X FTP_ITC_EXT.1.1(1) {MDF} {VPN}
FTP_ITC_EXT.1.1(3) {WLAN}
WLAN
EAP-TLS FTP_ITC_EXT.1.1(1) {MDF} {VPN}
FTP_ITC_EXT.1.1(3) {WLAN}
WLAN
TLS 1.0 FCS_TLSC_EXT.1.1 {WLAN} Secure data transfer
TLS 1.1 FCS_TLSC_EXT.1.1 {WLAN} Secure data transfer
TLS 1.2 FCS_TLSC_EXT.1.1 {MDF}
FCS_TLSC_EXT.1.1 {WLAN}
Secure data transfer
IPsec FTP_ITC_EXT.1.1(1) {MDF} {VPN}
FCS_IPSEC_EXT.1 Extended:
IPsec
VPN
Bluetooth
4.0, 4.2 and
5.0
FDP_UPC_EXT.1.1 {MDF} Trusted IT products
HTTPS FCS_HTTPS_EXT.1.1 {MDF}
FDP_UPC_EXT.1.1 {MDF}
FTP_ITC_EXT.1.1(1) {MDF} {VPN}
FTP_ITC_EXT.1.1(2) {AGENT}
OTA updates;
secure communication over a
network
Table 14: Protocols used for trusted channels
VID: 10937
Page 159 of 172 © 2019 Apple Inc. Version: 1.6
IPsec supports authentication using shared keys or certificate-based authentication.
8.9.1 EAP-TLS and TLS
The TOE supports EAP-TLS using TLS version 1.0, TLS 1.1 and TLS 1.2 and supports the
following ciphersuites.
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC5246
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC5246
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC5246
• TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC5246
EAP-TLS can be configured as one of the EAP types accepted using the AcceptEAPTypes
key in the Wi-Fi payload of the Configuration Profile.
When configuring the TOE to utilize EAP-TLS as part of a Wi-Fi Protected Access 2 (WPA2)
protected Wi-Fi-network, the CA certificate(s) to which the server's certificate must chain can
be configured using the PayLoadCertificateAnchorUUID key in the Wi-Fi payload of the
Configuration Profile.
Using the TLSAllowTrustExceptions key in the Wi-Fi payload of the Configuration Profile the
administrator can enforce that untrusted certificates are not accepted and the authentication
fails if such an untrusted certificate is presented.
The TOE provides mobile applications an API service for TLS version 1.2 including support
for following ciphersuites from FCS_TLSC_EXT.1.
• 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_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
In addition to these ciphersuites that have been tested as part of the evaluation, other
ciphersuites are supported by iOS 12. These are listed at
https://developer.apple.com/documentation/security/1550981-ssl_cipher_suite_values?language=objc
Furthermore, the elliptic curve cipher suites above may utilize the following supported elliptic
curve extensions by default.
• secp256r1
• secp384r1
Additional supported elliptic curve extensions below are also enabled by iOS and may be
disabled in the Operational Environment.
• x25519
When an application uses the provided APIs to attempt to establish a trusted channel, the
TOE will compare the DN contained within the peer certificate (specifically the Subject CN, as
well as any Subject Alternative Name fields, IP Address, or Wildcard certificate if applicable)
to the DN of the requested server. If the DN in the certificate does not match the expected DN
for the peer, then the application cannot establish the connection.
Applications can request from the TOE the list of ciphersuites supported and then define
which of the supported ciphersuites they enable for the TLS protected session they are going
to set up. Once the connection has been set up the application can retrieve the ciphersuite
negotiated with the communication partner.
VID: 10937
Page 160 of 172 © 2019 Apple Inc. Version: 1.6
When setting up a TLS session, the library function for the handshake (SSLHandshake) will
indicate, via a result code, any error that occurred during the certificate chain validation.
Communication between the Agent and the MDM Server is protected by TLS using the above
supported cipher specifications.
Certificate pinning is supported and is described in [HTTPSTN2232]. The user of the TLS
framework can use this certificate pinning support. However, existing TLS clients in the TOE,
such as the Safari browser, do not support certificate pinning.
8.9.2 Bluetooth
The TOE supports Bluetooth (4.0, 4.2 and 5.0) with the following Bluetooth profiles.
• Hands-Free Profile (HFP 1.6)
• Phone Book Access Profile (PBAP)
• Advanced Audio Distribution Profile (A2DP)
• Audio/Video Remote Control Profile (AVRCP 1.4)
• Personal Area Network Profile (PAN)
• Human Interface Device Profile (HID)
• Message Access Profile (MAP)
Users can pair their device with a remote Bluetooth device using the 'Set up Bluetooth
Device' option from the Bluetooth status menu. They can also remove a device from the
device list.
Manual authorization is implicitly configured since pairing can only occur when explicitly
authorized through the Settings»Bluetooth interface. During the pairing time, another device
(or the iOS) can send a pairing request. Commonly, a six-digit number is displayed on both
sides which must be manually matched by a user, i.e. the PIN is shown and the user must
accept it before the pairing completes. If one device does not support this automatic
exchange of a PIN, a window for entering a manual PIN is shown. That PIN must match on
both sides.
iOS requires that remote Bluetooth devices support an encrypted connection. Devices that
want to pair with the TOE via Bluetooth are required by Apple to use Secure Simple Pairing,
which uses ECDH based authentication and key exchange. See the Specification of the
Bluetooth System [BT] for details. No data can be transferred via Bluetooth until pairing has
been completed.
The only time the device is Bluetooth discoverable is when the Bluetooth configuration panel
is active and in the foreground (there is no toggle switch for discoverable or not
discoverable—unless the configuration panel is the active panel, the device is not
discoverable).
Connections via Bluetooth/LE are secured using AES-CTR-128 with CBC-MAC (CCM) mode.
A local database is kept of all Bluetooth device addresses for paired devices which is
checked prior to any automatic connection attempt. Additionally, Bluetooth devices may not
establish more than one connection. Multiple connection attempts from the same BD_ADDR
for an established connection will be discarded. For details of the security of Bluetooth/LE see
the Specification of the Bluetooth System [BT].
iOS supports L2CAP through an API in the IOBluetoothDevice class.
An RFCOMM channel object can be obtained by opening an RFCOMM channel in a device,
or by requesting a notification when a channel is created (this is commonly used to provide
services). See the IOBluetooth RFCOMMChannel class.
8.9.3 Wireless LAN
The TOE implements the wireless LAN protocol as defined in IEEE 802.11 (2012). The TOE
uses the random number generators of the CoreCrypto cryptographic modules for the
generation of keys and other random values used as part of this protocol.
VID: 10937
Page 161 of 172 © 2019 Apple Inc. Version: 1.6
As required by IEEE 802.11 (2012), the TOE implements the CTR with CBC-MAC protocol
(CCMP) with AES (128-bit key) as defined in section 11.4.3 of 802.11. This protocol is
mandatory for IEEE 802.11 (2012) and is also the default protocol for providing confidentiality
and integrity for wireless LANs that comply with IEEE 802.11. The implementation of the AES
algorithm is performed by the bulk encryption operation of the WLAN chip.
AES key wrapping as defined in NIST SP 800-38F is used to wrap the Group Temporal Key
(GTK), which is sent in an Extensible Authentication Protocol (EAPOL) key frame in message
three of the 4-way handshake defined in section 11.6.2 of IEEE 802.11 (2012).
AES key unwrapping is performed as described in NIST SP 800-38F section 6.1, Algorithm 2:
W^-1(C), and in section 6.2, Algorithm 4: KW-AD(C).
Processor Device Name Model Number Wi-Fi Alliance
A8
iPhone 6
A1549 WFA55892 / WFA55890
A1586 WFA55892 / WFA55890
A1589 WFA55892 / WFA55890
iPhone 6 Plus
A1522 WFA55891 / WFA55893
A1524 WFA55891 / WFA55893
A1593 WFA55891 / WFA55893
iPad mini 4
A1538 WFA61719
A1550 WFA61719
A8X iPad Air 2
A1566 WFA56012 / WFA56011
A1567 WFA56012 / WFA56011
A9
iPhone 6s
A1633 WFA60693
A1688 WFA60693
A1691 WFA60693
A1700 WFA60693
iPhone 6s Plus
A1634 WFA60694
A1687 WFA60694
A1690 WFA60694
A1699 WFA60694
iPhone SE
A1662 WFA64671 / WFA64670
A1723 WFA64671 / WFA64670
A1724 WFA64671 / WFA64670
iPad 9.7-inch
(5th
generation)
A1822 WFA70147 / WFA70146
A1823 WFA70147 / WFA70146
A9X
iPad Pro 9.7-inch
A1673 WFA64673 / WFA64672
A1674 WFA64673 / WFA64672
A1675 WFA64673 / WFA64672
iPad Pro 12.9-inch
A1584 WFA61740 / WFA61525
A1652 WFA61740 / WFA61525
A10 Fusion iPhone 7
A1660 WFA66686 / WFA66689
A1779 WFA66686 / WFA66689
VID: 10937
Page 162 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model Number Wi-Fi Alliance
A1780 WFA66686 / WFA66689
A1778 WFA66686 / WFA66689
iPhone 7 Plus
A1661 WFA66691 / WFA66687
A1785 WFA66691 / WFA66687
A1786 WFA66691 / WFA66687
A1784 WFA66691 / WFA66687
iPad 9.7-inch
(6th
generation)
A1893 WFA76394 / WFA76387
A1954 WFA76394 / WFA76387
A10X
Fusion
iPad Pro
12.9-inch
(2nd
generation)
A1670 WFA70412 / WFA70651
A1671 WFA70412 / WFA70651
A1821 WFA70412 / WFA70651
iPad Pro
10.5-inch
A1701 WFA70413 / WFA70652
A1709 WFA70413 / WFA70652
A1852 WFA70413 / WFA70652
A11 Bionic
iPhone 8
A1863 WFA72374 / WFA72354
A1906 WFA72374 / WFA72354
A1907 WFA72374 / WFA72354
A1905 WFA72374 / WFA72354
iPhone 8 Plus
A1864 WFA72375 / WFA72355
A1898 WFA72375 / WFA72355
A1899 WFA72375 / WFA72355
A1897 WFA72375 / WFA72355
iPhone X
A1865 WFA72376 / WFA72356
A1902 WFA72376 / WFA72356
A1903 WFA72376 / WFA72356
A1901 WFA72376 / WFA72356
A12 Bionic
iPhone XS
A1920 WFA 77787
A2097 WFA 77787
A2098 WFA 77787
A2099 WFA 77787
A2100 WFA 77787
iPhone XS Max
A1921 WFA 78758
A2101 WFA 78758
A2102 WFA 78758
A2103 WFA 78758
A2104 WFA 78758
iPhone XR
A1984 WFA 77788
A2105 WFA 77788
VID: 10937
Page 163 of 172 © 2019 Apple Inc. Version: 1.6
Processor Device Name Model Number Wi-Fi Alliance
A2106 WFA 77788
A2107 WFA 77788
A2108 WFA 77788
A12X
Bionic
11-inch iPad Pro
A1934 WFA 78760
A1979 WFA 78760
A1980 WFA 78760
A2013 WFA 78760
12.9 inch iPad Pro
A2014 WFA 77796
A1876 WFA 77796
A1895 WFA 77796
A1983 WFA 77796
Table 15: WiFi Alliance certificates
Additionally, PRF-384 is implemented as defined in IEEE 802.11-2012, "Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Specifications", section 11.6.1.2. It
is implemented in the TOE as part of the WPA implementation and is used for the key
generation of AES keys when the Counter Mode CBC-MAC Protocol (CCMP) cipher (defined
in section 11.4.3.1 of IEEE 802.11-2012) is used.
The Random Bit Generator used is the one provided by the main device.
8.9.4 VPN
8.9.4.1 AlwaysOn VPN
For managed and supervised devices, the TOE must be configured with an 'AlwaysOn' VPN
where the organization has full control over device traffic by tunneling all IP traffic back to the
organization using an Internet Key Exchange (IKE) v2 based IPsec tunnel. A specific set of
configuration key values dedicated to the VPN type 'AlwaysOn' allows the specification of the
interfaces (cellular or Wi-Fi) for which the VPN is 'AlwaysOn' (default is: for both), the
specification of exceptions from this service (only VoiceMail and AirPrint can be listed as
exceptions), and the definition of exceptions for Captive networking (if any).
Note: Captive networks are also known as "subscription" or "Wi-Fi Hotspot" networks. These
are often found in public locations.
For IKEv2 the configuration contains the following (among other items).
• The IP address or hostname of the VPN server
• The identifier of the IKEv2 client in one of the supported formats
• The authentication method (shared key or certificate)
• The server certificate (for certificate-based authentication)
• If extended authentication is enabled
• The encryption algorithm (allows for AES-128, AES-256 (default), AES-128-GCM and
AES-256-GCM. Single DES and 3DES shall not be used in the evaluated
configuration.)
• The integrity algorithm (allows for SHA1-96, SHA1-160, SHA-2-256 (default), SHA2-
384, SHA2-512. SHA1-96 shall not be used in the evaluated configuration).
VID: 10937
Page 164 of 172 © 2019 Apple Inc. Version: 1.6
8.9.4.2 IPsec General
IPsec is implemented in the TOE natively, as part of iOS, hence the packets are processed
by the TOE. Packets are processed in little-endian order. There is no separate “client”
application; the VPN tunnels are configured and controlled by Network Extension Framework,
which is a part of the host operating system’s Core OS Layer.
The TOE implements the IPsec protocol as specified in RFC 4301. Configuration of VPN
connection setting, such as, authentication method and algorithm selection, is performed by
the IPsec VPN client administrator.
The TOE enforces an “always on” configuration meaning that all traffic entering and leaving
the TOE platform interfaces is protected via an IPsec VPN connection. The TOE allows a
limited number of services to be configured to either not allow (DISCARD) or be sent plaintext
(BYPASS). These services include applications that make use of Captive Networking
Identifiers, Voice Mail, Cellular Services and AirPrint. All other communications are always
sent through the IPsec tunnel (PROTECT within the Security Policy Database (SPD)). In
order to set a service to match a PROTECT rule in the SPD, select “Allow traffic via tunnel.”
“Drop Traffic” will cause that traffic to match a DISCARD rule. “Allow traffic outside tunnel” will
create a BYPASS rule for that service.
The SPD is implemented by the TOE, which as a managed device is configured using a
Configuration Profile either manually, through the Apple Configurator 2, or via an MDM
solution. See section 8.6.2, Configuration Profiles for more information.
All data (other than that described in 8.9.4.3 IPsec Characteristics) is sent through the
encrypted tunnel. Any other plaintext data that is received is ignored. This happens
automatically without the need to configure an explicit discard.
The VPN payload, described in [IOS_CFG] specifies how a packet is processed against the
SPD and includes IPsec Dictionary Keys, IKEv2 Dictionary Keys, DNS Dictionary Keys,
Proxies Dictionary Keys, and AlwaysOn Dictionary Keys.
In the evaluated configuration, a catch-all value must be set.
8.9.4.3 IPsec Characteristics
The TOE platform supports the following IPsec connection characteristics:
• IKEv2 (as defined in RFCs 7296 and 4307),
• Tunnel Mode,
• Symmetric algorithms for IKE and ESP encryption (AES-GCM-128, AES-GCM-256,
AES-CBC-128, and AES-CBC-256),
• Integrity mechanisms (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-
SHA-512),
• Key Exchange (Diffie-Hellman Groups):
o 5(1536-bit MODP),
o 14(2048-bit MODP),
o 15(3072-bit MODP),
o 19(256-bit Random ECP), and
o 20 (384-bit Random ECP).
Each of these cryptographic mechanisms are provided by one of the following two
cryptographic modules, Apple CoreCrypto Kernel Cryptographic Module for ARM or Apple
CoreCrypto Cryptographic Module for ARM.
The key generation and key establishment for VPN are handled in the user space, while the
bulk encryption is handled in the kernel space.
VID: 10937
Page 165 of 172 © 2019 Apple Inc. Version: 1.6
8.9.4.4 Peer authentication
The supported peer authentication mechanisms, include, RSA or ECDSA X.509v3 digital
certificate authentication.
As part of the peer authentication process, a comparison is made of the distinguished name
(DN) contained within the peer certificate (specifically the Subject CN, as well as any Subject
Alternative Name fields) to the DN of the requested server. If the DN in the certificate does
not match the expected DN for the peer, then the session will not be established.
If a subject alternative name (SAN) is present in the certificate, its contents takes precedence
over the DN entry. If the SAN does not match that of the peer's identifier, the authentication
process fails. If the SAN matches the peer's identifier, the authentication process is
successful. Only if the SAN is not present, the DN of the certificate is applied.
8.9.4.5 IKE
In the evaluated configuration, the TOE does not support IKEv1. The TOE only supports
IKEv2.
The TOE supports configurable time-based lifetimes for both IKEv2 Phase 1 and Phase 2
SAs. Phase 1 SAs are configurable to 24 hours and phase 2 SAs are configurable to 8 hours.
Configuration settings are applied to the TOE via .xml profiles. These profiles can be
generated via an MDM, an iOS specific tool such as “Apple Configurator 2,” or by manually
editing the .xml file directly.
The TOE generates the secret value ‘x’ and nonces used in the IKEv2 Diffie-Hellman key
exchanges using the TOE platform CAVP validated DRBG specified (as specified in
FCS_RBG_EXT.1). The possible lengths of ‘x’ and the nonces are 224, 256, or 384 bits.
The strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated
to protect the IKEv2/IKE_SA connection and the strength of the symmetric algorithm
negotiated to protect the IKEv2 CHILD_SA connection is configured using .xml configuration
files. The administrator must explicitly choose the cryptographic algorithms (including key
strength) used for each SA. Key strength must be one of 128 or 256 bits as specified in the
IKEv2 Dictionary Keys, EncryptionAlgorithm Key.
In the evaluated configuration, during negotiation the TOE will only negotiate the configured
algorithms which must include an IKEv2/IKE_SA at least that of IKEv2 CHILD_SA. This
configuration is specified in [CC_GUIDE].
8.10 Security Audit (FAU)
8.10.1 Audit Records
iOS logging capabilities are able to collect a wide array of information concerning TOE usage
and configuration. The available commands and responses constitute audit records and must
be configured by TOE administrators using profiles that are further explained in section 8.6.2.
These profiles must also be used to determine the audit storage capacity as well as default
action when capacity is reached.
Although the specific audit record format is determined via Configuration Profile, the following
attributes form the baseline:
• Date and time the audit record was generated
• Process ID or information about the cause of the event
• Information about the intended operation
• Success or failure (where appropriate)
Audit record information is not available to TOE users or administrators on TOE devices and
is only accessible externally on trusted workstations via the Apple Configurator 2 or to an
MDM server on enrolled devices.
Depending on the underlying OS of the trusted workstation or MDM server, the audit records
are transferred to the following locations.
VID: 10937
Page 166 of 172 © 2019 Apple Inc. Version: 1.6
• macOS
o ~/Library/Logs/CrashReporter/MobileDevice/[Your_Device_Name]/
• Windows
o C:\Users\[Your_User_Name]\AppData\Roaming\Apple
Computer\Logs\CrashReporter\MobileDevice\[Your_Device_Name]\
8.10.2 MDM Agent Alerts
The MDM agent generates and sends an alert in response to an MDM server request (i.e.,
applying a policy, receiving a reachability event). The Status key field in Table 9: Wi-Fi CAVS
Certificates is used as the alert message to satisfy the FAU_ALT_EXT.2 requirements. The
MDM Agent's response is being used as the alert transfer mechanism.
When a Configuration Profile is sent to an MDM Agent, the MDM Agent responds using an
"Alert", the MDM Result Payload, a plist-encoded dictionary containing the following keys, as
well as other keys returned by each command.
Key Type Content
Status String Status. Legal values are described as:
Status value Description
Acknowledged Everything went well.
Error An error has occurred. See the
ErrorChain for details.
CommandFormatError A protocol error has occurred.
The command may be
malformed.
Idle The device is idle (there is no
status).
NotNow The device received the
command but cannot perform it
at this time. It will poll the
server again in the future.
UDID String UDID of the device
CommandUUID String UUID of the command that this response is for (if any)
ErrorChain Array Optional—Array of dictionaries representing the chain of
errors that occurred
Table 16: MDM Agent Status Commands
During installation:
• The user or administrator tells the device to install an MDM payload. The structure of
this payload is described in the Structure of MDM Payloads section of [iOS_MDM].
• The device connects to the check-in server. The device presents its identity certificate
for authentication, along with its UDID and push notification topic.
Note: Although UDIDs are used by MDM, the use of UDIDs is deprecated for iOS apps.
If the server accepts the device, the device provides its push notification device token to the
server. The server should use this token to send push messages to the device. This check-in
message also contains a PushMagic string. The server must remember this string and
include it in any push messages it sends to the device.
During normal operation:
VID: 10937
Page 167 of 172 © 2019 Apple Inc. Version: 1.6
• The server (at some point in the future) sends out a push notification to the device.
• The device polls the server for a command in response to the push notification.
• The device performs the command.
• The MDM Agent contacts the server to report the result of the last command and to
request the next command.
From time to time, the device token may change. When a change is detected, the device
automatically checks in with the MDM Server to report its new push notification token.
Note: The device polls only in response to a push notification; it does not poll the server
immediately after installation. The server must send a push notification to the device to begin
a transaction.
The MDM Agent initiates communication with the MDM Server in response to a push
notification by establishing a TLS connection to the MDM Server URL. The MDM Agent
validates the server's certificate, and then uses the identity specified in its MDM payload as
the client authentication certificate for the connection.
When an MDM Server wants to communicate with iPhone or iPad, a silent notification is sent
to the MDM Agent via the Apple Push Notification (APN) service, prompting it to check in with
the server. The process of notifying the MDM Agent does not send any proprietary
information to or from the APNS. The only task performed by the push notification is to wake
the device so it checks in with the MDM Server.
8.10.2.1 Queuing of Alerts
In cases where the TLS channel is unavailable, for example because the device is out of
range of a suitable network, an alert in regard to the successful installation of policies is
queued until the device is able to communicate with the server again. The queue cannot
become long, because if the device is out of communication with the MDM server no
additional requests can be received. If the MDM Server does not receive the alert, the MDM
Server should re-initiate the transfer until a response is received from the device.
There are certain times when the device is not able to do what the MDM Server requests. For
example, databases cannot be modified while the device is locked with Data Protection.
When a device cannot perform a command due to these types of situations, it will send the
NotNow status without performing the command. The server may send another command
immediately after receiving this status, but chances are the following command will also be
refused.
After sending a NotNow status, the device will poll the server at some future time. The device
will continue to poll the server until a successful transaction is completed.
The device does not cache the command that was refused. If the server wants the device to
retry the command, it must send the same command again later, when the device polls the
server.
The server does not need to send another push notification in response to this status.
However, the server may send another push notification to the device to have it poll the
server immediately.
The following commands are guaranteed to execute on iOS, and never return NotNow.
• DeviceInformation
• ProfileList
• DeviceLock
• EraseDevice
• ClearPasscode
• CertificateList
• ProvisioningProfileList
VID: 10937
Page 168 of 172 © 2019 Apple Inc. Version: 1.6
• InstalledApplicationList
• Restrictions
8.10.2.2 Alerts on successful application of policies
Candidate policies are generated by the administrator and disseminated as a Configuration
Profile using one of the methods already described in section 8.6.2 above.
The protocol for managing Configuration Profiles between the MDM Server and the MDM
Agent is defined by the MDM Protocol [iOS_MDM].
When the application of policies to a mobile device is successful the MDM Agent replies with
an MDM Result Payload with Status value "Acknowledged".
If a policy update is not successfully installed then the MDM Agent replies with an MDM
Result Payload with Status value "Error" or CommandFormatError, "Idle" and "NotNow".
8.10.2.3 Alerts on receiving periodic reachability events
Periodic reachability events are initiated by the MDM Server using Push Notifications. When a
periodic reachability event is received the MDM Agent contacts the server in the manner
described in section 8.10.1, above.
8.11 Inventory of TSF binaries and libraries
A proprietary inventory was provided to NIAP in support of the Assurance Activity for
FPT_AEX_EXT.3.
VID: 10937
Page 169 of 172 © 2019 Apple Inc. Version: 1.6
Abbreviations and Acronyms
A2DP Advanced Audio Distribution Profile
ACL Access Control List
AES Advanced Encryption Standard
API Application Programmer Interface
APN Apple Push Notification
APNS Apple Push Notification Service
ARC Advanced Reference Counting
ARM Advanced RISC Machine
ASLR Address Space Layout Randomization
AVRCP Audio/Video Remote Control Profile
BAF Biometric Authentication Factors
BR/EDR Basic Rate/Enhanced Data Rate
CAVS Cryptographic Algorithm Validation System
CBC Cypher Block Chaining
CC Common Criteria
CCM Counter with CBC-MAC
CCMP Counter Mode CBC-MAC Protocol
CDMA Code Division Multiple Access
CN Common Name
CTR Counter
CVE Common Vulnerabilities and Exposures
DAR Data-at-Rest
DC-HSDPA Dual-Carrier High Speed Packet Access
DEK Data Encryption Key
DEP Device Enrollment Program
DES Data Encryption Standard
DFU Device Firmware Upgrade
DH Diffie-Hellman
DMA Direct Memory Access
DN Distinguished Name
DNS Domain Name Server
DRBG Deterministic Random Bit Generator
DRNG Deterministic Random Number Generator
EAL Evaluation Assurance Level
EAP Extensible Authentication Protocol
EAPOL Extensible Authentication Protocol Over LAN
VID: 10937
Page 170 of 172 © 2019 Apple Inc. Version: 1.6
EAP-TLS Extensible Authentication Protocol Transport Layer Security
EAR Entropy Assessment Report
EC Elliptic Curve
ECB Electronic Codebook
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signal Algorithm
ECID Electronic Chip Identification
EDGE Enhanced Data rates for GSM Evolution
EP Extended Package (for a Protection Profile)
EV-DO Evolution-Data Optimized
FAR False Acceptance Rate
FDD-LTE Frequency-Division Duplex-Long Term Evolution
FIA Identification and Authentication
FIPS Federal Information Processing Standard
GCM Galois/Counter Mode
GID Group Key
GPS Global Positioning Satellites
GSM Global System for Mobile Communication
GTK Group Temporal Key
HFP Hands-Free Profile
HID Human Interface Device Profile
HMAC Keyed-hash Message Authentication Code
HSPA+ High Speed Packet Access Plus
IKE Internet Key Exchange
IOMMU input–output memory management unit
IPsec Internet Protocol Security
IV Initialization Vector
JSON JavaScript Object Notation
JTAG Joint Test Action Group
KAT Known Answer Test
KDF Key Derivation Function
KEK Key Encryption Key
KW Key Wrap
LE Low Energy
LLB Low-Level Bootloader
LTE Long Term Evolution
VID: 10937
Page 171 of 172 © 2019 Apple Inc. Version: 1.6
MAC Message Authentication Code
MAP Message Access Profile
MD Mobile Device
MDF Mobile Device Fundamentals
MDFPP Mobile Device Fundamentals Protection Profile
MDM Mobile Device Management
MMI Man-Machine Interface
MMU Memory Management Unit
NDRNG Non-deterministic Random Number Generator
NFC Near Field Communication
NITZ Network, Identity and Time Zone
NTP Network Time Protocol
OCSP Online Certificate Status Protocol
OSP Organizational Security Policy
OTA Over-the-Air
PAA Processor Algorithm Accelerator
PAE Port Access Entity
PAN Personal Area Network Profile
PBAP Phone Book Access Profile
PBKDF Password-Based Key Derivation Function
PHY Physical Layer
PKCS Public Key Cryptography Standards
PP Protection Profile
PRF Pseudorandom Function
RBG Random Bit Generator
REK Root Encryption Key
RFC Request for Comment
RISC Reduced Instruction Set Computing
RSA Rivest-Shamir-Adleman
S/MIME Secure/Multipurpose Internet Mail Extensions
SA Security Association
SAFAR System Authentication False Acceptance Rate
SAN Subject Alternative Name
SAR Security Assurance Requirement
SCEP Simple Certificate Enrollment Protocol
SDIO Secure Digital Input Output
SEP Secure Enclave Processor
VID: 10937
Page 172 of 172 © 2019 Apple Inc. Version: 1.6
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SHS Secure Hash Standard
SIG Signature
SKS Secure Key Store
SP Special Publication
SP Security Policy
SPD Security Policy Database
SSID Service Set Identifier
SSL Secure Sockets Layer
ST Security Target
TD-LTE Time Division Long-Term Evolution
TD-SCDMA Time Division Synchronous Code Division Multiple Access
TLS Transport Layer Security
TOE Target of Evaluation
TRNG True Random Number Generators
TSF TOE Security Functionality
TSS TOE Summary Specification
UI User Interface
UMTS Universal Mobile Telecommunications System
USSD Unstructured Supplementary Service Data
UID Unique ID
UUID Universally Unique ID
VNG Vector Next Generation
VPN Virtual Private Network
VPP Volume Purchase Program
WLAN Wireless Local Area Network
WPA2 Wi-Fi Protected Access 2
XN Execute Never
XEX Xor-encrypt-xor
XTS XEX-based tweaked-codebook mode with ciphertext stealing