Apple Inc. © 2022 Apple Inc. This document may be reproduced and distributed only in its original entirety without revision Apple iPadOS 15: iPads Security Target PP_MDF_V3.2 with MOD_MDM_AGENT_V1.0, MOD_BT_V1.0, MOD_VPNC_V2.3, PP_WLAN_CLI_EP_V1.0, PKG_TLS_V1.1 Version 1.2 2022-09-29 VID: 11238 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: 11238 Page 2 of 208 © 2022 Apple Inc. Version: 1.2 Table of Contents Revision History........................................................................................................................................... 10 Trademarks.................................................................................................................................................... 11 1 Security Target Introduction ........................................................................................................... 12 1.1 Security Target Reference ............................................................................................................. 12 1.2 TOE Reference................................................................................................................................... 12 1.3 TOE Overview..................................................................................................................................... 12 1.4 TOE Description................................................................................................................................. 13 1.4.1 General information............................................................................................................ 13 1.4.2 Obtaining the mobile devices......................................................................................... 14 1.4.3 Obtaining software updates............................................................................................ 14 1.4.4 Supervising and configuring the mobile devices.................................................... 14 1.4.5 Mobile devices covered by this evaluation............................................................... 15 1.5 TOE Architecture................................................................................................................................ 15 1.5.1 Physical Boundaries .......................................................................................................... 17 1.5.2 Security Functions provided by the TOE................................................................... 17 1.5.3 TOE Documentation .......................................................................................................... 23 1.5.4 Other References................................................................................................................ 25 2 Conformance Claims.......................................................................................................................... 29 2.1 CC Conformance ............................................................................................................................... 29 2.2 Protection Profile (PP) Conformance......................................................................................... 29 2.2.1 Technical Decisions (TDs) .............................................................................................. 30 2.3 Conformance Rationale................................................................................................................... 32 3 Security Problem Definition............................................................................................................. 33 3.1 Threats................................................................................................................................................... 33 3.2 Assumptions......................................................................................................................................... 35 3.3 Organizational Security Policies .................................................................................................. 37 4 Security Objectives ............................................................................................................................. 38 4.1 Security Objectives for the TOE................................................................................................... 38 4.2 Security Objectives for the TOE Environment........................................................................ 41 5 Extended Components Definition................................................................................................. 43 6 Security Functional Requirements............................................................................................... 44 6.1 Security Audit (FAU)......................................................................................................................... 45 Agent Alerts (FAU_ALT)............................................................................................................................. 45 FAU_ALT_EXT.2 Agent Alerts..................................................................................................... 45 Audit Data Generation (FAU_GEN)....................................................................................................... 45 VID: 11238 Page 3 of 208 © 2022 Apple Inc. Version: 1.2 FAU_GEN.1 Audit Data Generation........................................................................................... 45 FAU_GEN.1(2) Audit Data Generation..................................................................................... 48 FAU_GEN.1/BT Audit Data Generation (Bluetooth)............................................................ 49 Security Audit Event Selection (FAU_SEL)........................................................................................ 50 FAU_SEL.1(2) Security Audit Event Selection ...................................................................... 50 Security Audit Event Storage (FAU_STG).......................................................................................... 51 FAU_STG.1 Audit Storage Protection....................................................................................... 51 FAU_STG.4 Prevention of Audit Data Loss............................................................................ 51 6.2 Cryptographic Support (FCS) ....................................................................................................... 52 Cryptographic Key Management (FCS_CKM).................................................................................. 52 FCS_CKM.1 Cryptographic Key Generation.......................................................................... 52 FCS_CKM.1/WLAN Cryptographic Key Generation (Symmetric Keys for WPA2 Connections)......................................................................................................................... 52 FCS_CKM.1/VPN Cryptographic Key Generation (IKE).................................................... 52 FCS_CKM.2/UNLOCKED Cryptographic Key Establishment ......................................... 52 FCS_CKM.2/LOCKED Cryptographic Key Establishment................................................ 53 FCS_CKM.2/WLAN WLAN Cryptographic Key Distribution (GTK)............................... 53 FCS_CKM_EXT.1 Cryptographic Key Support (REK)........................................................ 53 FCS_CKM_EXT.2 Cryptographic Key Random Generation............................................ 54 FCS_CKM_EXT.3 Cryptographic Key Generation............................................................... 54 FCS_CKM_EXT.4 Key Destruction............................................................................................ 54 FCS_CKM_EXT.5 TSF Wipe........................................................................................................ 55 FCS_CKM_EXT.6 Salt Generation ............................................................................................ 55 FCS_CKM_EXT.7 Cryptographic Key Support (REK)........................................................ 55 FCS_CKM_EXT.8 Bluetooth Key Generation........................................................................ 55 Cryptographic Operations (FCS_COP)................................................................................................ 56 FCS_COP.1/ENCRYPT Cryptographic Operation............................................................... 56 FCS_COP.1/HASH Cryptographic Operation........................................................................ 56 FCS_COP.1/SIGN Cryptographic Operation.......................................................................... 56 FCS_COP.1/KEYHMAC Cryptographic Operation.............................................................. 56 FCS_COP.1/CONDITION Cryptographic Operation........................................................... 57 HTTPS Protocol (FCS_HTTPS).............................................................................................................. 57 FCS_HTTPS_EXT.1 HTTPS Protocol ...................................................................................... 57 IPsec Protocol (FCS_IPSEC)................................................................................................................... 57 FCS_IPSEC_EXT.1 IPsec ............................................................................................................. 57 Initialization Vector Generation (FCS_IV) ........................................................................................... 59 FCS_IV_EXT.1 Initialization Vector Generation.................................................................... 59 Random Bit Generation (FCS_RBG).................................................................................................... 59 FCS_RBG_EXT.1(Kernel and User space) Random Bit Generation........................... 59 FCS_RBG_EXT.1(SEP) Random Bit Generation ................................................................ 59 Cryptographic Algorithm Services (FCS_SRV)................................................................................. 60 FCS_SRV_EXT.1 Cryptographic Algorithm Services......................................................... 60 VID: 11238 Page 4 of 208 © 2022 Apple Inc. Version: 1.2 Cryptographic Key Storage (FCS_STG).............................................................................................. 60 FCS_STG_EXT.1 Cryptographic Key Storage...................................................................... 60 FCS_STG_EXT.2 Encrypted Cryptographic Key Storage................................................ 61 FCS_STG_EXT.3 Integrity of Encrypted Key Storage ....................................................... 61 FCS_STG_EXT.4 Cryptographic Key Storage...................................................................... 61 TLS Protocol (FCS_TLS)........................................................................................................................... 61 FCS_TLS_EXT.1 TLS Protocol.................................................................................................... 61 TLS Client Protocol (FCS_TLSC)........................................................................................................... 62 FCS_TLSC_EXT.1 TLS Client Protocol ................................................................................... 62 FCS_TLSC_EXT.1/WLAN Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).............................................................................................................................. 62 FCS_TLSC_EXT.2 TLS Client Protocol for Mutual Authentication ............................... 63 FCS_TLSC_EXT.4 TLS Client Support for Renegotiation................................................ 63 FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension ................. 63 6.3 User Data Protection (FDP)........................................................................................................... 64 Access Control (FDP_ACF)...................................................................................................................... 64 FDP_ACF_EXT.1 Access Control for System Services .................................................... 64 FDP_ACF_EXT.2 Access Control for System Resources................................................ 64 Data-At-Rest Protection (FDP_DAR).................................................................................................... 64 FDP_DAR_EXT.1 Protected Data Encryption ....................................................................... 64 FDP_DAR_EXT.2 Sensitive Data Encryption ........................................................................ 64 Subset Information Flow Control - VPN (FDP_IFC)........................................................................ 65 FDP_IFC_EXT.1 Subset Information Flow Control.............................................................. 65 FDP_IFC_EXT.1/VPN Subset Information Flow Control (VPN) ..................................... 65 Storage of Critical Biometric Parameters (FDP_PBA)................................................................... 65 FDP_PBA_EXT.1 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).................................................................................................... 66 FDP_STG_EXT.1 User Data Storage....................................................................................... 66 Inter-TSF User Data Protected Channel (FDP_UPC).................................................................... 66 FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection (Applications). 66 FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection (Bluetooth) .................................................................................................................................................... 66 6.4 Identification and Authentication (FIA) ...................................................................................... 67 Authentication Failures (FIA_AFL)......................................................................................................... 67 FIA_AFL_EXT.1 Authentication Failure Handling ................................................................ 67 Bluetooth Authorization and Authentication (FIA_BLT)................................................................. 67 FIA_BLT_EXT.1 Bluetooth User Authorization...................................................................... 67 FIA_BLT_EXT.2 Bluetooth Mutual Authentication ............................................................... 68 FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections.................................... 68 FIA_BLT_EXT.4 Secure Simple Pairing................................................................................... 68 VID: 11238 Page 5 of 208 © 2022 Apple Inc. Version: 1.2 FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization...................................... 68 FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization ................................. 68 Biometric Authentication (FIA_BMG).................................................................................................... 68 FIA_BMG_EXT.1 Accuracy of Biometric Authentication ................................................... 68 FIA_BMG_EXT.2 Biometric Enrollment.................................................................................... 69 FIA_BMG_EXT.3 Biometric Verification................................................................................... 70 FIA_BMG_EXT.5 Handling Unusual Biometric Templates............................................... 70 Enrollment of Mobile Device into Management (FIA_ENR)......................................................... 70 FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management.................... 70 Port Access Entity Authentication (FIA_PAE) ................................................................................... 70 FIA_PAE_EXT.1 PAE Authentication........................................................................................ 70 Password Management (FIA_PMG) ..................................................................................................... 70 FIA_PMG_EXT.1 Password Management.............................................................................. 70 Authentication Throttling (FIA_TRT)...................................................................................................... 71 FIA_TRT_EXT.1 Authentication Throttling.............................................................................. 71 User Authentication (FIA_UAU) .............................................................................................................. 71 FIA_UAU.5 Multiple Authentication Mechanisms ................................................................. 71 FIA_UAU.6 Re-Authentication...................................................................................................... 71 FIA_UAU.7 Protected authentication feedback..................................................................... 71 FIA_UAU_EXT.1 Authentication for Cryptographic Operation........................................ 72 FIA_UAU_EXT.2 Timing of Authentication.............................................................................. 72 X509 Certificates (FIA_X509_EXT)....................................................................................................... 72 FIA_X509_EXT.1 Validation of Certificates ............................................................................ 72 FIA_X509_EXT.1/WLAN X.509 Certificate Validation........................................................ 73 X509 Certificate Authentication (FIA_X509_EXT)........................................................................... 73 FIA_X509_EXT.2 X509 Certificate Authentication............................................................... 73 FIA_X509_EXT.2/WLAN X509 Certificate Authentication (EAP-TLS)......................... 74 Request Validation of Certificates (FIA_X509_EXT)...................................................................... 74 FIA_X509_EXT.3 Request Validation of Certificates.......................................................... 74 6.5 Security Management (FMT) ........................................................................................................ 75 Management of Functions in TSF (FMT_MOF)................................................................................ 75 FMT_MOF_EXT.1 Management of Security Functions Behavior.................................. 75 Trusted Policy Update (FMT_POL) ....................................................................................................... 75 FMT_POL_EXT.2 Agent Trusted Policy Update................................................................... 75 Specification of Management Functions (FMT_SMF).................................................................... 75 FMT_SMF_EXT.1 Specification of Management Functions ............................................ 75 FMT_SMF_EXT.1/BT Specification of Management Functions..................................... 79 FMT_SMF_EXT.1/WLAN Specification of Management Functions (Wireless LAN)79 FMT_SMF.1/VPN Specification of Management Functions (VPN) ............................... 79 FMT_SMF_EXT.2 Specification of Remediation Actions.................................................. 80 FMT_SMF_EXT.4 Specification of Management Functions ............................................ 80 VID: 11238 Page 6 of 208 © 2022 Apple Inc. Version: 1.2 User Unenrollment Prevention................................................................................................................. 80 FMT_UNR_EXT.1 User Unenrollment Prevention............................................................... 80 6.6 Protection of the TSF (FPT) .......................................................................................................... 81 Anti-Exploitation Services (FPT_AEX) ................................................................................................. 81 FPT_AEX_EXT.1 Application Address Space Layout Randomization ........................ 81 FPT_AEX_EXT.2 Memory Page Permissions....................................................................... 81 FPT_AEX_EXT.3 Stack Overflow Protection......................................................................... 81 FPT_AEX_EXT.4 Domain Isolation............................................................................................ 81 JTAG Disablement (FPT_JTA)................................................................................................................ 81 FPT_JTA_EXT.1 JTAG Disablement ........................................................................................ 81 Key Storage (FPT_KST) ............................................................................................................................ 82 FPT_KST_EXT.1 Key Storage..................................................................................................... 82 FPT_KST_EXT.2 No Key Transmission................................................................................... 82 FPT_KST_EXT.3 No Plaintext Key Export.............................................................................. 82 Self-Test Notification (FPT_NOT)........................................................................................................... 82 FPT_NOT_EXT.1 Self-Test Notification................................................................................... 82 Reliable Time Stamps (FPT_STM)........................................................................................................ 82 FPT_STM.1 Reliable Time Stamps............................................................................................ 82 TSF Functionality Testing (FPT_TST).................................................................................................. 82 FPT_TST_EXT.1 TSF Cryptographic Functionality Testing............................................. 82 FPT_TST_EXT.1/VPN TSF Self-Test (VPN Client)............................................................. 83 FPT_TST_EXT.1/WLAN TSF Cryptographic Functionality Testing.............................. 83 TSF Integrity Testing ................................................................................................................................... 83 FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel) ........................ 83 FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel) ................... 83 FPT_TST_EXT.3 TSF Integrity Testing.................................................................................... 83 Trusted Update (FPT_TUD) ..................................................................................................................... 84 FPT_TUD_EXT.1 Trusted Update: TSF Version Query.................................................... 84 Trusted Update Verification (FPT_TUD_EXT).................................................................................. 84 FPT_TUD_EXT.2 Trusted Update Verification...................................................................... 84 FPT_TUD_EXT.3 Application Signing....................................................................................... 84 FPT_TUD_EXT.4 Trusted Update Verification...................................................................... 84 FPT_TUD_EXT.5 Application Verification ............................................................................... 85 FPT_TUD_EXT.6 Trusted Update Verification...................................................................... 85 6.7 TOE Access (FTA) ............................................................................................................................ 86 Session Locking (FTA_SSL) .................................................................................................................... 86 FTA_SSL_EXT.1 TSF and User-initiated Locked State .................................................... 86 Default TOE Access Banners (FTA_TAB).......................................................................................... 86 FTA_TAB.1 Default TOE Access Banners.............................................................................. 86 Wireless Network Access (FTA_WSE) ................................................................................................ 86 FTA_WSE_EXT.1 Wireless Network Access......................................................................... 86 VID: 11238 Page 7 of 208 © 2022 Apple Inc. Version: 1.2 6.8 Trusted Path/Channels (FTP)....................................................................................................... 87 Bluetooth Trusted Channel Communication (FTP_BLT) .............................................................. 87 FTP_BLT_EXT.1 Bluetooth Encryption .................................................................................... 87 FTP_BLT_EXT.2 Persistence of Bluetooth Encryption...................................................... 87 FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR).............................. 87 FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE)........................................... 87 Trusted Channel Communication (FTP_ITC).................................................................................... 87 FTP_ITC_EXT.1 Trusted Channel Communication............................................................. 87 FTP_ITC_EXT.1(2) Trusted Channel Communication....................................................... 88 FTP_ITC_EXT.1/WLAN Trusted Channel Communication (Wireless LAN).............. 88 Trusted Channel Communication (FTP_TRP) .................................................................................. 89 FTP_TRP.1(2) Trusted Path (for Enrollment)......................................................................... 89 6.9 Security Functional Requirements Rationale ......................................................................... 89 7 Security Assurance Requirements............................................................................................... 90 8 TOE Summary Specification (TSS)............................................................................................... 91 8.1 Mapping to the Security Functional Requirements .............................................................. 91 8.2 Hardware Protection Functions..................................................................................................131 8.2.1 The Secure Enclave Processor (SEP).....................................................................131 8.3 Cryptographic Support...................................................................................................................132 8.3.1 Overview of Key Management ....................................................................................132 8.3.2 Storage of Persistent Secrets and Private Keys by the MDM Agent...........136 8.3.3 Randomness extraction and expansion step.........................................................140 8.3.4 Explanation of usage for cryptographic functions................................................141 8.4 User Data Protection (FDP).........................................................................................................147 8.4.1 Protection of Files.............................................................................................................147 8.4.2 Application Access to Files ...........................................................................................147 8.4.3 Declaring the Required Device Capabilities of an Application .......................148 8.4.4 App Groups .........................................................................................................................148 8.4.5 Restricting Applications Access to Services..........................................................148 8.4.6 Keychain Data Protection..............................................................................................149 8.4.7 VPN ........................................................................................................................................150 8.4.8 Keyed Hash.........................................................................................................................150 8.5 Identification and Authentication (FIA) ....................................................................................150 8.5.1 Biometric Authentication ................................................................................................152 8.5.2 X.509v3 Certificates.........................................................................................................154 8.5.3 MDM Server Reference ID............................................................................................156 8.6 Specification of Management Functions (FMT)...................................................................157 8.6.1 Enrollment............................................................................................................................157 8.6.2 Configuration Profiles......................................................................................................157 8.6.3 Biometric Authentication Factors (BAFs) ................................................................160 8.6.4 Unenrollment.......................................................................................................................161 VID: 11238 Page 8 of 208 © 2022 Apple Inc. Version: 1.2 8.6.5 Radios....................................................................................................................................162 8.6.6 Audio and Visual collection devices..........................................................................162 8.6.7 VPN Certificate Credentials..........................................................................................162 8.6.8 Removal of applications.................................................................................................162 8.7 Protection of the TSF (FPT) ........................................................................................................163 8.7.1 Secure Boot.........................................................................................................................163 8.7.2 Joint Test Action Group (JTAG) Disablement.......................................................163 8.7.3 Secure Software Update................................................................................................164 8.7.4 Security Updates...............................................................................................................165 8.7.5 Domain Isolation................................................................................................................165 8.7.6 Device Locking...................................................................................................................166 8.7.7 Time........................................................................................................................................166 8.7.8 Inventory of TSF Binaries and Libraries ..................................................................167 8.7.9 Self-Tests.............................................................................................................................167 8.7.10 Application integrity..........................................................................................................173 8.8 TOE Access (FTA) ..........................................................................................................................173 8.8.1 Session Locking ................................................................................................................173 8.8.2 Restricting Access to Wireless Networks................................................................173 8.8.3 Lock Screen / Access Banner Display .....................................................................173 8.9 Trusted Path/Channels (FTP).....................................................................................................174 8.9.1 EAP-TLS and TLS............................................................................................................174 8.9.2 Bluetooth ..............................................................................................................................176 8.9.3 Wireless LAN (WLAN) ....................................................................................................178 8.9.4 VPN ........................................................................................................................................178 8.10 Security Audit (FAU).......................................................................................................................181 8.10.1 Audit Records.....................................................................................................................181 8.10.2 MDM Agent Alerts.............................................................................................................182 Abbreviations and Acronyms ..............................................................................................................185 Annex A: Devices Covered by this Evaluation.............................................................................191 Annex B: Wi-Fi Alliance Certificates.................................................................................................204 Annex C: Biometric Data........................................................................................................................207 Annex D: Inventory of TSF Binaries and Libraries.....................................................................208 Table of Figures Figure 1: TOE OS layers ...............................................................................................................................................16 Figure 2: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1]18 Figure 3: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] ..........................................................................................................................................................................................19 VID: 11238 Page 9 of 208 © 2022 Apple Inc. Version: 1.2 Figure 4: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] .........................................................................................................................................................20 Figure 5: Key Hierarchy in the TOE OS................................................................................................................138 Table of Tables Table 1: PP conformance and claimed Use Cases............................................................................................29 Table 2: Technical Decision applicability.................................................................................................................32 Table 3: Combined mandatory auditable events from [PP_MDF_V3.2] and [PP_WLAN_CLI_EP_V1.0] ..........................................................................................................................................................................................48 Table 4: Auditable events from [MOD_MDM_AGENT_V1.0].........................................................................49 Table 5: Auditable events from [MOD_BT_V1.0].................................................................................................50 Table 6: Management Functions................................................................................................................................78 Table 7: Mapping of SFR Assurance Activities to the TSS............................................................................130 Table 8: Summary of keys and persistent secrets in the TOE OS.............................................................135 Table 9: Summary of keys and persistent secrets used by the MDM Agent .........................................137 Table 10: Explanation of usage for cryptographic functions in the cryptographic modules ............146 Table 11: Keychain to File-system Mapping........................................................................................................150 Table 12: MDM Server Reference Identifiers......................................................................................................157 Table 13: Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] Cryptographic Algorithm Tests.............................................................................................................................................................................168 Table 14: Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] Cryptographic Algorithm Tests........................................................................................................................................................170 Table 15: Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] Cryptographic Algorithm Tests..........................................................................................................................172 Table 16: Protocols used for trusted channels ...................................................................................................174 Table 17: MDM Agent Status Commands ............................................................................................................183 Table 18: Devices Covered by the Evaluation....................................................................................................203 Table 19: Wi-Fi Alliance certificates ........................................................................................................................206 VID: 11238 Page 10 of 208 © 2022 Apple Inc. Version: 1.2 Revision History Version Date Change 1.2 2022-09-29 Final. VID: 11238 Page 11 of 208 © 2022 Apple Inc. Version: 1.2 Trademarks Apple’s trademarks applicable to this document are listed in https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html Other company, product, and service names may be trademarks or service marks of others. © Copyright Apple Inc. 2022. All Rights Reserved. VID: 11238 Page 12 of 208 © 2022 Apple Inc. Version: 1.2 1 Security Target Introduction This document is the Common Criteria (CC) Security Target (ST) for the following. • Apple iPadOS 15: iPads The hardware platforms for the iPad are listed in Annex A: Devices Covered by this Evaluation. The listed hardware platforms, with Apple iPadOS 15 installed, were evaluated as mobile devices in exact conformance with the protection profiles listed in section 2, Conformance Claims. 1.1 Security Target Reference ST Title: Apple iPadOS 15: iPads Security Target ST Version: Version 1.2 ST Date: 2022-09-29 1.2 TOE Reference Target of Evaluation (TOE) Identification • Apple iPadOS 15: iPads (Please refer to Annex A: Devices Covered by this Evaluation 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 mobile devices running the iPadOS 15 operating system, a Mobile Device Management (MDM) Agent, VPN client, and WLAN client components, which are included on the mobile devices. All devices listed in this ST were tested using the following operating system release. • iPadOS 15.1.0 For simplicity, the term “TOE OS” is used throughout this document and refers to the OS release listed above. The TOE OS manages the device hardware, provides MDM Agent functionality, and provides the technologies required to implement native applications (a.k.a. apps). (A native app is an app compiled to run on a specific mobile platform.) It provides a built-in 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. The TOE OS 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: 11238 Page 13 of 208 © 2022 Apple Inc. Version: 1.2 The TOE provides cryptographic services for the encryption of data at rest (DAR) within the TOE, for secure communication channels, for protection of Configuration Profiles, and for use by apps. User data protection is provided by encrypting user data, restricting access by apps, and restricting access until the user has been successfully authenticated. User identification and authentication is provided by a user defined passphrase (and 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 2 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 internal user and TOE Security Functionality (TSF) data using TSF protected keys and encryption/decryption functions, by conducting self-tests, by ensuring the integrity and authenticity of TSF updates and downloaded apps, 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 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 Annex A: Devices Covered by this Evaluation) and the TOE software is identified by its version number. The TOE includes documentation that is listed in section 1.5.3, TOE Documentation. The TOE provides wireless connectivity and includes support for virtual private network (VPN) connections; for access to the protected enterprise network, enterprise data and apps; and for communicating with other mobile devices. The TOE does not include the user apps that run on top of the operating system, but does include controls that limit apps’ behavior and enforce data segregation and impermeability across apps 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. VID: 11238 Page 14 of 208 © 2022 Apple Inc. Version: 1.2 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 There is a distinct online store for Business customers. From the Apple website (https://www.apple.com), go to the bottom of the page and click “Shop for Business.” Or optionally, use the following link. https://www.apple.com/retail/business/ 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 The TOE devices support wireless and wired 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 the operating system can be performed automatically (if the Software Automatic Update Settings are turned ON), manually from the device, manually using Finder on macOS versions 10.15.0 (Catalina) and higher, or manually using iTunes on macOS versions prior to 10.15.0 and on PCs. 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 the enterprise’s control. Supervision gives enterprises greater control over the TOE devices for which they are responsible. With supervision, the administrator can apply extra restrictions like turning off AirDrop or VID: 11238 Page 15 of 208 © 2022 Apple Inc. Version: 1.2 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 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 VPN connection, • the specification of the external storage via device connector policy, • 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 Annex A: Devices Covered by this Evaluation lists the mobile devices covered by this evaluation. 1.5 TOE Architecture The implementation of TOE architecture can be viewed as a set of layers, which are shown in Figure 1: TOE OS layers, below. Lower layers contain fundamental services and technologies. Higher-level layers build upon the lower layers and provide more sophisticated services and technologies. VID: 11238 Page 16 of 208 © 2022 Apple Inc. Version: 1.2 Figure 1: TOE OS layers The individual layers provide the following services. The Cocoa Touch layer contains key frameworks for building apps. These frameworks define the appearance of 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; • 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). VID: 11238 Page 17 of 208 © 2022 Apple Inc. Version: 1.2 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 the protection profiles listed in section 2, Conformance Claims. 1.5.2.1 Cryptographic Support The TOE provides cryptographic services via the following three cryptographic modules. • Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] (User Space) • Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] (Kernel Space) • Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] The Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] is a dynamically loadable library that resides within the TOE OS user space. The library is loaded into an app running in user space to provide cryptographic functions. Figure 2 below shows the logical boundary of the Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] within the TOE. VID: 11238 Page 18 of 208 © 2022 Apple Inc. Version: 1.2 Figure 2: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] Note that the Wi-Fi chip performs the bulk AES cryptography for Wi-Fi communications. See section 8.9.3 for more detail. 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 (PBKDF2) • Key generation • Key wrapping VID: 11238 Page 19 of 208 © 2022 Apple Inc. Version: 1.2 The Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] is a TOE OS kernel extension (KEXT) optimized for library use within the TOE OS kernel. Once the module is loaded into the kernel, its cryptographic functions are made available to TOE OS Kernel services only. Figure 3 below shows the logical boundary of the Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] within the TOE. Figure 3: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] 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 generation VID: 11238 Page 20 of 208 © 2022 Apple Inc. Version: 1.2 • Key wrapping The Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] is a single-chip standalone hardware cryptographic module SoC/System-in-Package (SiP) 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 • Message authentication • Key generation • Key wrapping Figure 4 below shows the logical boundary of the Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] within the TOE. Figure 4: Block Diagram of the Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] VID: 11238 Page 21 of 208 © 2022 Apple Inc. Version: 1.2 In the figure above, HW is shorthand for hardware, POST is shorthand Power-On Self Tests, OTP- ROM is shorthand for One Time Programmable Read-Only Memory, and UID is shorthand for Unique ID. Note that the “Apps” in the Secure Enclave Processor OS (sepOS) are Apple-only developed apps. They are not user-created apps. 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 apps or application- defined cryptographic keys) can be stored in the keychain, 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 is protected such that only the app that owns the data can access it. 1.5.2.3 Identification and Authentication Except for making answering calls, emergency calls, accessing Medical ID information, using the cameras (unless their use is generally disallowed), using the flashlight, using the control center, and using the notification center, users need to authenticate using a passcode or a biometric (fingerprint or face). The user is required to use the passcode authentication mechanism under the following conditions. • Turn on or restart the device • Press the Home button or swipe up to unlock your device (configurable) • Update software • Erase the device • View or change passcode settings • Install iPadOS Configuration Profiles The passcode can be configured for a minimum length, for dedicated passcode policies, and for a maximum lifetime. 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. 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. VID: 11238 Page 22 of 208 © 2022 Apple Inc. Version: 1.2 1.5.2.4 Security Management The security functions listed in Table 6: 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 apps and protect the TSF from unauthorized access to TSF resources—in addition, each device includes a separate system called the SEP which is the only system that can use the Root Encryption Key (REK). The SEP 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 apps • 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.11ac-2013 (a.k.a. Wi-Fi 5) • IEEE 802.11ax (a.k.a. Wi-Fi 6) • IEEE 802.1X • EAP-TLS (1.0,1.1,1.2) • TLS (1.2) • IPsec VID: 11238 Page 23 of 208 © 2022 Apple Inc. Version: 1.2 • Bluetooth (4.2, 5.0) 1.5.2.8 Audit The TOE provides the ability for responses to be sent from the MDM Agent to the MDM Server. These responses are configurable by the organization as per [DEV_MAN] under Implementing Device Management, Deploying MDM Enrollment Profiles. 1.5.3 TOE Documentation For documents that contain multiple links, the first link points to the document (and language) used in the evaluation. The second link marked “International” points to the internationalized versions of the document. Reference Document Name Location Mobile Device Administrator Guidance [CCGUIDE] Apple iOS 15: iPhones and Apple iPadOS 15: iPads Common Criteria Configuration Guide https://www.niap- ccevs.org/MMO/Product/st_vid11 238-agd.pdf [DEV_MAN] Device Management (online) https://developer.apple.com/docu mentation/devicemanagement Mobile Device User Guidance [iPad_UG] iPad User Guide iPadOS 15.1 (2021) (This version is no longer available, but screenshots exist in [CCGUIDE].) The latest iPad User Guide: https://support.apple.com/guide/i pad/welcome/ios [PASSCODE-Help] (March 28, 2022) Use a passcode with your iPhone, iPad or iPod touch https://support.apple.com/en- us/HT204060 International: https://support.apple.com/HT204 060 [BLUETOOTH_HELP] (November 19, 2021) Pair a third-party Bluetooth accessory with your iPhone, iPad, or iPod touch https://support.apple.com/en- us/HT204091 International: https://support.apple.com/HT204 091 VID: 11238 Page 24 of 208 © 2022 Apple Inc. Version: 1.2 Reference Document Name Location Mobile Device Management [AConfig] Apple Configurator 2 User Guide (online) https://support.apple.com/guide/ apple-configurator- 2/welcome/mac [ABM_Guide] (April 27, 2022) Apple Business Manager User Guide https://support.apple.com/guide/ apple-business- manager/welcome/web [PM_Help] Profile Manager User Guide for macOS Monterey https://support.apple.com/guide/ profile-manager/welcome/mac Supporting Documents [DeployRef] (June 2022) Apple Platform Deployment https://support.apple.com/guide/ deployment/welcome/web [LOGGING] Logging https://developer.apple.com/docu mentation/os/logging?language= objc [PROFS_LOGS] Profiles and Logs (iOS info applies to iPadOS) https://developer.apple.com/bug- reporting/profiles-and- logs/?platforms=ios [TRUST_STORE] (September 27, 2021) List of available trusted root certificates in iOS 15, iPadOS 15, macOS 12, tvOS 15, and watchOS 8 https://support.apple.com/en- us/HT212773 International: https://support.apple.com/HT212 773 [MANAGE_CARDS] (December 16, 2021) Change or remove the payment cards that you use with Apple Pay https://support.apple.com/en- us/HT205583 International: https://support.apple.com/HT205 583 [PAY_SETUP] (March 18, 2022) Set up Apple Pay https://support.apple.com/en- us/HT204506 International: https://support.apple.com/HT204 506 VID: 11238 Page 25 of 208 © 2022 Apple Inc. Version: 1.2 Reference Document Name Location [CONTENT-CACHING] Set up content caching on Mac https://support.apple.com/guide/ mac-help/set-up-content- caching-on-mac- mchl3b6c3720/12.0/mac/12.0 [APFS_DOC] File system formats available in Disk Utility on Mac https://support.apple.com/guide/ disk- utility/dsku19ed921c/21.0/mac/1 2.0 App Developer Guidance [CKTSREF] Certificate, Key, and Trust Services https://developer.apple.com/docu mentation/security/certificate_key _and_trust_services [KEYCHAINPG] Keychain Services (Programming Guide) https://developer.apple.com/docu mentation/security/keychain_servi ces [AP_SEC] (May 2022) Apple Platform Security https://help.apple.com/pdf/securi ty/en_US/apple-platform- security-guide.pdf [APFS_DEV_DOC] (2021) About Apple File System https://developer.apple.com/docu mentation/foundation/file_system /about_apple_file_system [CertPinning] Identity Pinning: How to configure server certificates for your app https://developer.apple.com/new s/?id=g9ejcf8y 1.5.4 Other References Reference Document Name Location [BT] Bluetooth SIG, Inc. Bluetooth Specifications https://www.bluetooth.com/specif ications/ [FIPS 140-3] FIPS 140-3 Security Requirements for Cryptographic Modules https://csrc.nist.gov/publications/ detail/fips/140/3/final VID: 11238 Page 26 of 208 © 2022 Apple Inc. Version: 1.2 Reference Document Name Location [FIPS 180-4] FIPS 180-4 Secure Hash Standard (SHS) https://csrc.nist.gov/publications/ detail/fips/180/4/final [FIPS 186-4] FIPS 186-4 Digital Signature Standard (DSS) https://csrc.nist.gov/publications/ detail/fips/186/4/final [FIPS 197] FIPS 197 Advanced Encryption Standard (AES) https://csrc.nist.gov/publications/ detail/fips/197/final [FIPS 198-1] FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) https://csrc.nist.gov/publications/ detail/fips/198/1/final [RFC 3394] IETF RFC 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm https://datatracker.ietf.org/doc/ht ml/rfc3394 [RFC 3526] IETF RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) https://tools.ietf.org/html/rfc3526 [RFC 5996] IETF RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2) https://tools.ietf.org/html/rfc5996 [RFC 7748] IETF RFC 7748 Elliptic Curves for Security https://tools.ietf.org/html/rfc7748 [SP800-38A] NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques https://csrc.nist.gov/publications/ detail/sp/800-38a/final VID: 11238 Page 27 of 208 © 2022 Apple Inc. Version: 1.2 Reference Document Name Location [SP800-38C] NIST Special Publication 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality https://csrc.nist.gov/publications/ detail/sp/800-38c/final [SP800-38D] NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC https://csrc.nist.gov/publications/ detail/sp/800-38d/final [SP800-38E] NIST Special Publication 800-38E Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage Devices https://csrc.nist.gov/publications/ detail/sp/800-38e/final [SP800-38F] NIST Special Publication 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping https://csrc.nist.gov/publications/ detail/sp/800-38f/final [SP800-56A] NIST Special Publication 800-56A Revision 3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography https://csrc.nist.gov/publications/ detail/sp/800-56a/rev-3/final [SP800-56B] NIST Special Publication 800-56B Revision 2 Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography https://csrc.nist.gov/publications/ detail/sp/800-56b/rev-2/final [SP800-56C] NIST Special Publication 800-56C Revision 2 Recommendation for Key- Derivation Methods in Key- Establishment Schemes https://csrc.nist.gov/publications/ detail/sp/800-56c/rev-2/final VID: 11238 Page 28 of 208 © 2022 Apple Inc. Version: 1.2 Reference Document Name Location [SP800-57] NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key Management, Part 1: General https://csrc.nist.gov/publications/ detail/sp/800-57-part-1/rev- 4/final [SP800-90A] NIST Special Publication 800-90A Revision 1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators https://csrc.nist.gov/publications/ detail/sp/800-90a/rev-1/final [SP800-108] NIST Special Publication 800-108 (Revised) October 2009 Recommendation for Key Derivation Using Pseudorandom Functions https://csrc.nist.gov/publications/ detail/sp/800-108/final [SP800-132] NIST Special Publication 800-132 Recommendation for Password- Based Key Derivation: Part 1: Storage Applications https://csrc.nist.gov/publications/ detail/sp/800-132/final VID: 11238 Page 29 of 208 © 2022 Apple Inc. Version: 1.2 2 Conformance Claims 2.1 CC Conformance This [ST] conforms to Common Criteria (CC) Version 3.1, Revision 5 and is Part 2 extended and Part 3 extended. 2.2 Protection Profile (PP) Conformance This [ST] claims Exact Conformance to the documents in Table 1. Reference Document Claimed Use Cases [CFG_MDF-MDMA-VPNC- BT_V1.0] This PP-Configuration is comprised of the following 4 documents. PP-Configuration for Mobile Device Fundamentals, Mobile Device Management Agents, Virtual Private Network Clients, and Bluetooth, 07 March 2022 [PP_MDF_V3.2] Protection Profile for Mobile Device Fundamentals, Version 3.2, dated 2021- 04-15 Use Case 3, Use Case 4 [MOD_MDM_AGENT_V1.0] PP-Module for MDM Agents Version 1.0, dated 2019-04-25 Use Case 3, Use Case 4 [MOD_BT_V1.0] PP-Module for Bluetooth, Version 1.0, dated 2021-04-15 Use Case 2 [MOD_VPNC_V2.3] PP-Module for Virtual Private Network (VPN) Clients, Version 2.3, dated 2021- 08-10 Use Case 1 [PP_WLAN_CLI_EP_V1.0] General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients, Version 1.0, dated 2016-02-08 [PKG_TLS_V1.1] Functional Package for Transport Layer Security (TLS), Version 1.1, dated 2019- 02-12 Table 1: PP conformance and claimed Use Cases VID: 11238 Page 30 of 208 © 2022 Apple Inc. Version: 1.2 2.2.1 Technical Decisions (TDs) Table 2 below contains the active TDs for the documents in Table 1 above at the time of the evaluation. The applicability of each TD to the evaluation is provided in the table. Document NIAP TD TD Description Appli- cable? Non-applicability Rationale [PP_MDF_V3.2] TD0663 Audit Listing for MDF Moved to Guidance Yes TD0658 Updates to Table 7 Column References in MDF v3.2 Yes TD0653 MDF v3.2 ASE References Yes TD0650 Conformance claim sections updated to allow for MOD_VPNC_V2.3 and 2.4 No The ST does not claim MOD_VPNC_V2.4. (TD0600 added MOD_VPNC_V2.3.) TD0646 Function 23 Allow Invalid Certs Yes TD0643 Data Signaling, Mgmt Function #24 No Function #24 is optional and not claimed by the ST. TD0623 FIA_X509_EXT.2.1 Protocol Selection Yes TD0600 Conformance claim sections updated to allow for MOD_VPNC_V2.3 Yes TD0596 VPN Traffic Permitted in FDP_IFC_EXT.1 Yes [MOD_MDM_AGENT_ V1.0] TD0673 MDM-Agent PP- Module updated to allow for new PP and PP-Module Versions Yes TD0660 Mislabeled SFRs in MDM Agent Auditable Events Table Yes VID: 11238 Page 31 of 208 © 2022 Apple Inc. Version: 1.2 Document NIAP TD TD Description Appli- cable? Non-applicability Rationale TD0650 Conformance claim sections updated to allow for MOD_VPNC_V2.3 and 2.4 No The ST does not claim MOD_VPNC_V2.4. (TD0600 added MOD_VPNC_V2.3.) TD0600 Conformance claim sections updated to allow for MOD_VPNC_V2.3 Yes TD0497 SFR Rationale, Consistency of SPD, and Implicitly Satisfied SFRs Yes TD0491 Update to FMT_SMF_EXT.4 Test 2 Yes [MOD_BT_V1.0] TD0671 Bluetooth PP-Module updated to allow for new PP and PP-Module Versions No The ST does not claim GPOS v4.3, MDF v3.3, BIOcPPM v1.1, or WLANC PPM v1.0. TD0650 Conformance claim sections updated to allow for MOD_VPNC_V2.3 and 2.4 No The ST does not claim MOD_VPNC_V2.4. (TD0600 added MOD_VPNC_V2.3.) TD0640 Handling BT devices that do not support encryption Yes TD0600 Conformance claim sections updated to allow for MOD_VPNC_V2.3 Yes [MOD_VPNC_V2.3] TD0622 VPNC MOD FTP_DIT_EXT.1 corrections No The ST does not conform to AppPP. [PP_WLAN_CLI_EP_V1 .0] TD0517 WLAN Client Corrections for X509 and TLSC Yes VID: 11238 Page 32 of 208 © 2022 Apple Inc. Version: 1.2 Document NIAP TD TD Description Appli- cable? Non-applicability Rationale TD0492 TLS-EAP Ciphers and TLS versions for WLAN Client Yes TD0470 Wireless Network Restrictions Yes TD0439 EAP-TLS Revocation Checking Yes TD0244 FCS_TLSC_EXT - TLS Client Curves Allowed No The TOE’s WLAN excludes elliptic curves. TD0194 Update to Audit of FTP_ITC_EXT.1/WLAN Yes [PKG_TLS_V1.1] TD0588 Session Resumption Support in TLS package No. The TOE does not contain TLS server functionality. TD0513 CA Certificate loading Yes TD0499 Testing with pinned certificates Yes TD0469 Modification of test activity for FCS_TLSS_EXT.1.1 test 4.1 No The TOE does not contain TLS server functionality. TD0442 Updated TLS Ciphersuites for TLS Package Yes Table 2: Technical Decision applicability 2.3 Conformance Rationale This [ST] provides Exact Conformance with the documents in Table 1. The security problem definition, security objectives and security requirements in this [ST] are all taken from the documents in Table 1 performing only operations defined there. The requirements in the documents in Table 1 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 documents in Table 1 have been copied into this [ST], the dependency analysis for the requirements is assumed to be already performed by the authors of the documents in Table 1 and is not reproduced in this document. VID: 11238 Page 33 of 208 © 2022 Apple Inc. Version: 1.2 3 Security Problem Definition The security problem definition has been taken from the documents in Table 1. It is reproduced here for the convenience of the reader. 3.1 Threats T.NETWORK_EAVESDROP (PP_MDF_V3.2, MOD_BT_V1.0) 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_ATTACK (PP_MDF_V3.2, MOD_BT_V1.0) 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.PHYSICAL_ACCESS (PP_MDF_V3.2) 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.MALICIOUS_APP (PP_MDF_V3.2) 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.PERSISTENT_PRESENCE (PP_MDF_V3.2) 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 (MOD_MDM_AGENT_V1.0) VID: 11238 Page 34 of 208 © 2022 Apple Inc. Version: 1.2 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 the enterprise would detect compromise. 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.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.UNAUTHORIZED_ACCESS (MOD_VPNC_V2.3) 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 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. VID: 11238 Page 35 of 208 © 2022 Apple Inc. Version: 1.2 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.TSF_CONFIGURATION (MOD_VPNC_V2.3) 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.USER_DATA_REUSE (MOD_VPNC_V2.3) 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. T.TSF_FAILURE (MOD_VPNC_V2.3) 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_MDF_V3.2) 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.NOTIFY (PP_MDF_V3.2) It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen. A.PRECAUTION (PP_MDF_V3.2) VID: 11238 Page 36 of 208 © 2022 Apple Inc. Version: 1.2 It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device. A.PROPER_USER (PP_MDF_V3.2) Mobile Device users are not willfully negligent or hostile, and use the device within compliance of a reasonable Enterprise security policy. A.CONNNECTIVITY (MOD_MDM_AGENT_V1.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 (MOD_MDM_AGENT_V1.0) The MDM Agent relies upon mobile platform and hardware evaluated against the MDF PP 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 (MOD_MDM_AGENT_V1.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.PROPER_USER (MOD_MDM_AGENT_V1.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.TRUSTED_ADMIN (PP_WLAN_CLI_EP_V1.0) TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. A.NO_TOE_BYPASS (MOD_VPNC_V2.3) Information cannot flow onto the network to which the VPN client's host is connected without passing through the TOE. A.PHYSICAL (MOD_VPNC_V2.3) Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environment. A.TRUSTED_CONFIG (MOD_VPNC_V2.3) Personnel configuring the TOE and its operational environment will follow the applicable security configuration guidance. VID: 11238 Page 37 of 208 © 2022 Apple Inc. Version: 1.2 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.ACCOUNTABILITY (MOD_MDM_AGENT_V1.0) Personnel operating the TOE shall be accountable for their actions within the TOE. P.ADMIN (MOD_MDM_AGENT_V1.0) The configuration of the mobile device security functions must adhere to the Enterprise security policy. P.DEVICE_ENROLL (MOD_MDM_AGENT_V1.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 (MOD_MDM_AGENT_V1.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. VID: 11238 Page 38 of 208 © 2022 Apple Inc. Version: 1.2 4 Security Objectives The security objectives have been taken from the documents in Table 1. They are reproduced here for the convenience of the reader. 4.1 Security Objectives for the TOE O.PROTECTED_COMMS (PP_MDF_V3.2, MOD_BT_V1.0) To address the network eavesdropping (T.EAVESDROP) and network attack (T.NETWORK) threats described in [PP_MDF_V3.2] Section 3.1 Threats, 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, DTLS, 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 including any optional SFRs defined in this PP, 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 (PP_MDF_V3.2) 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 (PP_MDF_V3.2) 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(PP_MDF_V3.2) 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. VID: 11238 Page 39 of 208 © 2022 Apple Inc. Version: 1.2 O.INTEGRITY (PP_MDF_V3.2) 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 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 (PP_MDF_V3.2) 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.ACCOUNTABILITY (MOD_MDM_AGENT_V1.0) The TOE must provide logging facilities, which record management actions undertaken by its administrators. O.APPLY_POLICY (MOD_MDM_AGENT_V1.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 entire lifecycle, including policy updates and its possible unenrollment from management services. O.DATA_PROTECTION_TRANSIT (MOD_MDM_AGENT_V1.0) Data exchanged between the MDM Server and the MDM Agent must be protected from being monitored, accessed, or altered. O.STORAGE (MOD_MDM_AGENT_V1.0) 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 platform provide key storage. The TOE is expected to protect its persistent secrets and private keys. 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. VID: 11238 Page 40 of 208 © 2022 Apple Inc. Version: 1.2 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. O.AUTHENTICATION (MOD_VPNC_V2.3) To address the issues associated with unauthorized disclosure of information in transit, a compliant TOE’s authentication ability (IPsec) will allow the TSF to establish VPN connectivity with a remote VPN gateway or peer and ensure that any such connection attempt is both authenticated and authorized. This objective also ensures the protection of data in transit by ensuring that interfaces exist for non-TOE entities to invoke the TSF to establish an IPsec channel. O.CRYPTOGRAPHIC_FUNCTIONS (MOD_VPNC_V2.3) To address the issues associated with unauthorized disclosure of information in transit, a compliant TOE will implement cryptographic capabilities. These capabilities are intended to maintain confidentiality and allow for detection and modification of data that is transmitted outside of the TOE. O.KNOWN_STATE (MOD_VPNC_V2.3) The TOE will provide sufficient measures to ensure it is operating in a known state. At minimum this includes management functionality to allow the security functionality to be configured and self-test functionality that allows it to assert its own integrity. It may also include auditing functionality that can be used to determine the operational behavior of the TOE. O.NONDISCLOSURE (MOD_VPNC_V2.3) To address the issues associated with unauthorized disclosure of information at rest, a compliant TOE will ensure that non-persistent data is purged when no longer needed. The TSF may also implement measures to protect against the disclosure of stored cryptographic keys and data through implementation of protected storage and secure erasure methods. The TOE may optionally also enforce split-tunneling prevention to ensure that data in transit cannot be disclosed inadvertently outside of the IPsec tunnel. VID: 11238 Page 41 of 208 © 2022 Apple Inc. Version: 1.2 4.2 Security Objectives for the TOE Environment OE.CONFIG (PP_MDF_V3.2) TOE administrators will configure the Mobile Device security functions correctly to create the intended security policy. OE.NOTIFY (PP_MDF_V3.2) The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen. OE.PRECAUTION (PP_MDF_V3.2) The mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device. OE.DATA_PROPER_USER(PP_MDF_V3.2) Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device. OE.DATA_PROPER_ADMIN (MOD_MDM_AGENT_V1.0) TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. OE.DATA_PROPER_USER(MOD_MDM_AGENT_V1.0) Users of the mobile device are trained to securely use the mobile device and apply all guidance in a trusted manner. OE.IT_ENTERPRISE (MOD_MDM_AGENT_V1.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 (MOD_MDM_AGENT_V1.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.WIRELESS_NETWORK (MOD_MDM_AGENT_V1.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.TRUSTED_ADMIN (PP_WLAN_CLI_EP_V1.0) TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. OE.NO_TOE_BYPASS (MOD_VPNC_V2.3) Information cannot flow onto the network to which the VPN client's host is connected without passing through the TOE. VID: 11238 Page 42 of 208 © 2022 Apple Inc. Version: 1.2 OE.PHYSICAL (MOD_VPNC_V2.3) Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environment. OE.TRUSTED_CONFIG (MOD_VPNC_V2.3) Personnel configuring the TOE and its operational environment will follow the applicable security configuration guidance. VID: 11238 Page 43 of 208 © 2022 Apple Inc. Version: 1.2 5 Extended Components Definition The Security Target draws upon the extended components implicitly defined in the documents in Table 1. VID: 11238 Page 44 of 208 © 2022 Apple Inc. Version: 1.2 6 Security Functional Requirements This chapter describes the Security Functional Requirements (SFRs) for the TOE. The SFRs have been taken from the documents in Table 1 with appropriate selections, assignments and refinements being applied. For each SFR, the source is indicated in braces as follows. {MDF} – The component can be found in [PP_MDF_V3.2] {AGENT} – The component can be found in [MOD_MDM_AGENT_V1.0] {BT} – The component can be found in [MOD_BT_V1.0] {TLS} – The component can be found in [PKG_TLS_V1.1] {VPN} – The component can be found in [MOD_VPNC_V2.3] {WLAN} – The component can be found in [PP_WLAN_CLI_EP_V1.0] Selections and assignment operations performed as required by the PP, PP-Modules, FP, and EP are marked in bold. This Security Target (ST) does not identify selections or assignments already applied in the documents from Table 1. VID: 11238 Page 45 of 208 © 2022 Apple Inc. Version: 1.2 6.1 Security Audit (FAU) Agent Alerts (FAU_ALT) FAU_ALT_EXT.2 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 audit events: • 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 Audit Data Generation FAU_GEN.1.1 {MDF} {WLAN} 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 OS 5) Insertion or removal of removable media 6) Specifically defined auditable events in Table 2 7) No additional auditable events Note: For this element, Table 2 refers to Table 2 in [PP_MDF_V3.2]. Table 3: Combined mandatory auditable events from [PP_MDF_V3.2] and [PP_WLAN_CLI_EP_V1.0], below, presents the information given in Table 2 of [PP_MDF_V3.2] combined with Table 2 of [PP_WLAN_CLI_EP_V1.0] as instructed in [PP_WLAN_CLI_EP_V1.0]. VID: 11238 Page 46 of 208 © 2022 Apple Inc. Version: 1.2 Requirement Auditable Events Additional Audit Record Contents [PP_MDF_V3.2] Mandatory FAU_GEN.1 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.5 None No additional information FCS_CKM_EXT.6 None FCS_CKM.1 None No additional information FCS_CKM.2/UNLOCKED None FCS_CKM.2/LOCKED None FCS_COP.1/ENCRYPT None FCS_COP.1/HASH None FCS_COP.1/SIGN None FCS_COP.1/KEYHMAC None FCS_COP.1/CONDITION 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 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_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 VID: 11238 Page 47 of 208 © 2022 Apple Inc. Version: 1.2 Requirement Auditable Events Additional Audit Record Contents FPT_AEX_EXT.1 None FPT_AEX_EXT.2 None FPT_AEX_EXT.3 None FPT_JTA_EXT.1 None FPT_KST_EXT.1 None 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/PREKERNEL Start-up of TOE No additional information None No additional information FPT_TUD_EXT.1 None FTA_SSL_EXT.1 None [PP_WLAN_CLI_EP_V1.0] Mandatory FAU_GEN.1/WLAN None FCS_CKM.1/WLAN None FCS_CKM.2/WLAN None FCS_CKM_EXT.4 None FCS_TLSC_EXT.1/WLAN Failure to establish an EAP-TLS session. Reason for failure. Establishment/terminati on of an EAP-TLS session. Non-TOE endpoint of connection. FIA_PAE_EXT.1 None FIA_X509_EXT.1/WLAN1 Failure to validate X.509v3 certificate Reason for failure of validation FIA_X509_EXT.2/WLAN None FMT_SMF_EXT.1/WLAN None FPT_TST_EXT.1/WLAN Execution of this set of TSF self-tests. None No additional information FTA_WSE_EXT.1 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/WLAN2 All attempts to establish a trusted channel Identification of the non-TOE endpoint of the channel 1 TD0439 added the FIA_X509_EXT.1/WLAN audit event. 2 TD0194 modified the FTP_ITC_EXT.1/WLAN audit event. VID: 11238 Page 48 of 208 © 2022 Apple Inc. Version: 1.2 Table 3: Combined mandatory auditable events from [PP_MDF_V3.2] and [PP_WLAN_CLI_EP_V1.0] FAU_GEN.1.2 {MDF} {WLAN} 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 2 6) no additional information Note: For this element, Table 2 refers to Table 1 in [PP_MDF_V3.2]. Table 3: Combined mandatory auditable events from [PP_MDF_V3.2] and [PP_WLAN_CLI_EP_V1.0], above, presents the information given in Table 2 of [PP_MDF_V3.2] 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 Generation3 FAU_GEN.1.1(2) {AGENT} The MDM Agent shall implement functionality to generate an MDM Agent audit record of the following auditable events: a. Startup and shutdown of the MDM Agent; b. All auditable events for not specified level of audit; and c. MDM policy updated, any modification commanded by the MDM Server, specifically defined auditable events listed in Table 4, and no other events. 3 TD0660 is applicable to this SFR. VID: 11238 Page 49 of 208 © 2022 Apple Inc. Version: 1.2 Requirement Auditable Events Additional Audit Record Contents FAU_ALT_EXT.2 Success/failure of sending alert. No additional information FAU_GEN.1 (2) None. N/A FAU_SEL.1(2) All modifications to the audit configuration that occur while the audit collection functions are operating. No additional information FCS_STG_EXT.4 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 the TLS session. Non-TOE endpoint of connection. FIA_ENR_EXT.2 Enrollment in management. Reference identifier of MDM Server. FMT_POL_EXT.2 Failure of policy validation. Reason for failure of validation. FMT_SMF_EXT.4 Outcome (Success/failure) of function. No additional information. FMT_UNR_EXT.1.1 Attempt to unenroll No additional information. FTP_ITC_EXT.1(2) Initiation and termination of trusted channel. Trusted channel protocol. Non-TOE endpoint of connection. Table 4: Auditable events from [MOD_MDM_AGENT_V1.0] Note: FCS_STG_EXT.1(2) has been removed from Table 4 because it does not exist in [ST]. (FCS_STG_EXT.1(2) is required for MDM PP, not MDF PP.) FAU_GEN.1.2(2) {AGENT} The TSF shall record within each MDM Agent audit record at least the following information: a. Date and time of the event, type of event, subject identity, (if relevant) the outcome (success or failure) of the event, and additional information in Table 4; and b. For each audit event type, based on the auditable event definitions of the functional components included in the PP-Module/ST, no other audit relevant information. FAU_GEN.1/BT Audit Data Generation (Bluetooth) FAU_GEN.1.1/BT {BT} The TSF shall be able to generate an audit record of the following auditable events: 1) Start-up and shutdown of the audit functions VID: 11238 Page 50 of 208 © 2022 Apple Inc. Version: 1.2 2) All auditable events for the not selected level of audit 3) Specifically defined auditable events in the Auditable Events table. Note: For this element, Auditable Events table refers to Table 2 in [MOD_BT_V1.0]. Requirement Auditable Events Additional Audit Record Contents FCS_CKM_EXT.8 None FIA_BLT_EXT.1 Failed user authorization of Bluetooth device. User authorization decision (e.g., user rejected connection, incorrect pin entry). Failed user authorization for local Bluetooth Service. Bluetooth address and name of device. Bluetooth profile. Identity of local service with service ID. FIA_BLT_EXT.2 Initiation of Bluetooth connection. Bluetooth address and name of device. Failure of Bluetooth connection. Reason for failure. FIA_BLT_EXT.4 None FIA_BLT_EXT.6 None FIA_BLT_EXT.7 None FTP_BLT_EXT.1 None FTP_BLT_EXT.2 None FTP_BLT_EXT.3/BR None FTP_BLT_EXT.3/LE None Table 5: Auditable events from [MOD_BT_V1.0] FAU_GEN.1.2/BT {BT} The TSF shall record within each audit record at least the following information: 4) Date and time of the event 5) Type of event 6) Subject identity 7) The outcome (success or failure) of the event 8) Additional information in the Auditable Events table. Note: For this element, Auditable Events table refers to Table 2 in [MOD_BT_V1.0]. Security Audit Event Selection (FAU_SEL) FAU_SEL.1(2) Security Audit Event Selection FAU_SEL.1.1(2) {AGENT} The TSF shall implement functionality to select the set of events to be audited from the set of all auditable events based on the following attributes: a. event type VID: 11238 Page 51 of 208 © 2022 Apple Inc. Version: 1.2 b. success of auditable security events, failure of auditable security events, and no other attributes. 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: 11238 Page 52 of 208 © 2022 Apple Inc. Version: 1.2 6.2 Cryptographic Support (FCS) Cryptographic Key Management (FCS_CKM) FCS_CKM.1 Cryptographic Key Generation FCS_CKM.1.1 {MDF} {VPN} The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm • 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: RFC 7748 • FFC schemes using o Diffie-Hellman group 14 that meet the following: RFC 3526 o “safe-prime” groups that meet the following: ‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”’ Note: FCS_CKM.1.1 is a merged SFR from both MDF PP and PP-Module for VPN Clients. 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 PRF-704 and specified cryptographic key sizes 128 bits and 256 bits using a Random Bit Generator as specified in FCS_RBG_EXT.1 that meet the following: IEEE 802.11-2012 and IEEE 802.11ac-2014. FCS_CKM.1/VPN Cryptographic Key Generation (IKE) FCS_CKM.1.1/VPN {VPN} The TSF shall implement functionality to generate asymmetric cryptographic keys used for IKE peer authentication in accordance with: • 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/UNLOCKED Cryptographic Key Establishment FCS_CKM.2.1/UNLOCKED {MDF} {VPN} VID: 11238 Page 53 of 208 © 2022 Apple Inc. Version: 1.2 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 o NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”, • Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “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 Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”, • Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526. FCS_CKM.2/LOCKED Cryptographic Key Establishment FCS_CKM.2.1/LOCKED {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 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 the 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. VID: 11238 Page 54 of 208 © 2022 Apple Inc. Version: 1.2 FCS_CKM_EXT.2 Cryptographic Key Random Generation FCS_CKM_EXT.2.1 {MDF} All DEKs shall be randomly generated with entropy corresponding to the security strength of AES key sizes of 256 bits. FCS_CKM_EXT.3 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. FCS_CKM_EXT.3.2 {MDF} The TSF shall generate all KEKs using one of the following methods: • Derive the KEK from a Password Authentication Factor using according to FCS_COP.1.1/CONDITION and • Generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1), • Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by concatenating the keys and using a KDF (as described in SP 800-56C), encrypting one key with another. Note: The random number generator on the main device (i.e., FCS_RBG_EXT.1(Kernel and User space)) is used. FCS_CKM_EXT.4 Key Destruction FCS_CKM_EXT.4.1 {MDF} {WLAN} 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. VID: 11238 Page 55 of 208 © 2022 Apple Inc. Version: 1.2 FCS_CKM_EXT.4.2 {MDF} {WLAN} The TSF shall destroy all plaintext keying material and critical security parameters when no longer needed. FCS_CKM_EXT.5 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 Salt Generation FCS_CKM_EXT.6.1 {MDF} 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 SEP 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 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 Appendix B of the Protection Profile, because “mutable hardware” is included in FCS_CKM_EXT.1.1 {MDF}. FCS_CKM_EXT.8 Bluetooth Key Generation FCS_CKM_EXT.8.1 {BT} The TSF shall generate public/private ECDH key pairs every new connection attempt. VID: 11238 Page 56 of 208 © 2022 Apple Inc. Version: 1.2 Cryptographic Operations (FCS_COP) FCS_COP.1/ENCRYPT Cryptographic Operation FCS_COP.1.1/ENCRYPT {MDF} {VPN} 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 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), • AES-XTS (as defined in NIST SP 800-38E) mode, • AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013), • AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013) and cryptographic key sizes 128-bit key sizes and 256-bit key sizes. FCS_COP.1/HASH Cryptographic Operation FCS_COP.1.1/HASH {MDF} 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/SIGN Cryptographic Operation FCS_COP.1.1/SIGN {MDF} The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm • RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4, • ECDSA schemes using “NIST curves” P-384 and P-256, P-521 that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5. FCS_COP.1/KEYHMAC Cryptographic Operation FCS_COP.1.1/KEYHMAC {MDF} 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 greater than or equal to 112 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". VID: 11238 Page 57 of 208 © 2022 Apple Inc. Version: 1.2 FCS_COP.1/CONDITION Cryptographic Operation FCS_COP.1.1/CONDITION {MDF} The TSF shall perform conditioning in accordance with a specified cryptographic algorithm HMAC-SHA-256 using a salt, and PBKDF2 with one iteration, repetitive AES-256 CBC encryption with a duration between 100 and 150 ms and output cryptographic key sizes 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 HTTPS Protocol FCS_HTTPS_EXT.1.1 {MDF} The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 {MDF} The TSF shall implement HTTPS using TLS as defined in the Package for Transport Layer Security. FCS_HTTPS_EXT.1.3 {MDF} The TSF shall notify the application and request application authorization to establish the connection if the peer certificate is deemed invalid. IPsec Protocol (FCS_IPSEC) FCS_IPSEC_EXT.1 IPsec FCS_IPSEC_EXT.1.1 {VPN} The TSF shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 {VPN} The TSF shall implement tunnel mode. FCS_IPSEC_EXT.1.3 {VPN} The TSF 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 TSF 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. VID: 11238 Page 58 of 208 © 2022 Apple Inc. Version: 1.2 FCS_IPSEC_EXT.1.5 {VPN} The TSF shall implement the protocol: • IKEv2 as defined in RFCs 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC8247, and no other RFCs for hash functions. FCS_IPSEC_EXT.1.6 {VPN} The TSF shall ensure the encrypted payload in the IKEv2 protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and AES-GCM-128, AES-GCM- 256 as specified in RFC 5282. FCS_IPSEC_EXT.1.7 {VPN} The TSF 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 TSF shall ensure that all IKE protocols implement DH groups 19 (256-bit Random ECP), 20 (384-bit Random ECP), and 15 (3072-bit MODP), 14 (2048-bit MODP). FCS_IPSEC_EXT.1.9 {VPN} The TSF 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 TSF 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} The TSF 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} The TSF shall not establish an SA if the Fully Qualified Domain Name (FQDN) and no other reference identifier type 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} The TSF 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} VID: 11238 Page 59 of 208 © 2022 Apple Inc. Version: 1.2 The TSF 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 Initialization Vector Generation FCS_IV_EXT.1.1 {MDF} The TSF shall generate IVs in accordance with Table 13: References and IV Requirements for NIST- approved Cipher Modes. Note: The referenced Table 13 is found in [PP_MDF_V3.2]. Random Bit Generation (FCS_RBG) FCS_RBG_EXT.1(Kernel and User space) Random Bit Generation FCS_RBG_EXT.1.1(Kernel and User space) {MDF} 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} 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} The TSF shall be capable of providing output of the RBG to applications running on the TSF that request random bits. Note: This random bit generator is often referred to in this ST as the random bit generator in the main device. FCS_RBG_EXT.1(SEP) Random Bit Generation FCS_RBG_EXT.1.1(SEP) {MDF} 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} VID: 11238 Page 60 of 208 © 2022 Apple Inc. Version: 1.2 The deterministic RBG shall be seeded by an entropy source that accumulates entropy from TSF- hardware-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(SEP) {MDF} 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 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/LOCKED • The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, no other modes • All selected algorithms in FCS_COP.1/SIGN • All mandatory and selected algorithms in FCS_COP.1/HASH • All mandatory and selected algorithms in FCS_COP.1/KEYHMAC • No other cryptographic operations Cryptographic Key Storage (FCS_STG) FCS_STG_EXT.1 Cryptographic 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. VID: 11238 Page 61 of 208 © 2022 Apple Inc. Version: 1.2 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 Encrypted Cryptographic Key Storage FCS_STG_EXT.2.1 {MDF} The TSF shall encrypt all DEKs, KEKs, WPA2 (PSKs), IPsec (client certificates), Bluetooth keys, and all software-based key storage by KEKs that are 1) Protected by the REK with • encryption by a KEK chaining from a REK, 2) Protected by the REK and the password with • encryption by a KEK chaining to a REK and the password-derived or biometric unlocked KEK. FCS_STG_EXT.2.2 {MDF} 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 Integrity of Encrypted Key Storage FCS_STG_EXT.3.1 {MDF} The TSF shall protect the integrity of any encrypted DEKs and KEKs and long-term trusted channel key material by an immediate application of the key for 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 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 Protocol (FCS_TLS) FCS_TLS_EXT.1 TLS Protocol FCS_TLS_EXT.1.1 {TLS} The product shall implement TLS as a client. VID: 11238 Page 62 of 208 © 2022 Apple Inc. Version: 1.2 TLS Client Protocol (FCS_TLSC) FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 {TLS}4 The product shall implement TLS 1.2 (RFC 5246) and no earlier TLS versions as a client that supports the cipher suites • 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_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288, • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289, • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 and also supports functionality for • mutual authentication • session renegotiation. FCS_TLSC_EXT.1.2 {TLS} The product shall verify that the presented identifier matches the reference identifier according to RFC 6125. FCS_TLSC_EXT.1.3 {TLS} The product shall not establish a trusted channel if the server certificate is invalid with no exceptions. FCS_TLSC_EXT.1/WLAN Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)5 FCS_TLSC_EXT.1.1/WLAN {WLAN} The TSF shall implement TLS 1.0 (RFC 2246), 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: • TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 • TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246 • TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 • TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 4 TD0442 is applicable to this element. 5 TD0492 and TD0517 are applicable to this SFR. VID: 11238 Page 63 of 208 © 2022 Apple Inc. Version: 1.2 FCS_TLSC_EXT.1.2/WLAN {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 {WLAN} The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1/WLAN. FCS_TLSC_EXT.1.4/WLAN {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 {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.2 TLS Client Protocol for Mutual Authentication FCS_TLSC_EXT.2.1 {TLS} The product shall support mutual authentication using X.509v3 certificates. FCS_TLSC_EXT.4 TLS Client Support for Renegotiation FCS_TLSC_EXT.4.1 {TLS} The product shall support secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746. FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension FCS_TLSC_EXT.5.1 {TLS} The product shall present the Supported Elliptic Curves Extension in the Client Hello handshake message with the supported groups secp256r1, secp384r1, secp521r1. VID: 11238 Page 64 of 208 © 2022 Apple Inc. Version: 1.2 6.3 User Data Protection (FDP) Access Control (FDP_ACF) FDP_ACF_EXT.1 Access Control for System Services 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, groups of applications from accessing all data stored by other application, groups of applications. Exceptions may only be explicitly authorized for such sharing by a common application developer. FDP_ACF_EXT.2 Access Control for System Resources FDP_ACF_EXT.2.1 {MDF} The TSF shall provide a separate keystore, account credential database for each application group and only allow applications within that process group to access the resource. Exceptions may only be explicitly authorized for such sharing by no one. Data-At-Rest Protection (FDP_DAR) FDP_DAR_EXT.1 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 XTS mode with key size 128, 256 bits. FDP_DAR_EXT.2 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} VID: 11238 Page 65 of 208 © 2022 Apple Inc. Version: 1.2 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 Subset Information Flow Control FDP_IFC_EXT.1.1 {MDF}6 {VPN} The TSF shall • provide an interface which allows a VPN client to protect all IP traffic using IPsec, • provide a VPN client which can protect all IP traffic using IPsec as defined in the PP- Module for VPN Client with the exception of IP traffic needed to manage the VPN connection, and Cellular Services, Voicemail, AirPrint, and initial Captive Network communication, when the VPN is enabled. FDP_IFC_EXT.1/VPN Subset Information Flow Control (VPN) FDP_IFC_EXT.1.1/VPN {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 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 Processor 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. 6 TD0596 is applicable to this SFR. VID: 11238 Page 66 of 208 © 2022 Apple Inc. Version: 1.2 Certificate Data Storage (FDP_STG) FDP_STG_EXT.1 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/APPS Inter-TSF User Data Transfer Protection (Applications) FDP_UPC_EXT.1.1/APPS {MDF} The TSF shall provide a means for non-TSF applications executing on the TOE to use • mutually authenticated TLS as defined in the Package for Transport Layer Security, • HTTPS, and • no other protocol 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/APPS {MDF} The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection (Bluetooth) FDP_UPC_EXT.1.1/BLUETOOTH {MDF} The TSF shall provide a means for non-TSF applications executing on the TOE to use • Bluetooth BR/EDR in accordance with the PP-Module for Bluetooth, and • Bluetooth LE in accordance with the PP-Module for Bluetooth 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/BLUETOOTH {MDF} The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. VID: 11238 Page 67 of 208 © 2022 Apple Inc. Version: 1.2 6.4 Identification and Authentication (FIA) Authentication Failures (FIA_AFL) FIA_AFL_EXT.1 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 Bluetooth User Authorization FIA_BLT_EXT.1.1 {BT} The TSF shall require explicit user authorization before pairing with a remote Bluetooth device. VID: 11238 Page 68 of 208 © 2022 Apple Inc. Version: 1.2 FIA_BLT_EXT.2 Bluetooth Mutual Authentication FIA_BLT_EXT.2.1 {BT} The TSF shall require Bluetooth mutual authentication between devices prior to any data transfer over the Bluetooth link. FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections FIA_BLT_EXT.3.1 {BT} The TSF shall discard pairing and session initialization attempts from a Bluetooth device address (BD_ADDR) to which an active session already exists. FIA_BLT_EXT.4 Secure Simple Pairing FIA_BLT_EXT.4.1 {BT} The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the controller. FIA_BLT_EXT.4.2 {BT} The TOE shall support Secure Simple Pairing during the pairing process. FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization FIA_BLT_EXT.6.1 {BT} The TSF shall require explicit user authorization before granting trusted remote devices access to services associated with the following Bluetooth profiles: none. FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization FIA_BLT_EXT.7.1 {BT} The TSF shall require explicit user authorization before granting untrusted remote devices access to services associated with the following Bluetooth profiles: none. Biometric Authentication (FIA_BMG) FIA_BMG_EXT.1 Accuracy of Biometric Authentication FIA_BMG_EXT.1.1(T1) {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(T3) {MDF}(Touch ID Gen.3) VID: 11238 Page 69 of 208 © 2022 Apple Inc. Version: 1.2 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(T4) {MDF}(Touch ID Gen.4) The one-attempt BAF False Accept Rate (FAR) for fingerprint authentication shall not exceed 1:83K with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 23. FIA_BMG_EXT.1.1(F3) {MDF}(Face ID Gen.3) The one-attempt BAF False Accept Rate (FAR) for face authentication shall not exceed 1:1M with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 22. FIA_BMG_EXT.1.1(F4) {MDF}(Face ID Gen.4) The one-attempt BAF False Accept Rate (FAR) for face authentication shall not exceed 1:1M with a one-attempt BAF False Reject Rate (FRR) not to exceed 1 in 44. FIA_BMG_EXT.1.2(T1) {MDF}(Touch ID Gen.1) The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in 10,600 within a 1% margin. FIA_BMG_EXT.1.2(T3) {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. FIA_BMG_EXT.1.2(T4) {MDF}(Touch ID Gen.4) The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in 16,600 within a 1% margin. FIA_BMG_EXT.1.2(F3) {MDF}(Face ID Gen.3) The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in 377,359 within a 1% margin. FIA_BMG_EXT.1.2(F4) {MDF}(Face ID Gen.4) The overall System Authentication False Accept Rate (SAFAR) shall be no greater than 1 in 425,532 within a 1% margin. FIA_BMG_EXT.2 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) VID: 11238 Page 70 of 208 © 2022 Apple Inc. Version: 1.2 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 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 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 Agent 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. Port Access Entity Authentication (FIA_PAE) FIA_PAE_EXT.1 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 Password Management FIA_PMG_EXT.1.1 {MDF} VID: 11238 Page 71 of 208 © 2022 Apple Inc. Version: 1.2 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 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: The TOE 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 {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.2 {MDF} 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. VID: 11238 Page 72 of 208 © 2022 Apple Inc. Version: 1.2 FIA_UAU_EXT.1 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 Timing of Authentication FIA_UAU_EXT.2.1 {MDF} The TSF shall allow answering calls, making emergency calls, accessing Medical ID information, using the cameras (unless their use is generally disallowed), using the flashlight, using the control center, and using the notification center 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 Validation of Certificates FIA_X509_EXT.1.1 {MDF} 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, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met. • The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field • The TSF shall validate the revocation status of the certificate using OCSP as specified in RFC 6960. • 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 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 EKU field. [conditional] o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field. VID: 11238 Page 73 of 208 © 2022 Apple Inc. Version: 1.2 o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field. [conditional] FIA_X509_EXT.1.2 {MDF} 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. FIA_X509_EXT.1/WLAN X.509 Certificate Validation7 FIA_X509_EXT.1.1/WLAN {WLAN} The TSF shall validate certificates for EAP-TLS 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 extendedKeyUsage field according to the following rules: o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. FIA_X509_EXT.1.2/WLAN {WLAN} 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. X509 Certificate Authentication (FIA_X509_EXT) FIA_X509_EXT.2 X509 Certificate Authentication8 FIA_X509_EXT.2.1 {MDF} {VPN} The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for mutually authenticated TLS as defined in the Package for Transport Layer Security, HTTPS, IPsec in accordance with the PP-Module for VPN Client, and code signing for system software updates, code signing for mobile applications, code signing for integrity verification. FIA_X509_EXT.2.2 {MDF} {VPN} When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF shall accept the certificate. 7 TD0439 is applicable to this SFR. 8 TD0623 is applicable to this SFR. VID: 11238 Page 74 of 208 © 2022 Apple Inc. Version: 1.2 FIA_X509_EXT.2/WLAN X509 Certificate Authentication (EAP-TLS)9 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. Request Validation of Certificates (FIA_X509_EXT) FIA_X509_EXT.3 Request Validation of Certificates FIA_X509_EXT.3.1 {MDF} The TSF shall provide a certificate validation service to applications. FIA_X509_EXT.3.2 {MDF} The TSF shall respond to the requesting application with the success or failure of the validation. 9 TD0517 is applicable to this SFR. VID: 11238 Page 75 of 208 © 2022 Apple Inc. Version: 1.2 6.5 Security Management (FMT) Management of Functions in TSF (FMT_MOF) FMT_MOF_EXT.1 Management of Security Functions Behavior10 FMT_MOF_EXT.1.1 {MDF} The TSF shall restrict the ability to perform the functions in column 4 of Table 7 to the user. FMT_MOF_EXT.1.2 {MDF} The TSF shall restrict the ability to perform the functions in column 6 of Table 7 to the administrator when the device is enrolled and according to the administrator-configured policy. Note: The referenced Table 7 is found in [PP_MDF_V3.2]. Trusted Policy Update (FMT_POL) FMT_POL_EXT.2 Agent Trusted Policy Update FMT_POL_EXT.2.1 {AGENT} The MDM Agent shall only accept policies and policy updates that are digitally signed by a certificate that has been authorized for policy updates by the MDM Server. 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 Specification of Management Functions FMT_SMF_EXT.1.1 {MDF} {VPN} The TSF shall be capable of performing the following management functions: 10 TD0658 is applicable to this SFR. VID: 11238 Page 76 of 208 © 2022 Apple Inc. Version: 1.2 Management Function Implemented (FMT_SMF_EXT.1) User Only (FMT_MOF_EXT.1.1) Admin Admin Only (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) (N) Function 4: Enable/disable Bluetooth, Wi-Fi, cellular radio Y (Y) (N) (N) Function 5: Enable/disable cameras: a. across device b. on a per-app basis Y (N) (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: 11238 Page 77 of 208 © 2022 Apple Inc. Version: 1.2 Management Function Implemented (FMT_SMF_EXT.1) User Only (FMT_MOF_EXT.1.1) Admin Admin Only (FMT_MOF_EXT.1.2) Function 11: Import X.509v3 certificates in the Trust Anchor Database Y N Y (Y) Function 12: Remove imported X.509v3 certificates and no other X.509v3 certificates in the Trust Anchor Database Y (N) (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 (N) Function 16: Install applications Y N Y (Y) Function 17: Remove Enterprise applications Y N Y N Function 18: Enable/disable display notifications in the locked state of: f. all notifications Y (N) (Y) (N) Function 19: Enable data-at rest protection Y (N) (N) (N) Function 20: Enable removable media’s data- at-rest protection Y (Y) (N) (N) Function 21: Enable/disable location services: a. across device b. on a per-app basis Y (Y) (N) (N) Function 22: Enable/disable the use of Biometric Authentication Factor Y (N) (Y) (Y) Function 23:11 Configure whether to allow/disallow establishment of a TLS trusted channel if the peer/server certificate is deemed invalid. (Y) (Y) (N) (N) Function 28: Wipe Enterprise data (Y) (N) (Y) N 11 TD0646 is applicable to this SFR. VID: 11238 Page 78 of 208 © 2022 Apple Inc. Version: 1.2 Management Function Implemented (FMT_SMF_EXT.1) User Only (FMT_MOF_EXT.1.1) Admin Admin Only (FMT_MOF_EXT.1.2) Function 30: Configure whether to allow/disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate (Y) (N) (Y) (N) Function 36: Configure the unlock banner (Y) N (Y) (Y) Function 37: Configure the auditable items (Y) N (Y) (N) Function 44: Unenroll the TOE from management Y N Y N Function 45: Enable/disable the Always On VPN protection: a. across device d. no other method Y (N) (Y) (Y) Function 47: Enable/disable microphones on a per-app basis (Y) (Y) (N) (N) Table 6: 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: For function 19, the TOE always provides data at rest protection of internal memory (i.e., it cannot be managed (enabled or disabled)). The KEKs are protected by the passcode feature in the evaluated configuration. Note: Function 20 is supported in the evaluated configuration. Backups can be made using iTunes or iCloud, and backup encryption can be made mandatory. Note: Function 23 is supported by TLS for the user. Function 23 is not supported by the VPN. Note: Function 26 has not been included in the table because the TOE does not support a developer mode. Note: Function 27 has not been included in the table because the TOE (in its evaluated configuration) does not support bypass of local user authentication. VID: 11238 Page 79 of 208 © 2022 Apple Inc. Version: 1.2 Note: Function 32 has not been included in the table because audit review is not implemented on TOE devices. Note: Function 33 has not been included in the table because the feature is not configurable. Note: Functions 24,25,29,31,34,35,38,39,40,41,42,43, and 46 have not been included in the table since the functions are optional. FMT_SMF_EXT.1/BT Specification of Management Functions FMT_SMF_EXT.1.1/BT {BT} The TSF shall be capable of performing the following Bluetooth management functions: Function Implemented User Only Admin Admin Only Function BT-1: Configure the Bluetooth trusted channel. • Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes; Y (Y) (N) (N) 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. FMT_SMF_EXT.1/WLAN Specification of Management Functions (Wireless LAN)12 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 • specify wireless networks (SSIDs) to which the TSF may connect FMT_SMF.1/VPN Specification of Management Functions (VPN) FMT_SMF.1.1/VPN {VPN} The TSF shall be capable of performing the following management functions: • Specify VPN gateways to use for connections, • Specify client credentials to be used for connections, 12 TD0470 is applicable to this SFR. VID: 11238 Page 80 of 208 © 2022 Apple Inc. Version: 1.2 • 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 [MOD_VPNC_V2.3], • ability to update the TOE, and to verify the updates, • ability to configure all security management functions identified in other sections of [MOD_VPNC_V2.3]. FMT_SMF_EXT.2 Specification of Remediation Actions FMT_SMF_EXT.2.1 {MDF} The TSF shall offer remove Enterprise applications, remove all device-stored Enterprise resource data, remove Enterprise secondary authentication data upon unenrollment and no other triggers. FMT_SMF_EXT.4 Specification of Management Functions FMT_SMF_EXT.4.1 {AGENT} The MDM Agent shall be capable of interacting with the platform to perform the following functions: • Import the certificates to be used for authentication of MDM Agent communications, • administrator-provided management functions in MDF PP • no additional functions. FMT_SMF_EXT.4.2 {AGENT} The MDM Agent shall be capable of performing the following functions: • Enroll in management • Configure whether users can unenroll from management • no other functions. User Unenrollment Prevention FMT_UNR_EXT.1 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, apply remediation actions. VID: 11238 Page 81 of 208 © 2022 Apple Inc. Version: 1.2 6.6 Protection of the TSF (FPT) Anti-Exploitation Services (FPT_AEX) FPT_AEX_EXT.1 Application Address Space Layout Randomization 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 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 Stack 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 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 JTAG Disablement FPT_JTA_EXT.1.1 {MDF} The TSF shall disable access through hardware to JTAG. VID: 11238 Page 82 of 208 © 2022 Apple Inc. Version: 1.2 Key Storage (FPT_KST) FPT_KST_EXT.1 Key Storage FPT_KST_EXT.1.1 {MDF} The TSF shall not store any plaintext key material in readable non-volatile memory. FPT_KST_EXT.2 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 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 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 TSF Cryptographic Functionality Testing FPT_TST_EXT.1.1 {MDF} 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. VID: 11238 Page 83 of 208 © 2022 Apple Inc. Version: 1.2 FPT_TST_EXT.1/VPN TSF Self-Test (VPN Client) FPT_TST_EXT.1.1/VPN {VPN} 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/VPN {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/HASH, FCS_COP.1/SIGN, FCS_COP.1/KEYHMAC, or FIA_X509_EXT.1. FPT_TST_EXT.1/WLAN TSF Cryptographic Functionality Testing FPT_TST_EXT.1.1/WLAN {WLAN} 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 {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. TSF Integrity Testing FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel) FPT_TST_EXT.2.1/PREKERNEL {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.2/POSTKERNEL TSF Integrity Checking (Post-Kernel) FPT_TST_EXT.2.1/POSTKERNEL {MDF} The TSF shall verify the integrity of applications 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 TSF Integrity Testing FPT_TST_EXT.3.1 {MDF} The TSF shall not execute code if the code signing certificate is deemed invalid. VID: 11238 Page 84 of 208 © 2022 Apple Inc. Version: 1.2 Trusted Update (FPT_TUD) FPT_TUD_EXT.1 Trusted Update: TSF Version Query FPT_TUD_EXT.1.1 {MDF} The TSF shall provide authorized users the ability to query the current version of the TOE firmware/software. FPT_TUD_EXT.1.2 {MDF} 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} 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 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 verified by the manufacturer trusted key prior to installing those updates. FPT_TUD_EXT.2.2 {MDF} The TSF shall never update the TSF boot integrity key. FPT_TUD_EXT.2.3 {MDF} The TSF shall verify that the digital signature verification key used for TSF updates matches an immutable hardware public key. FPT_TUD_EXT.3 Application Signing FPT_TUD_EXT.3.1 {MDF} The TSF shall verify mobile application software using a digital signature mechanism prior to installation. FPT_TUD_EXT.4 Trusted Update Verification FPT_TUD_EXT.4.1 {MDF} The TSF shall not install code if the code signing certificate is deemed invalid. VID: 11238 Page 85 of 208 © 2022 Apple Inc. Version: 1.2 FPT_TUD_EXT.5 Application Verification FPT_TUD_EXT.5.1 {MDF} The TSF shall by default only install mobile applications cryptographically verified by a built-in X.509v3 certificate. FPT_TUD_EXT.6 Trusted Update Verification FPT_TUD_EXT.6.1 {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: 11238 Page 86 of 208 © 2022 Apple Inc. Version: 1.2 6.7 TOE Access (FTA) Session Locking (FTA_SSL) FTA_SSL_EXT.1 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 Wireless Network Access13 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. 13 TD0470 is applicable to the assurance activities of this SFR. VID: 11238 Page 87 of 208 © 2022 Apple Inc. Version: 1.2 6.8 Trusted Path/Channels (FTP) Bluetooth Trusted Channel Communication (FTP_BLT) FTP_BLT_EXT.1 Bluetooth Encryption FTP_BLT_EXT.1.1 {BT} The TSF shall enforce the use of encryption when transmitting data over the Bluetooth trusted channel for BR/EDR and LE. FTP_BLT_EXT.1.2 {BT} The TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption. FTP_BLT_EXT.2 Persistence of Bluetooth Encryption FTP_BLT_EXT.2.1 {BT} The TSF shall terminate the connection if the remote device stops encryption while connected to the TOE. FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR) FTP_BLT_EXT.3.1/BR {BT} The TSF shall set the minimum encryption key size to 128 bits for BR/EDR and not negotiate encryption key sizes smaller than the minimum size. FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE) FTP_BLT_EXT.3.1/LE {BT} The TSF shall set the minimum encryption key size to 128 bits for LE and not negotiate encryption key sizes smaller than the minimum size. Trusted Channel Communication (FTP_ITC) FTP_ITC_EXT.1 Trusted Channel Communication FTP_ITC_EXT.1.1 {MDF} {VPN} The TSF shall use • 802.11-2012 in accordance with the Extended Package for WLAN Clients, • 802.1X in accordance with the Extended Package for WLAN Clients, • EAP-TLS in accordance with the Extend Package for WLAN Clients, • mutually authenticated TLS as defined in the Package for Transport Layer Security, and VID: 11238 Page 88 of 208 © 2022 Apple Inc. Version: 1.2 • IPsec in accordance with the PP-Module for VPN Client, • HTTPS protocols 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 {MDF} {VPN} The TSF shall permit the TSF to initiate communication via the trusted channel. FTP_ITC_EXT.1.3 {MDF} {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) Trusted Channel Communication Note: The Agent PP-Module modifies FTP_ITC_EXT.1 and is labeled as FTP_ITC_EXT.1(2) for clarity. FTP_ITC_EXT.1.1(2) {AGENT} 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} 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} 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 Trusted Channel Communication (Wireless LAN) FTP_ITC_EXT.1.1/WLAN {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 {WLAN} The TSF shall initiate communication via the trusted channel for wireless access point connections. VID: 11238 Page 89 of 208 © 2022 Apple Inc. Version: 1.2 Trusted Channel Communication (FTP_TRP) FTP_TRP.1(2) Trusted Path (for Enrollment) FTP_TRP.1.1(2) {AGENT} The TSF shall use HTTPS to provide a trusted communication path between itself and another trusted IT product that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data from modification, disclosure. FTP_TRP.1.2(2) {AGENT} The TSF shall permit MD users to initiate communication via the trusted path. FTP_TRP.1.3(2) {AGENT} The TSF shall require the use of the trusted path for all MD user actions. 6.9 Security Functional Requirements Rationale The requirements in the documents in Table 1 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 documents in Table 1 have been copied into this [ST], the dependency analysis for the requirements is assumed to be already performed by the authors of the documents in Table 1 and is not reproduced in this document. VID: 11238 Page 90 of 208 © 2022 Apple Inc. Version: 1.2 7 Security Assurance Requirements The Security Assurance Requirements (SARs) for the TOE are defined in [PP_MDF_V3.2]. 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 are defined in [PP_MDF_V3.2]. These security assurance requirements are also applicable to the [MOD_MDM_AGENT_V1.0], [MOD_BT_V1.0], [MOD_VPNC_V2.3], and [PP_WLAN_CLI_EP_V1.0], and [PKG_TLS_V1.1]. The assurance components in [PP_MDF_V3.2] are as follows. • 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 VID: 11238 Page 91 of 208 © 2022 Apple Inc. Version: 1.2 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 documents in Table 1. The TOE security boundary is described in section 1.5 TOE Architecture above. 8.1 Mapping to the Security Functional Requirements Table 7: Mapping of SFR Assurance Activities to the TSS below provides a mapping of the SFRs defined in section 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: 11238 Page 92 of 208 © 2022 Apple Inc. Version: 1.2 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.4.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 17: 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 {MDF} FAU_GEN.1.2 {MDF} There is no TSS assurance activity for this SFR. 8.10.1 Audit Records. Table 3: Combined mandatory auditable events from [PP_MDF_V3.2] 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 4: Auditable events from [MOD_MDM_AGENT_V1.0] 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_GEN.1.1/BT (BT} FAU_GEN.1.2/BT (BT} Evaluated in the same manner as defined by the Evaluation Activities for the claimed Base-PP. 8.10.1 Audit Records Table 5: Auditable events from [MOD_BT_V1.0] 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: 11238 Page 93 of 208 © 2022 Apple Inc. Version: 1.2 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: 11238 Page 94 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FCS FCS_CKM.1.1 {MDF} {VPN} Identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, it identifies the usage for each scheme. Table 10: 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. Describe how the implementation meets RFC 3526 section 3. 8.9.3 Wireless LAN (Wi-Fi Alliance certificates) FCS_CKM.1.1/VPN {VPN} Describes how the key generation functionality is invoked. 8.9.4.3 IPsec Characteristics FCS_CKM.2.1/UNLOCKED {MDF} {VPN} 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/LOCKED {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 (Wi-Fi Alliance certificates) VID: 11238 Page 95 of 208 © 2022 Apple Inc. Version: 1.2 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 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 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). 8.2.1 The Secure Enclave Processor (SEP) 8.3.1 Overview of Key Management Figure 5: Key Hierarchy in the TOE OS The proprietary Entropy Assessment Report (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 the TOE OS 8.2 Hardware Protection Functions 8.3 Cryptographic Support. VID: 11238 Page 96 of 208 © 2022 Apple Inc. Version: 1.2 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 key encryption keys (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 [SP800-108]. 8.3.1 Overview of Key Management Figure 5: Key Hierarchy in the TOE OS This RBG in the SEP 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} {WLAN} FCS_CKM_EXT.4.2 {MDF} {WLAN} 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 8: Summary of keys and persistent secrets in the TOE OS. Table 9: Summary of keys and persistent secrets used by the MDM Agent VID: 11238 Page 97 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 the TOE OS 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_CKM_EXT.8.1 {BT} Describes the criteria used to determine the frequency of generating new ECDH public/private key pairs and does not permit the use of static ECDH key pairs. 8.9.2 Bluetooth FCS_COP.1.1/ENCRYPT {MDF} {VPN} There is no TSS assurance activity for this SFR. FCS_COP.1.1/HASH {MDF} Documents the association of the hash function with other TSF cryptographic functions. 8.3 Cryptographic Support FCS_COP.1.1/SIGN {MDF} There is no TSS assurance activity for this SFR. VID: 11238 Page 98 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FCS_COP.1.1/KEYHMAC {MDF} 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 10: Explanation of usage for cryptographic functions in the cryptographic modules 8.3 Cryptographic Support 8.4.8 Keyed Hash FCS_COP.1.1/CONDITION {MDF} 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 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. VID: 11238 Page 99 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 security policy database (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: 11238 Page 100 of 208 © 2022 Apple Inc. Version: 1.2 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 VID: 11238 Page 101 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 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 the TOE OS FCS_RBG_EXT.1.1(Kernel and User space) {MDF} FCS_RBG_EXT.1.2(Kernel and User space) {MDF} FCS_RBG_EXT.1.3(Kernel and User space) {MDF} FCS_RBG_EXT.1.1(SEP) {MDF} FCS_RBG_EXT.1.2 (SEP) {MDF} FCS_RBG_EXT.1.3(SEP) {MDF} There is no TSS assurance activity for this SFR. A proprietary Entropy Assessment Report (EAR) has been produced and is on file with NIAP. VID: 11238 Page 102 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 the TOE OS 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 the TOE OS 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 MDM 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 MDM Agent VID: 11238 Page 103 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FCS_TLS_EXT.1 {TLS} There is no TSS assurance activity for this SFR. FCS_TLSC_EXT.1.1 {TLS} 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 {TLS} 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 {TLS} Describes how and when user or administrator authorization is obtained. Describes any mechanism for storing such authorizations, such that future presentation of such otherwise-invalid certificates permits establishment of a trusted channel without user or administrator action. 8.9.1 EAP-TLS and TLS FCS_TLSC_EXT.1.1/WLAN {WLAN} FCS_TLSC_EXT.1.2/WLAN {WLAN} FCS_TLSC_EXT.1.3/WLAN {WLAN} FCS_TLSC_EXT.1.4/WLAN {WLAN} FCS_TLSC_EXT.1.5/WLAN {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 X.509v3 Certificates 8.9.1 EAP-TLS and TLS FCS_TLSC_EXT.2.1 {TLS} Describes for FIA_X509_EXT.2.1 the use of client-side certificates for TLS mutual authentication. Describes any factors beyond configuration that are necessary in order for the client to engage in mutual authentication using X.509v3 certificates. 8.9.1.1 TLS mutual authentication 8.5.2 X.509v3 Certificates VID: 11238 Page 104 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FCS_TLSC_EXT.4.1 {TLS} There is no TSS assurance activity for this SFR. FCS_TLSC_EXT.5.1 {TLS} Describes the Supported Groups Extension. 8.9.1 EAP-TLS and TLS VID: 11238 Page 105 of 208 © 2022 Apple Inc. Version: 1.2 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_ACF_EXT.2.1 {MDF} There is no TSS assurance activity for this SFR. 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 the TOE OS VID: 11238 Page 106 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 11: Keychain to File-system Mapping 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 are 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 11: 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 11: 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 11: Keychain to File-system Mapping VID: 11238 Page 107 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FDP_IFC_EXT.1.1 {MDF} {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) or needed for the correct functioning of the TOE 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 FDP_IFC_EXT.1.1/VPN {VPN} Describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. Describes 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 is 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 FDP_PBA_EXT.1.1 {MDF} Describes the activities that happen during biometric authentication. 8.6.3 Biometric Authentication Factors (BAFs) 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.9.4.6 Residual information protection and packet processing VID: 11238 Page 108 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 X.509v3 Certificates FDP_UPC_EXT.1.1/APPS {MDF} FDP_UPC_EXT.1.2/APPS {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) FDP_UPC_EXT.1.1/BLUETOOTH {MDF} FDP_UPC_EXT.1.2/BLUETOOTH {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: 11238 Page 109 of 208 © 2022 Apple Inc. Version: 1.2 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 {BT} 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 {BT} Describes how data transfer of any type is prevented before the Bluetooth pairing is completed. Specifically calls out any supported radio frequency communication (RFCOMM) and L2CAP data transfer mechanisms 8.9.2 Bluetooth VID: 11238 Page 110 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FIA_BLT_EXT.3.1 {BT} 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 {BT} FIA_BLT_EXT.4.2 {BT} There is no TSS assurance activity for this SFR. FIA_BLT_EXT.6.1 {BT} Describes all Bluetooth profiles and associated services for which explicit user authorization is required before a remote device can gain access. Describes any difference in behavior based on whether or not the device has a trusted relationship with the TOE for that service (i.e. whether there are any services that require explicit user authorization for untrusted devices that do not require such authorization for trusted devices). Describes the method by which a device can become 'trusted'. 8.9.2 Bluetooth FIA_BLT_EXT.7.1 {BT} See FIA_BLT_EXT.6.1. See FIA_BLT_EXT.6.1. FIA_BMG_EXT.1.1(T1) {MDF}(Touch ID Gen.1) FIA_BMG_EXT.1.1(T3) {MDF}(Touch ID Gen.3) FIA_BMG_EXT.1.1(T4) {MDF}(Touch ID Gen.4) FIA_BMG_EXT.1.1(F3) {MDF}(Face ID Gen.3) FIA_BMG_EXT.1.1(F4) {MDF}(Face ID Gen.4) 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 VID: 11238 Page 111 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FIA_BMG_EXT.1.2(T1) {MDF}(Touch ID Gen.1) FIA_BMG_EXT.1.2(T3) {MDF}(Touch ID Gen.3) FIA_BMG_EXT.1.2(T4) {MDF}(Touch ID Gen.4) FIA_BMG_EXT.1.2(F3) {MDF}(Face ID Gen.3) FIA_BMG_EXT.1.2(F4) {MDF}(Face ID Gen.4) Indicates which SAFAR the TOE is targeting and contains evidence supporting the calculations, per Annex C: Biometric Data, 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 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 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 12: MDM Server Reference Identifiers FIA_PAE_EXT.1.1 {WLAN} There is no TSS assurance activity for this SFR. The TOE conforms to IEEE Standard 802.1X for a Port Access Entity (PAE) in the “Supplicant” role. FIA_PMG_EXT.1.1 {MDF} There is no TSS assurance activity for this SFR. VID: 11238 Page 112 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 {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) FIA_X509_EXT.1.1 {MDF} {VPN} {AGENT} FIA_X509_EXT.1.2 {MDF} {VPN} {AGENT} FIA_X509_EXT.1.1/WLAN {WLAN} FIA_X509_EXT.1.2/WLAN {WLAN} Describes where the check of validity of the certificates takes place. Describes the certificate path validation algorithm. 8.5.2 X.509v3 Certificates VID: 11238 Page 113 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 X.509v3 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 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: 11238 Page 114 of 208 © 2022 Apple Inc. Version: 1.2 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 6: 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 6: 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 6: 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 VID: 11238 Page 115 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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. 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. Describes the point in the boot sequence the radios are powered on and indicates if the radios are used as part of the initialization of the device. 8.6.5 Radios Annex A: Devices Covered by this Evaluation Table 6: Management Functions Function 5: Describes each collection device and an indication 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 6: 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 VID: 11238 Page 116 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 8: Summary of keys and persistent secrets in the TOE OS 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 X.509v3 Certificates 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. VID: 11238 Page 117 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference Function 18: There is no TSS assurance activity for this function. Function 19: There is no TSS assurance activity for this function. Function 20: There is no TSS assurance activity for this function. 8.6.2 Configuration Profiles Function 21: There is no TSS assurance activity for this function. Function 22: States if the TOE supports a BAF. Describes the procedure to enable/disable the BAF. 8.6.3 Biometric Authentication Factors (BAFs) Function 23: There is no TSS assurance activity for this function. Function 28 There is no TSS assurance activity for this function. Function 30: 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. VID: 11238 Page 118 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference Function 44: 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 Function 47: Describes all assigned security management functions and their intended behavior. 8.6.2 Configuration Profiles 8.6.6 Audio and Visual collection devices FMT_SMF_EXT.1.1/BT (BT} Describes the Bluetooth profiles and services supported and the Bluetooth security modes and levels supported by the TOE. 8.9.2 Bluetooth Function BT-1: There is no TSS assurance activity for this function. 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.4.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 VID: 11238 Page 119 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FMT_SMF_EXT.4.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: 11238 Page 120 of 208 © 2022 Apple Inc. Version: 1.2 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. It provides a rationale for those binaries and libraries that are not protected in this manner. 8.7.5 Domain Isolation 8.7.8 Inventory of TSF Binaries and Libraries VID: 11238 Page 121 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 Unstructured Supplementary Service Data (USSD) or Man-Machine Interface (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 FPT_JTA_EXT.1.1 {MDF} Explains the location of the Joint Test Action Group (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 VID: 11238 Page 122 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 cryptographic support (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 Processor (SEP) VID: 11238 Page 123 of 208 © 2022 Apple Inc. Version: 1.2 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.3.1.2 No plaintext key transmission and export 8.2.1 The Secure Enclave Processor (SEP) 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 Processor (SEP) 8.3.1.2 No plaintext key transmission and export 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 VID: 11238 Page 124 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference 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 an NTP server or the carrier’s network time as the primary time sources. 8.7.7 Time 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 include 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 {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 and 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: 11238 Page 125 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FPT_TST_EXT.1.1/WLAN {WLAN} FPT_TST_EXT.1.2/WLAN {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/PREKERNEL {MDF} FPT_TST_EXT.2.1/POSTKERNEL {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 VID: 11238 Page 126 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FPT_TUD_EXT.1.1 {MDF} FPT_TUD_EXT.1.2 {MDF} FPT_TUD_EXT.1.3 {MDF} There is no TSS assurance activity for this SFR. 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 (i.e., 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.3.1 {MDF} Describes how mobile application software is verified at installation and uses a digital signature. 8.7.10 Application integrity FPT_TUD_EXT.4.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.5.1 {MDF} Describes how mobile application software is verified at installation using a digital signature by a code signing certificate. 8.5.2 X.509v3 Certificates. VID: 11238 Page 127 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FPT_TUD_EXT.6.1 {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: 11238 Page 128 of 208 © 2022 Apple Inc. Version: 1.2 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: 11238 Page 129 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FTP FTP_BLT_EXT.1.1 {BT} FTP_BLT_EXT.1.2 {BT} Describes the use of encryption, the specific Bluetooth protocol(s) it applies to, and whether it is enabled by default. 8.9.2 Bluetooth FTP_BLT_EXT.2.1 {BT} Describes the TSF’s behavior if a remote device stops encryption while connected to the TOE. 8.9.2 Bluetooth FTP_BLT_EXT.3.1/BR {BT} Specifies the minimum key size for BR/EDR encryption, whether this value is configurable, and the mechanism by which the TOE will not negotiate keys sizes smaller than the minimum. 8.9.2 Bluetooth FTP_BLT_EXT.3.1/LE {BT} Specifies the minimum key size for LE encryption, whether this value is configurable, and the mechanism by which the TOE will not negotiate keys sizes smaller than the minimum. 8.9.2 Bluetooth FTP_ITC_EXT.1.1 {MDF} {VPN} FTP_ITC_EXT.1.2 {MDF} {VPN} FTP_ITC_EXT.1.3 {MDF} {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 16: Protocols used for trusted channels 8.7.3 Secure Software Update. FTP_ITC_EXT.1.1(2) {AGENT} FTP_ITC_EXT.1.2(2) {AGENT} FTP_ITC_EXT.1.3(2) {AGENT} The TSS indicates the methods of MDM 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 X.509v3 Certificates 8.5.3 MDM Server Reference ID VID: 11238 Page 130 of 208 © 2022 Apple Inc. Version: 1.2 SFR TSS Requirements from Assurance Activities TSS Section /Reference FTP_ITC_EXT.1.1/WLAN {WLAN} FTP_ITC_EXT.1.2/WLAN {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 FTP_TRP.1(2) {AGENT} Specifies that for mobile device enrollment, the mobile device initiates a connection over HTTPS to the MDM server. 8.5.3 MDM Server Reference ID Table 7: Mapping of SFR Assurance Activities to the TSS VID: 11238 Page 131 of 208 © 2022 Apple Inc. Version: 1.2 8.2 Hardware Protection Functions 8.2.1 The Secure Enclave Processor (SEP) The SEP is a coprocessor fabricated in all of the Apple processors listed in Annex A: Devices Covered by this Evaluation. 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 SEP execution environment shares the main random access memory (RAM) with the application processor. The memory controller provides memory separation between the two processors by distinguishing between the origin of memory fetch or store requests performed by the processors. In addition, the memory controller encrypts/obfuscates (using AES-XEX) all SEP data in RAM using a key shared only between the SEP and the memory controller. This adds an additional level of protection between the SEP memory and the application processor. If the memory separation between the two processors were violated to where the application processor could access the SEP RAM, the application processor would only see encrypted data. The SEP 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 SEP 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 SEP and the main system is shared. The main system has no access to other memory areas of the SEP and no keys or key material may be exported. Each SEP is provisioned during fabrication with its own 256-bit Unique ID (UID). This UID is used as a key by the device, 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 SEP’s portion of the device’s memory space. Additionally, data that is saved to the file system by the TOE OS is encrypted with a key entangled with the UID and an anti-replay counter. The SEP manages the wrapping and unwrapping of the KEKs associated with the stored data. The UID also serves as the REK for the whole device. In addition to the UID, 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 SEP has its own physical noise source and random number generator which is used for generating the 128-bit salt value for the password-based key generation function (PBKDF, specifically PBKDF2). The PBKDF2 salt is regenerated each time the passcode changes. The salt value is stored AES encrypted with the UID in the system keybag. (The PBKDF2 is discussed in section 8.3.1.1.) Other salt values used for functions in the TOE OS are generated using the True Random Number Generator (TRNG) of the application processor. This includes nonces used in the generation of digital signature algorithm (DSA) signatures as well as nonces required for the Wi-Fi and TLS protocol. VID: 11238 Page 132 of 208 © 2022 Apple Inc. Version: 1.2 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 (i.e., etched into the silicon) in the SEP and is not accessible by the application processor. Even the software in the SEP cannot read the UID. It can only request encryption and decryption operations performed by a dedicated AES engine accessible only from the SEP. The UID is generated during production using the hardware [SP800-90A] DRBG (CTR_DRBG(AES)) of the SEP and then etched into the silicon. 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 [SP800-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 SEP (used to seed the CTR_DRBG) when the TOE OS is first installed or after the device has been wiped. 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 SEP use its true hardware random number generator based on multiple ring oscillators used to seed the CTR_DRBG. The EMF key is the master key used for the encryption of file system metadata. The Dkey is used within the key hierarchy to directly wrap the class keys that can be used when the device is locked. All class keys are generated in the SEP and passed to the TOE OS kernel in wrapped form only. 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 SEP (i.e., FCS_RBG_EXT.1(SEP)). Files are encrypted using this key with AES in Xor-Encrypt-Xor-based tweaked-codebook mode with ciphertext stealing (XTS) where the initialization vector (IV) is calculated with the block offset into the file, encrypted with the SHA-1 hash of the per-file key, and follows [SP800-38E]. On Apple ARM A14 and later devices and M1 and later devices, the encryption uses AES-256 in XTS mode in the SEP. On Apple ARM A9 through A13 devices, the encryption uses AES-128 in XTS mode in the SEP where the 256-bit per file key is split to provide a 128-bit tweak and a 128-bit cipher key. (This is a general Apple ARM processor statement and all aforementioned processors may not be used by the devices in this TOE.) Each per-file key is wrapped (in the SEP) 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 SEP. 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: 11238 Page 133 of 208 © 2022 Apple Inc. Version: 1.2 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). The TOE OS 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) that generates the key encryption key (KEK) for this class key as described above. The device-wide asymmetric key pair is generated within the SEP. 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, the TOE OS generates another asymmetric key pair within the SEP (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 Diffie-Hellman (DH) as described in [SP800-56A]). The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of [SP800-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, because 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. FDP_DAR_EXT.2.2 requires an asymmetric key scheme to be used to encrypt and store sensitive data received while the TOE is locked. The key scheme implemented by the TOE 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 the TOE OS 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 a TOE 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. VID: 11238 Page 134 of 208 © 2022 Apple Inc. Version: 1.2 The keys for both file and Keychain Data Protection classes are collected and managed in keybags. The TOE OS 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, which are used for device update and by MDM, are relevant for functions defined in [PP_MDF_V3.2]. 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 8: Summary of keys and persistent secrets in the TOE OS, summarizes the storage for keys in persistent storage. Key / Persistent Secret Purpose Storage (for all devices) UID REK for device Key entanglement SEP Salt (128 bits) Additional input to one-way functions AES encrypted in the system keybag Key 0x89B Wrapping of EMF key SEP. Block 0 of the flash memory. (Effaceable storage.) Key 0x835 Wrapping of Dkey SEP. Block 0 of the flash memory. (Effaceable storage.) 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 VID: 11238 Page 135 of 208 © 2022 Apple Inc. Version: 1.2 Key / Persistent Secret Purpose Storage (for all devices) WhenUnlockedThisDeviceOnly Stored in wrapped form in persistent storage Dkey Stored in wrapped form in persistent storage NSFileProtectionNone Stored in wrapped form in persistent storage 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/TLS X.509v3 Certificate Keys Used to authenticate IKE/IPsec & TLS sessions Persistently stored encrypted in the platform keychain CA IPsec/TLS X.509v3 Certificate Public Keys Used in X.509v3 certificate validation Persistently stored encrypted in the platform keychain 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 TLS ECDH keys Used as part of TLS key establishment RAM TLS AES session keys Used to encrypt TLS traffic RAM Table 8: Summary of keys and persistent secrets in the TOE OS VID: 11238 Page 136 of 208 © 2022 Apple Inc. Version: 1.2 8.3.1.1 Password based key derivation The TOE implements PBKDF2 to derive a 256-bit key from a user's passcode. The PBKDF2 is implemented as specified in [SP800-132] following “Option 2b” defined in section 5.4 of the standard. It uses HMAC-SHA-256 as the pseudorandom function (PRF). The input to the PBKDF2 is the 128-bit random salt generated by the SEP (as described in section 8.2.1), the user’s passcode without any pre-processing, and an iteration count of one. The output is the 256-bit key mentioned above. Next, the output of the PBKDF2 is repeatedly encrypted with the AES-CBC-256 hardware cipher using the 256- bit UID as the encryption key to generate 256 bits of data with each loop iteration. The loop is performed as often as needed to reach a duration between 100 and 150 milliseconds on that device. The output after all AES iterations have completed forms the 256-bit root encryption key used to unwrap the user’s keybag that holds the class keys for the file system data protection. Only when the unwrapping of the user’s keybag is successful is the user considered authenticated. Note: The number of AES-CBC-256 iterations is calibrated to take at least 100 to 150 milliseconds and is a minimum of 50,000. The number of iterations is device-specific and may be greater than 50,000 on some devices. 8.3.1.2 No plaintext key transmission and export The TOE security boundary is the device. The TOE does not transmit or export plaintext key material outside of the TOE security boundary. Plaintext key material is never logged. Biometric credential data is confined to the SEP. Biometric keying material, enrollment and authentication templates, the features an algorithm uses to perform biometric authentication for enrollment or verification, threshold values, intermediate calculations, and final match scores never leave the SEP. Plaintext keys such as plaintext data encryption keys (DEKs), key encryption keys (KEKs), and keys stored in the secure key storage are never exported. As described in section 8.3.1, the SEP preserves the security of these keys. 8.3.2 Storage of Persistent Secrets and Private Keys by the MDM Agent The MDM Agent calls the TOE OS 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 9: Summary of keys and persistent secrets used by the MDM Agent, summarizes the keys and persistent secrets stored for the MDM Agent. They are used on all devices listed in this [ST]. VID: 11238 Page 137 of 208 © 2022 Apple Inc. Version: 1.2 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 Transferring certificates via payloads. [DEV_MAN] » Profile-Specific Payload Keys » Certificates 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 9: Summary of keys and persistent secrets used by the MDM Agent Figure 5: Key Hierarchy in the TOE OS provides an overview on the key management hierarchy implemented in the TOE OS. VID: 11238 Page 138 of 208 © 2022 Apple Inc. Version: 1.2 Figure 5: Key Hierarchy in the TOE OS 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. The UID (a.k.a. UID key) is not accessible by any software. The “Key 0x89B” and “Key 0x835” keys are both derived by encrypting defined values (identical for all devices) with the UID key. All three keys are stored in the SEP. All other keys shown in the figure are stored in wrapped form in persistent storage and unwrapped when needed. The following bullet points summarize storage of persistent secrets and private keys by the MDM agent. • The keys discussed in this section are managed by and/or maintained in the SEP. The TOE OS and SEP interact with each other using a mailbox system detailed in section 8.2.1. • All file system items and all keychain items are stored in encrypted form only. VID: 11238 Page 139 of 208 © 2022 Apple Inc. Version: 1.2 • File system metadata is encrypted using the EMF key. • Files and keychain 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 keychain 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 [SP800-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. The TOE performs the following activities to protect the keys used for file encryption. Every time the TOE is booted, it does the following. • An ephemeral AES key (256-bit) is created in the SEP using the random number generator of the SEP. • The (wrapped) Dkey and (wrapped) EMF key (both 256-bit keys) are loaded by the TOE OS kernel from the effaceable storage and sent to the SEP. • The SEP unwraps the Dkey and the EMF key. • The SEP wraps the Dkey with the newly generated ephemeral key. • The SEP stores the ephemeral key in the storage controller. This area is not accessible by the TOE OS kernel. When the TOE OS accesses a file, the following operations are performed. • The TOE OS kernel first extracts the file metadata (which are encrypted with the EMF key) and sends them to the SEP. • The SEP decrypts the file metadata and sends it back to the TOE OS kernel. • The TOE OS 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 SEP. • The SEP unwraps the file key and re-wraps it with the ephemeral key and sends this wrapped key back to the TOE OS kernel. • The TOE OS 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 bullet points summarize the storage location for key material. • The UID is stored in the firmware of the SEP in a section not accessible by any program in the SEP or the application processor. The processor in the SEP can only be used to encrypt and decrypt data (with AES- 256) using the UID as the key. • “Key 0x89B” and “Key 0x835” are stored in the SEP. VID: 11238 Page 140 of 208 © 2022 Apple Inc. Version: 1.2 • 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 plaintext in the application processor system. • File keys and Keychain item keys are stored in internal, non-volatile memory, but in wrapped form only. As explained they are never available in plaintext in the application 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. Similarly, ECDH asymmetric keys used for TLS and HTTPS are held in RAM only. They are generated and managed using one of the two libraries, Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] and Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1], 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. 8.3.3 Randomness extraction and expansion step “Concatenating the keys and using a KDF (as described in (SP 800- 56C)” is selected in FCS_CKM_EXT.3 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: VID: 11238 Page 141 of 208 © 2022 Apple Inc. Version: 1.2 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) 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 and the output key length of the KDF are each 256 bits. 8.3.4 Explanation of usage for cryptographic functions Table 10: Explanation of usage for cryptographic functions below, enumerates the various cryptographic functions specified in the SFRs and maps them to their implementation. VID: 11238 Page 142 of 208 © 2022 Apple Inc. Version: 1.2 SFR Cryptographic Function Algorithm Modes / Notes Key/Curve size Implementation Module FCS_CKM.1 Cryptographic Key Generation Asymmetric key pair generation ECDSA KeyGen and KeyVer [FIPS 186-4] (ECC scheme) Notes: Used for TLS and memory encryption scheme. P-256, P-384, Curve25519 vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS Diffie-Hellman Group 14 [RFC 3526] (FFC scheme) Notes: Used for IPsec. MODP-2048 vng_ltc Apple corecrypto User Space Safe-primes [SP800-56A] (FFC scheme) Notes: Used for IPsec. MODP-2048, MODP-3072 vng_ltc Apple corecrypto User Space FCS_CKM.1/VPN Asymmetric key pair generation (for IPsec authentication) ECDSA KeyGen and KeyVer [FIPS 186-4] (ECC scheme) Notes: Used for IPsec. P-256, P-384 vng_ltc Apple corecrypto User Space FCS_CKM.2/UNLOCKED Key establishment RSA [SP800-56B] 2048, 3072, 4096 c_ltc Apple corecrypto User Space ECC Key Establishment (KAS-ECC-SSC Sp800- 56Ar3) [SP800-56A] Scheme: ephemeralUnified P-256, P-384 c_ltc Apple corecrypto User Space Apple SEP SKS Diffie-Hellman Group 14 [RFC 3526] (FFC scheme) Notes: Used for IPsec. MODP-2048 c_ltc Apple corecrypto User Space VID: 11238 Page 143 of 208 © 2022 Apple Inc. Version: 1.2 SFR Cryptographic Function Algorithm Modes / Notes Key/Curve size Implementation Module FFC Key Establishment (KAS-FFC-SSC Sp800- 56Ar3) [SP800-56A] Scheme: dhEphem Notes: Used for IPsec. MODP-2048, MODP-3072 c_ltc Apple corecrypto User Space FCS_CKM.2/LOC KED Key establishment [RFC 7748] Curve25519 Apple SEP SKS FCS_COP.1/ENCRYPT Symmetric encryption/decryption AES [FIPS 197] CCM, GCM [SP800-38C] (CCM), [SP800-38D] (GCM) 128-bit 256-bit vng_asm Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS CBC, XTS [SP800-38A] (CBC), [SP800-38E] (XTS) 128-bit 256-bit asm_arm Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS KW [SP800-38F] (KW) 128-bit 256-bit c_asm Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS CBC [SP800-38A] (CBC) 128-bit, 256-bit SKG (per processor) SEP Hardware CCMP [SP800-38C] (CCM) 128-bit, 256-bit Wi-Fi core/chip Wi-Fi core/chip GCMP [SP800-38D] (GCM) 256-bit Wi-Fi core/chip Wi-Fi core/chip VID: 11238 Page 144 of 208 © 2022 Apple Inc. Version: 1.2 SFR Cryptographic Function Algorithm Modes / Notes Key/Curve size Implementation Module FCS_COP.1/HASH Hashing SHS [FIPS 180-4] SHA-1, SHA-256, SHA-384, SHA-512 (byte-oriented mode) Notes: Used for digital signatures (FCS_COP.1/SIGN), HMACs (FCS_COP.1/KEYHMAC), and KDFs (FCS_CKM_EXT.3, FCS_COP.1/CONDITION). vng_neon for SHA- 256, otherwise, vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS FCS_COP.1/SIGN Digital signature generation; Digital signature verification RSA SigGen [FIPS 186-4] Using SHA-256, SHA-384, SHA-512 Modulo: 2048, 3072, 4096 vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space RSA SigVer [FIPS 186-4] Using SHA-1, SHA-256, SHA-384, SHA-512 Modulo: 2048, 3072, 4096 vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space ECDSA SigGen [FIPS 186-4] Using SHA-256, SHA-384, SHA-512 P-256, P-384, P-521 vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS ECDSA SigVer [FIPS 186-4] Using SHA-1, SHA-256, SHA-384, SHA-512 P-256, P-384, P-521 vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS VID: 11238 Page 145 of 208 © 2022 Apple Inc. Version: 1.2 SFR Cryptographic Function Algorithm Modes / Notes Key/Curve size Implementation Module FCS_COP.1/KEYHMAC Keyed-hash HMAC [FIPS 198-1] HMAC-SHA-1, Block size: 512 Output MAC: 160 greater than or equal to 112 bits vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS HMAC-SHA-256, Block size: 512 Output MAC: 256 greater than or equal to 112 bits vng_neon Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS HMAC-SHA-384, Block size: 1024 Output MAC: 384 greater than or equal to 112 bits vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS HMAC-SHA-512, Block size: 1024 Output MAC: 512 greater than or equal to 112 bits vng_ltc Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS FCS_COP.1/CONDI TION Salted HMAC-SHA and PBKDF2 HMAC-SHA-256 HMAC-SHA-256, Block size: 512 Output MAC: 256 greater than or equal to 112 bits vng_neon Apple corecrypto User Space Apple corecrypto Kernel Space Apple SEP SKS VID: 11238 Page 146 of 208 © 2022 Apple Inc. Version: 1.2 SFR Cryptographic Function Algorithm Modes / Notes Key/Curve size Implementation Module FCS_RBG_EXT.1 (Kernel and User space) Random number generation; Symmetric key generation CTR_DRBG(AES) [SP800-90A] AES-256 256-bit vng_asm Apple corecrypto User Space and Kernel Space FCS_RBG_EXT.1 (SEP) Random number generation; Symmetric key generation CTR_DRBG(AES) [SP800-90A] AES-256 256-bit SKG (per processor) SEP Hardware Table 10: Explanation of usage for cryptographic functions in the cryptographic modules VID: 11238 Page 147 of 208 © 2022 Apple Inc. Version: 1.2 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 the TOE OS allowing users to grant access to these services, or not. 8.4.1 Protection of Files When a new file is created on a TOE 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. If the user has not defined a PIN, then only class D keys exist. All data in files is considered private data, because all files are encrypted. Sensitive data is data protected with a class A or class B key because this data is not accessible when the device is locked. 8.4.2 Application Access to Files An 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 TOE OS 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. VID: 11238 Page 148 of 208 © 2022 Apple Inc. Version: 1.2 When a built-in 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 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. The TOE provides the following separate resources for each app group and allows only applications within that group to access the resources. • Account credential database • Keystore 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 • Tracking • Contacts • Calendars • Reminders VID: 11238 Page 149 of 208 © 2022 Apple Inc. Version: 1.2 • Photos • Bluetooth • Local Network • Microphone • Speech Recognition • Camera • HomeKit • Media & Apple Music • Files and Folders • Motion & Fitness • Focus • Analytics & Improvements • Apple Advertising • App Privacy Report • Record App Activity 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 TOE OS 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. 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 Apple Developer Program or in the TOE OS via application groups. The prefix requirement and application group uniqueness are enforced through code signing, Provisioning Profiles, and the Apple Developer Program. The TOE OS 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 11: Keychain to File-system Mapping, shows the Keychain classes and their equivalent file system classes. VID: 11238 Page 150 of 208 © 2022 Apple Inc. Version: 1.2 Keychain data protection class File data protection class When unlocked NSFileProtectionComplete While locked NSFileProtectionCompleteUnlessOpen After first unlock NSFileProtectionCompleteUntilFirstUserAuthentication Always NSFileProtectionNone Table 11: 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; keychain 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. Keychain items can have associated access control lists (ACLs) to set policies for accessibility and authentication requirements. Thereby, items can have conditions that require user presence, specifying that they cannot be accessed unless authenticated entering the device’s passcode, biometric authentication, etc. ACLs are evaluated inside the SEP 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. Because all the TSF binaries and libraries are protected from stack-based buffer overflow (See 8.7.5, Domain Isolation), it can be 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 peripheral component interconnect express (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 greater than or equal to 112 bits and message digest sizes 160 and 256, 384, 512 bits. 8.5 Identification and Authentication (FIA) The user of the device is authenticated using a passcode, fingerprint, or facial authentication factor. Except for answering calls, making emergency calls, accessing Medical ID information, VID: 11238 Page 151 of 208 © 2022 Apple Inc. Version: 1.2 using the cameras (unless their use is generally disallowed), using the flashlight, using the control center, and using the notification center, 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. For Touch ID, 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 fingerprint samples are presented, then 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 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 and vice versa. 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 has not been unlocked for more than 48 hours. • The passcode has not been used to unlock the device in the last 156 hours (six and a half days) and Face ID has not unlocked the device in the last 4 hours. • The device has received a remote lock command. • After there have been five unsuccessful attempts to match. • After power off/Emergency SOS/Medical ID has been initiated. The number of failed passcode 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. Touch ID and Face ID use a separate failed VID: 11238 Page 152 of 208 © 2022 Apple Inc. Version: 1.2 attempt counter from the passcode counter that is not maintained over a power loss or reboot (i.e., the Touch ID and Face ID failed attempt counter is reset after a power loss or reboot). 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 between consecutive attempts. 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 passcode failed login counter to increment only once for those multiple attempts even though these are all passcode failed login attempts. Different passcodes must be entered in order for the passcode failed login counter to increment. (This description only applies to the passcode failed login counter and does not apply to biometric authentication.) 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 SEP 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 TOE OS 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_MDF_V3.2], test protocols differ between sensor generations as follows. • For Gen.1 (short for generation 1), a full cross-comparison scheme is used. Each user is enrolled and each template is attacked by all other user data. • For Gen.3 and Gen.4 (short for generation 3 and generation 4, respectively), 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. See Annex C: Biometric Data “Proprietary Table 1: Touch ID Test Population” for specific values. 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 VID: 11238 Page 153 of 208 © 2022 Apple Inc. Version: 1.2 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). See Annex C: Biometric Data “Proprietary Table 2: FRR Face ID Test Population” and “Proprietary Table 3: FAR Face ID Test Population” for additional information. 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 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_MDF_V3.2] is derived from tests run for FIA_BMG_EXT.1.1 as noted in section 8.5.1.1, above. Because the TOE 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, as shown in Annex C: Biometric Data “Proprietary Table 4: Touch ID SAFAR”. Similarly, the TOE allows the use of 5 facial identification attempts or 10 attempts of 6-digit passcode, the value of SAFAR is dominated by Face ID SAFAR for 5 attempts, as shown in Annex C: Biometric Data “Proprietary Table 5: Face ID SAFAR”. 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 the TOE OS, 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 VID: 11238 Page 154 of 208 © 2022 Apple Inc. Version: 1.2 • 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 If the sample quality passes verification during enrollment, the TOE saves it as an enrollment template. When a user authenticates, an authentication template is generated. If a properly formatted template contains unusual data properties, incorrect syntax, low quality, or unrealistic modality, the TOE rejects the template. The validation of the discussed mechanism is performed regularly for each major TOE OS 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 X.509v3 Certificates There are a number of X.509v3 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. In addition, root certificates can be downloaded from a web site. Certificates can be installed for the following. • IPsec • TLS • EAP-TLS, other supported EAP protocols • Configuration Profile validation Note that only IPsec, TLS, and EAP-TLS are addressed by [PP_MDF_V3.2]. 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 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 VID: 11238 Page 155 of 208 © 2022 Apple Inc. Version: 1.2 • AppleIPsec • AppleCodeSigning • AppleIDValidation • AppleTimeStamping External entities can be authenticated using a digital certificate. Out of the box, the TOE 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. The TOE OS 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 is not 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 peer certificate (i.e., a certificate received from the other endpoint), the peer certificate is first checked to ensure it is valid as per RFC 5280. Certificates are validated against the Subject Alternative Name (SAN). Wildcards are supported. The Common Name (CN) is ignored. If the SAN 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. The TOE, excluding WLAN, uses the online certificate status protocol (OCSP) for validating the revocation status of certificates. When a connection cannot be established to the OCSP server to determine the revocation status of a certificate, the TOE considers the certificate as not revoked. As part of the certificate chain validation, the validity period of each certificate in the chain is verified. If the certificate is marked as an extended validation certificate, the TOE performs an OCSP lookup to verify the validity (revocation status) of the certificate (except for WLAN certificate validation which does not support OCSP). The basicContraints extension and the CA flag are checked. CA certificates must have the basicContraints extension, the CA flag set to TRUE, and include the caSigning purpose. The extendedKeyUsage (EKU) is validated against the rules defined in FIA_X509_EXT.1 (which is a superset of the rules in FIA_X509_EXT.1/WLAN). Finally, the signature of the issuer of the certificate is verified. Only when all checks succeed, the certificate is considered valid and the next certificate in the certificate chain is checked. VID: 11238 Page 156 of 208 © 2022 Apple Inc. Version: 1.2 The certificate chain searches for the certificates in the trust store. The trust store is a combination of the trust store delivered with the TOE and the certificates stored in the keychain and marked as trustworthy. Certificates from the trusted store are validated using the previously described checks at the time that they are used. Certificate path validation terminates with a certificate in the trust store. 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 (e.g., HTTPS connection) will display a message to the user that the peer certificate validation failed and allow the user to examine the certificate with the option to allow the connection or not. The TOE 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"). Thus, the enrollment is initiated by the device and performed over an HTTPS connection. 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 HTTPS. This identity can be included in the profile as a Certificates payload, or can be generated by enrolling the device with Simple Certificate Enrollment Protocol (SCEP)14 . Each MDM Server must be registered with Apple at the Apple Business Manager (ABM) management portal. The ABM 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. The TOE devices automatically connect to the MDM Server during setup if the device is enrolled into the ABM 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 12: MDM Server Reference Identifiers, below. 14 More information about SCEP can be found RFC 8894 (https://tools.ietf.org/html/rfc8894). VID: 11238 Page 157 of 208 © 2022 Apple Inc. Version: 1.2 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 12: MDM Server Reference Identifiers 8.6 Specification of Management Functions (FMT) In FMT_SMF_EXT.4.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 the same operating system, there are no differences between supported management functions and policies between the different mobile devices. The supported management functions for the TOE OS are described in [DEV_MAN]. Table 6: 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 • Apple Business Manager (This is an automated and enforced method of automatically enrolling new devices.) A more detailed description is found in section 8.5.3, above. In addition, the enrollment process is discussed in [DeployRef]. 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 [DEV_MAN] under Configuration Profiles, Profile-Specific Payload Keys. Configuration Profiles are processed by the TOE OS. VID: 11238 Page 158 of 208 © 2022 Apple Inc. Version: 1.2 The PayloadRemovalDisallowed key—found in [DEV_MAN] under Configuration Profiles, Profile- Specific Payload Keys, TopLevel, object TopLevel—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 as follows. • Using the Apple Configurator 2 tool • Opening a file on the device: o via an email message, o via a web page, o via a files folder. • Using over-the-air configuration as described in [DEV_MAN] under Implementing Device Management, Deploying MDM Enrollment Profiles • Using over-the-air configuration via an MDM Server To preserve the integrity, authenticity, and confidentiality of Configuration Profiles, they can be required to be digitally signed and encrypted. When the signature of the MDM payload is checked, there are the following possible outcomes. • Signature verified • Signature failed • No signature present or signature cannot be verified due to other reasons (e.g., missing CA certificate) If the signature is successfully verified, then the payload is deployed. If the signature fails verification, then the payload is not deployed. If there is no signature or the signature cannot be verified due to other reasons, then the TOE checks the origin of the payload (i.e., its connection). If the connection to the MDM payload origin is trusted (i.e., the certificates can be validated and its signature checks out), the MDM payload is processed as trusted and deployed. This includes the Apple Configurator 2 tool as an MDM origin. (When you enroll the device into the Apple Configurator 2 tool, the device starts trusting the Apple Configurator 2 tool (i.e., it trusts its certificate).) Otherwise, the payload is not deployed. 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 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 VID: 11238 Page 159 of 208 © 2022 Apple Inc. Version: 1.2 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: o allowing or disallowing specific services (e. g. remote backup) or using devices like the cameras, o allowing or disallowing notifications when locked, o allowing or disallowing a prompt when an untrusted certificate is presented in a TLS/HTTPS connection, and o restricting Files USB drive access to encrypted Apple File System (APFS). 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 fingerprint authentication (Touch ID) or facial authentication (Face 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 VID: 11238 Page 160 of 208 © 2022 Apple Inc. Version: 1.2 • the ability for the user to use 'Enable Restrictions' interface. A user can access available management functions via the menus of the graphical user interface. The functions are described in [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 6: 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 [iPad_UG]. 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 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. An authentication template is created from the biometric data and stored inside the SEP. The authentication template cannot be retrieved from the SEP. Instead, the SEP can be asked to compare biometric data to the stored authentication template and will return a success or failure result. VID: 11238 Page 161 of 208 © 2022 Apple Inc. Version: 1.2 8.6.4 Unenrollment The TOE supports both preventing unenrollment from occurring as well as applying remediation actions when a device is unenrolled. [DEV_MAN] describes unenrollment options for the mobile device user through specifying the key "PayloadRemovalDisallowed" (found under Configuration Profiles, Profile-Specific Payload Keys, TopLevel, object TopLevel). 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, [DEV_MAN] describes the additional ability to restrict the installation and removal of Configuration Profiles from other sources. This is achieved using the AccessRights key—found in [DEV_MAN] under Configuration Profiles, Profile-Specific Payload Keys, Managed Devices, object MDM—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. When a device is unenrolled, the TOE’s remediation action is to delete all MDM payloads regardless whether they are locked to the device or not. This includes the following. • Removal of Enterprise applications • Removal of all device-stored Enterprise resource data • Removal of Enterprise secondary authentication data There are no administrator-configurable unenrollment triggers. VID: 11238 Page 162 of 208 © 2022 Apple Inc. Version: 1.2 8.6.5 Radios The following radios are found in the TOE. • Cellular • Wi-Fi • Bluetooth These are fully described, including the frequencies employed, in Annex A: Devices Covered by this Evaluation. As indicated in Table 6: Management Functions, users can enable/disable these radios. Depending on configuration settings, all radios can be enabled at boot time before the user interacts with the device. Any communication requiring credentials, such as a Wi-Fi passcode, can only commence after the user logs into the device for the first time. This is due to the storage of the credentials in the keychain with the protection class of requiring the user having initially logged on. Communication requiring no credentials such as unprotected Wi-Fi may commence before the user logs on in case the radio is enabled as per the system configuration. The radios are not required as part of the initialization of the device (i.e., the device will boot with the radios disabled). 8.6.6 Audio and Visual collection devices The following audio and visual collection devices are found in the TOE. • Cameras • Microphones Table 6: Management Functions describes the roles that can enable/disable them. 8.6.7 VPN Certificate Credentials For the VPN, X.509v3 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.6.8 Removal of applications The following table indicates which application types can be removed along with the role that can remove them. Application type Role allowed to remove the application Built-in applications (e.g., Camera, Calendar, Clock, Contacts, Settings, Messages, Safari, Wallet) Nobody (Some built-in apps allow their icon to be removed, but the app stays installed) User-installed applications User MDM-installed applications MDM-Administrator, User VID: 11238 Page 163 of 208 © 2022 Apple Inc. Version: 1.2 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 are not tampered with. When a TOE 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. Because the Apple Root CA public key resides in immutable code, no software (including unverified or unauthorized software) can modify this public key. 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 TOE OS 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 SEP 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 system on a chip (SoCs) and higher as well as Apple M1 SoC • DFU Mode: Set by Boot ROM on devices with Apple A12 SoC and higher as well as Apple M1 SoC 8.7.2 Joint Test Action Group (JTAG) Disablement The 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. In a development- fused device, certain hardware fuses in the device are not blown during the manufacturing process that are blown in a production-fused device. Only with these development- interface related fuses intact, the JTAG-like interface is technically reachable. • When having a development-fused device, the Apple developers are given a special 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 special 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 VID: 11238 Page 164 of 208 © 2022 Apple Inc. Version: 1.2 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. A request is sent to the mobile device to pull the update from the servers. Mobile device users receive TOE OS update notifications on the mobile device, through the Finder application on macOS versions 10.15.0 (Catalina) and higher, through iTunes on macOS versions prior to 10.15.0 and on a PC. Note that the iTunes application is not available on macOS versions 10.15.0 and higher. Updates are delivered wirelessly, encouraging rapid adoption of the latest security fixes, as well as downloadable through the aforementioned iTunes and Finder applications. The startup process described in section 8.7.1 above helps ensure that only Apple-signed code can be installed on a device. The Apple Root CA public key, which resides in immutable code as described in section 8.7.1, is used in verifying the signed updates. To prevent devices from being downgraded to older versions that lack the latest security updates, the TOE OS 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 OS and exploit a vulnerability that’s been fixed in the newer version. The SEP also utilizes System Software Authorization to ensure the integrity of its software and prevent downgrade installations. The TOE OS software updates can be installed using the Finder application on macOS version 10.15.0 and higher, using iTunes on macOS versions prior to 10.15.0 and on PCs, or over-the-air (OTA) on the device via HTTPS trusted channel. With iTunes and Finder, a full copy of the latest OS 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 macOS Server so that the TOE devices do not need to access Apple servers to obtain the necessary update data. Software updates may also be cached on macOS version 10.13.0 and higher running the built-in caching service (in the client software). During a TOE OS upgrade, Finder/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 Exclusive Chip Identification (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. VID: 11238 Page 165 of 208 © 2022 Apple Inc. Version: 1.2 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 OS version from one device cannot 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 distributes information about security issues in its products through security advisories. Advisories are provided through the security-announce mailing list. Resources include the following. Report a security or privacy vulnerability https://support.apple.com//HT201220 Apple security updates https://support.apple.com//HT201222 Security-announce – Product security notifications and announcements from Apple https://lists.apple.com/mailman/listinfo/security-announce/ 8.7.5 Domain Isolation When a TOE device with cellular capabilities (i.e., a dialer) is in the lock state, only the Emergency Call dialer is available to make a call. The Emergency Call interface does not support the entering of Unstructured Supplementary Service Data (USSD or Man-Machine Interface (MMI) codes. On TOE devices, USSD/MMI codes start with one or more of the following characters: number sign (#), asterisk (*). The Emergency Call interface ignores (i.e., does not send when the Call button is pressed) codes that start with one or more of these characters; thereby, preventing the code actions from executing. The TOE also does not support auxiliary boot modes; therefore, the ability to enter codes using auxiliary boot modes does not exist. 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 the TOE OS. Stack-based buffer overflow protection implementations in the TOE OS 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 VID: 11238 Page 166 of 208 © 2022 Apple Inc. Version: 1.2 • 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 the TOE OS runs as the non-privileged user “mobile,” as do all third-party apps. The entire TOE OS partition is mounted as read-only. Unnecessary tools, such as remote login services, are not included in the system software, and APIs do not allow apps to escalate their own privileges to modify other apps or the TOE OS 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 TOE OS 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 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 (FPT_STM.1). • FAU_GEN.1.2 (Audit record time stamp) • FIA_TRT_EXT.1 (Authentication throttling) • FIA_UAU.7 (Protected authentication feedback) • FIA_X509_EXT.1.1 (TOE certificate expiration validation) • FIA_X509_EXT.3.1 (Application certificate expiration validation) VID: 11238 Page 167 of 208 © 2022 Apple Inc. Version: 1.2 • FMT_SMF_EXT.1.1 Function 1 (Password lifetime) • FMT_SMF_EXT.1.1 Function 2 (Screen-lock timeout management) • FTA_SSL_EXT.1 (Lock state inactivity timeout) 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. 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 The inventory of TSF binaries and libraries is provided in Annex D: 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. 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. In addition, the secure boot process begins in hardware and builds a chain of trust through software using the self-tested corecrypto modules, where each step ensures that the next is properly vetted before handing over control to that TSF executable. Secure boot of the devices ensures that the lowest levels of software are not tampered with and that only trusted operating system software from Apple loads at startup. In the devices, security begins in immutable code called the Boot ROM, which is laid down during chip fabrication and known as the hardware root of trust and continues through the loading of the TSF executables. 8.7.9.1 Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] 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 TOE OS 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 TOE OS 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 files. The TOE OS 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 VID: 11238 Page 168 of 208 © 2022 Apple Inc. Version: 1.2 self-test during startup time is sufficient as it tests the module instance loaded in memory which is subsequently used by every application on the TOE OS. 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 Module v12.0 [Apple ARM, User, Software, SL1] 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. If the followings tests succeed, the device continues with its normal power-up process. 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 SigGen, SigVer Pair-wise consistency checks Encrypt / decrypt KAT, Separate encryption /decryption operations are performed ECDSA SigGen, SigVer Pair-wise consistency checks Diffie-Hellman “Z” computation N/A KAT EC Diffie-Hellman “Z” computation N/A KAT Table 13: Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] Cryptographic Algorithm Tests Software / Firmware Integrity Tests A software integrity test is performed on the runtime image of the Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1]. The module’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. If the test succeeds, the device continues with its normal power-up process. Critical Function Tests No other critical function test is performed on power up. VID: 11238 Page 169 of 208 © 2022 Apple Inc. Version: 1.2 Conditional Tests The following items describe the conditional tests supported by the Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1]. • Pair-wise Consistency Test The module 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. • SP800-90A Assurance Tests The module 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.2 Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] 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 TOE OS Kernel startup process upon device initialization. If the self-tests succeed, the module instance is maintained in the memory of the TOE OS 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 Module v12.0 [Apple ARM, Kernel, Software, SL1] 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. If the followings tests succeed, the device continues with its normal power-up process. VID: 11238 Page 170 of 208 © 2022 Apple Inc. Version: 1.2 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 SigGen, SigVer pair-wise consistency test RSA SigVer KAT Table 14: Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1] Cryptographic Algorithm Tests Software/Firmware Integrity Tests A software integrity test is performed on the runtime image of the Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1]. The module’s HMAC-SHA-256 is used as an Approved algorithm for the integrity test. If the test fails, then the device powers itself off. If the test succeeds, the device continues with its normal power-up process. Critical Function Tests No other critical function test is performed on power up. Conditional Tests The following items describe the conditional tests supported by the Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1]. • Continuous Random Number Generator Test The module performs a continuous random number generator test, whenever CTR_DRBG is invoked. In addition, the seed source implemented in the TOE OS kernel also performs a continuous self-test. • Pair-wise Consistency Test The module 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 module 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. VID: 11238 Page 171 of 208 © 2022 Apple Inc. Version: 1.2 8.7.9.3 Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] [FIPS 140-3] 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 TOE OS 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. If the followings tests succeed, the device continues with its normal power-up process. VID: 11238 Page 172 of 208 © 2022 Apple Inc. Version: 1.2 Cryptographic Algorithm Tests Algorithm Modes Test AES Implementation selected by the module for the corresponding environment AES-128 ECB, CBC KAT15 Separate encryption / decryption operations are performed AES SKG Hardware Accelerator Implementation AES-256 ECB KAT Separate encryption / decryption operations are performed AES SKG Hardware Accelerator Implementation AES-256 CBC KAT Encryption operation is performed Hardware DRBG (CTR_DRBG) N/A KAT HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512 N/A KAT16 ECDSA SigGen, SigVer PCT EC Diffie-Hellman “Z” computation N/A KAT Table 15: Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2] Cryptographic Algorithm Tests Software / Firmware Integrity Tests A software integrity test is performed on the runtime image of the TOE OS. 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. If the test succeeds, the device continues with its normal power-up process. Critical Function Tests No other critical function test is performed on power up. Conditional Tests The following items describe the conditional tests supported by the Apple corecrypto Module v12.0 [Apple ARM, Secure Key Store, Hardware, SL2]. • Pair-wise Consistency Test The module performs pair-wise consistency tests on asymmetric keys generated for ECDSA cipher. • SP800-90A Assurance Tests 15 Self-test is subject to the "selector" approach for the different implementations of AES. 16 Self-test is subject to the "selector" approach for the different implementations of SHA. VID: 11238 Page 173 of 208 © 2022 Apple Inc. Version: 1.2 The module 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 perform known-answer tests and prediction resistance. • Critical Function Test No other critical function test is performed conditionally. 8.7.10 Application integrity Apple issues certificates to TOE OS application developers that developers use to sign their applications. The TOE OS checks each application’s signature to ensure that it was signed using a valid Apple-issued certificate by using a hardware-protected asymmetric key. This applies to both application installation and application execution. 8.8 TOE Access (FTA) 8.8.1 Session Locking The TOE 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. 8.8.2 Restricting Access to Wireless Networks Users and administrators can restrict the wireless networks a TOE device connects to. Using the Configuration Profile administrators can define the wireless networks the device is allowed to connect to using SSIDs 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 Annex A: Devices Covered by this 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. VID: 11238 Page 174 of 208 © 2022 Apple Inc. Version: 1.2 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 the protocols listed in Table 16: Protocols used for trusted channels. Protocol ST requirements Used for 802.11ax In addition to the minimum trusted channel requirements and supported by FCS_COP.1. Wireless access points 802.11ac- 2013 802.11-2012 FTP_ITC_EXT.1.1 {MDF} {VPN} FTP_ITC_EXT.1.1/WLAN {WLAN} Wireless access points 802.1X FTP_ITC_EXT.1.1 {MDF} {VPN} FTP_ITC_EXT.1.1/WLAN {WLAN} WLAN EAP-TLS FTP_ITC_EXT.1.1 {MDF} {VPN} FTP_ITC_EXT.1.1/WLAN {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 {MDF} {VPN} FCS_IPSEC_EXT.1 IPsec VPN Bluetooth 4.2 and 5.0 with BR/EDR and LE FDP_UPC_EXT.1/BLUETOOTH {MDF} Trusted IT products HTTPS FCS_HTTPS_EXT.1.1 {MDF} FDP_UPC_EXT.1/APPS {MDF} FTP_ITC_EXT.1.1 {MDF} {VPN} FTP_ITC_EXT.1.1(2) {AGENT} FTP_TRP.1.1(2) OTA updates; secure communication over a network Table 16: Protocols used for trusted channels IPsec supports authentication using shared keys or certificate-based authentication. The TOE’s TLS client supports certificate-based mutual authentication. 8.9.1 EAP-TLS and TLS For Wi-Fi, 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 VID: 11238 Page 175 of 208 © 2022 Apple Inc. Version: 1.2 • 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 PayloadCertificateAnchorUUID and TLSTrustedServerNames keys 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 also provides mobile applications TLS version 1.2 (client) capabilities via an API service that includes 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_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • 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 the TOE. 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 (P-256) • secp384r1 (P-384) • secp521r1 (P-521) (SigGen/SigVer only) Additional supported elliptic curve extension below is also always enabled by the TOE OS. • Curve25519 The TOE OS supports RSA [SP800-56B] key establishment schemes as both a sender (e.g., when starting a TLS session) and a recipient (e.g., during a rekey triggered by the remote endpoint). VID: 11238 Page 176 of 208 © 2022 Apple Inc. Version: 1.2 When an application uses the provided APIs to attempt to establish a trusted channel, the TOE will compare the Subject Alternative Name (SAN) contained within the peer certificate (specifically the SAN fields, IP Address, and Wildcard certificate if applicable) to the Fully Qualified Domain Name (FQDN) of the requested server. The Common Name (CN) is ignored. If the FQDN in the certificate does not match the expected SAN 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. 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 MDM Agent and the MDM Server is protected by HTTPS (which employs TLS) using the above supported cipher specifications. Certificate pinning is supported and is described in [CertPinning]. 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. WLAN also does not support certificate pinning. 8.9.1.1 TLS mutual authentication For TLS mutual authentication, each application can have one or more client certificates. For X.509 certificates, the TOE allows applications to store client certificates in either a P12 file or in a keychain. A P12 file only holds one client certificate, but a keychain can hold multiple client certificates. For applications that use a P12 file, there is only one client certificate choice when performing TLS mutual authentication. The application passes this choice to the TLS API. For applications that use a keychain, there may be multiple client certificate choices. An application can select the appropriate client certificate from the keychain and pass the selected certificate to the TLS API or it can pass an array of client certificates to the TLS API. The TLS API uses the first certificate in the array and ignores the other certificates in the array when establishing a connection. There are no other factors beyond configuration necessary to engage in mutual authentication. 8.9.1.2 TLS client renegotiation The TOE supports TLS client secure renegotiation through the use of the “renegotiation_info” TLS extension in accordance with RFC 5746. 8.9.2 Bluetooth The TOE supports Bluetooth (4.2 and 5.0) including Basic Rate/Enhanced Data Rate (BR/EDR) and Low Energy (LE) with the following Bluetooth profiles. • Hands-Free Profile (HFP 1.6) • Phone Book Access Profile (PBAP) • Advanced Audio Distribution Profile (A2DP) VID: 11238 Page 177 of 208 © 2022 Apple Inc. Version: 1.2 • Audio/Video Remote Control Profile (AVRCP 1.4) • Personal Area Network Profile (PAN) • Human Interface Device Profile (HID) • Message Access Profile (MAP) By default, Bluetooth is enabled. 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. Explicit user authorization is required. 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 TOE OS) 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. The TOE automatically authorizes the remote Bluetooth device during pairing for all Bluetooth profiles the remote device announces to support during the pairing operation. This approach avoids user confusion between a paired device to which the TOE is connected to but not yet authorized device with which the TOE cannot yet communicate. To de-authorize a device, the user would unpair the device. The TOE establishes a “trusted relationship” with an authorized device at the time of pairing. The only difference in behavior between a trusted device and an untrusted device is that the untrusted device must first be manual authorized as described in the previous paragraph. The TOE 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 Bluetooth Specifications [BT] for details. The TOE generates a new ephemeral ECDH key pair for every new connection attempt. No data can be transferred via Bluetooth until pairing has been completed. The TOE terminates the connection if the remote device stops encryption while connected to the TOE. 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 BR/EDR and LE are secured using 128-bit AES Counter with CBC-MAC (AES-CCM- 128) mode. No other key sizes are supported; thus, smaller key sizes cannot be negotiated. 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 (i.e., pairing and session initialization attempts) from the same BD_ADDR for an established connection will be discarded. For details of the security of Bluetooth/LE see the Bluetooth Specifications [BT]. The TOE supports the Logical Link Control and Adaptation Layer Protocol (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. VID: 11238 Page 178 of 208 © 2022 Apple Inc. Version: 1.2 A service ID is used to identify the local service. 8.9.3 Wireless LAN (WLAN) 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. 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. Newer device models support AES-CCMP-256 with 256-bit keys following IEEE 802.11ac-2013 as well as AES-GCMP-256 with 256-bit key sizes, respectively, following IEEE 802.11ac-2013. The implementation of these AES algorithms is performed by the bulk encryption operation of the Wi-Fi chip. AES key wrapping as defined in [SP800-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 used to unwrap the GTK is performed as described in [SP800-38F] section 6.1, Algorithm 2: W^-1(C), and in section 6.2, Algorithm 4: KW-AD(C). 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. PRF-704 is implemented as defined by IEEE 802.11ac-2013 for TOE device models supporting GCMP. The random bit generator used is the one provided by the main device (i.e., FCS_RBG_EXT.1(Kernel and User space)). The Wi-Fi Alliance certificates for the devices in this evaluation are in Annex B: Wi-Fi Alliance Certificates. 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 for: • the specification of the interfaces (cellular and/or Wi-Fi) for which the VPN is 'AlwaysOn' (default is: for both cellular and Wi-Fi), • the specification of exceptions from this service (only Voicemail, AirPrint, and Cellular Services can be listed as exceptions), and • the definition of exceptions for Captive Networking (if any). The TOE supports separate configurations for cellular and Wi-Fi. VID: 11238 Page 179 of 208 © 2022 Apple Inc. Version: 1.2 Captive networks are also known as "subscription" or "Wi-Fi Hotspot" networks where the user must communicate with the Hotspot (e.g., to log in, to agree to Terms of Use) before gaining access to the network. These are often found in public locations. For a captive network connection using an ‘AlwaysOn’ VPN, the TOE supports the use of a captive network application prior to the VPN establishment on that connection to perform any captive network handling (communication). Once the captive network application completes, the VPN is established and all traffic goes through the VPN. 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-CBC-128, AES-CBC-256 (default), AES-GCM-128, and AES-GCM-256. Single DES and 3DES shall not be used in the evaluated configuration.) • The integrity algorithm allows for SHA1-160, SHA2-256 (default), SHA2-384, and SHA2-512. (SHA1-96 must not be used in the evaluated configuration.) 8.9.4.2 IPsec General IPsec is implemented in the TOE natively, as part of the TOE OS, 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 Core OS Layer described in section 1.5. 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, Voicemail, 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 section 8.9.4.1, is sent through the encrypted tunnel. Any other plaintext data that is received is ignored (discarded). Discarding happens automatically without the need to configure an explicit discard. There are no differences in the routing of IP traffic when using any of the supported baseband protocols. VID: 11238 Page 180 of 208 © 2022 Apple Inc. Version: 1.2 The VPN payload—described in [DEV_MAN] under Configuration Profiles, Profile-Specific Payload Keys, VPN, object VPN—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. The TOE also provides an API for third-party VPN clients. The TOE supports enable/disable of VPN protection both across the device as well as on a per- app basis. (FMT_SMF_EXT.1 Function 3) 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 DH Group 14 (2048-bit MODP), o DH Group 15 (3072-bit MODP), o DH Group 19 (256-bit Random ECP), and o DH Group 20 (384-bit Random ECP). Each of these cryptographic mechanisms are provided by one of the following two cryptographic modules: Apple corecrypto Module v12.0 [Apple ARM, User, Software, SL1] or Apple corecrypto Module v12.0 [Apple ARM, Kernel, Software, SL1]. The key generation and key establishment for VPN are handled in the user space, while the bulk encryption is handled in the kernel space. The VPN seeds its private copy of the CTR_DRBG present in the corecrypto instance used by the VPN client with 384 bits of entropy, invokes the corecrypto ECDH or DH APIs to generate the appropriate keys using key material generated by the CTR_DRBG, and follows the key establishment algorithms defined in [SP800-56A], ECDSA key generation algorithm in [FIPS 186-4], Diffie-Hellman Group (MODP) key generation [RFC 3526], and IKEv2 key derivation function in [RFC 5996]. 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 Subject Alternative Name (SAN) contained within the peer certificate to the SAN of the requested server. If the SAN in the certificate does not match the expected SAN for the peer, then the session will not be established. The Common Name (CN) is ignored. VID: 11238 Page 181 of 208 © 2022 Apple Inc. Version: 1.2 If the SAN in the peer certificate does not match that of the peer's identifier or a SAN does not exist in the peer certificate, the authentication process fails. If the SAN matches the peer's identifier, the authentication process is successful. 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 Apple-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 (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 [CCGUIDE]. 8.9.4.6 Residual information protection and packet processing When a network packet is received, the TCP/IP stack allocates a new buffer in memory of the same size as the incoming packet, then copies the packet into the new buffer, thereby, overwriting the entire allocated buffer. The packet is only referred to by reference/address, not copied. The VPN encrypts and decrypts the packets in-place because the size of the data does not change when using symmetric ciphers. 8.10 Security Audit (FAU) 8.10.1 Audit Records The TOE 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 VID: 11238 Page 182 of 208 © 2022 Apple Inc. Version: 1.2 • 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. • 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 17: MDM Agent Status Commands 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) VID: 11238 Page 183 of 208 © 2022 Apple Inc. Version: 1.2 ErrorChain Array Optional—Array of dictionaries representing the chain of errors that occurred Table 17: 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 [DEV_MAN] under Configuration Profiles, Profile-Specific Payload Keys, Managed Devices, object 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 TOE OS 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: • 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 an HTTPS 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 an 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 HTTPS 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 VID: 11238 Page 184 of 208 © 2022 Apple Inc. Version: 1.2 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 the TOE OS, and never return NotNow. • DeviceInformation • ProfileList • DeviceLock • EraseDevice • ClearPasscode • CertificateList • ProvisioningProfileList • 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 in [DEV_MAN] under Configuration Profiles, Profile-Specific Payload Keys, Managed Devices, object 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. VID: 11238 Page 185 of 208 © 2022 Apple Inc. Version: 1.2 Abbreviations and Acronyms A2DP Advanced Audio Distribution Profile ABM Apple Business Manager ACL Access Control List AES Advanced Encryption Standard APFS Apple File System 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 CBC Cypher Block Chaining CC Common Criteria CCM Counter with CBC-MAC CCMP Counter Mode CBC-MAC Protocol CDMA Code Division Multiple Access CMC Certificate Management over CMS CMS Cryptographic Message Syntax CN Common Name CTR Counter CVE Common Vulnerabilities and Exposures DAR Data at Rest DC-HSDPA Dual-Carrier High Speed Downlink Packet Access DEK Data Encryption Key DES Data Encryption Standard DFU Device Firmware Upgrade DH Diffie-Hellman DMA Direct Memory Access VID: 11238 Page 186 of 208 © 2022 Apple Inc. Version: 1.2 DN Distinguished Name DNS Domain Name Server DRBG Deterministic Random Bit Generator DRNG Deterministic Random Number Generator DSA Digital Signature Algorithm DTLS Datagram Transport Layer Security EAL Evaluation Assurance Level EAP Extensible Authentication Protocol EAPOL Extensible Authentication Protocol Over LAN 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 Signature Algorithm ECID Exclusive Chip Identification EDGE Enhanced Data rates for GSM Evolution EKU extendedKeyUsage EP Extended Package (for a Protection Profile) EST Enrollment over Secure Transport 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 FQDN Fully Qualified Domain Name FRR False Rejection Rate GCM Galois/Counter Mode GID Group Key GPS Global Positioning Satellites GSM Global System for Mobile VID: 11238 Page 187 of 208 © 2022 Apple Inc. Version: 1.2 GTK Group Temporal Key HCI Host Controller Interface HFP Hands-Free Profile HID Human Interface Device Profile HMAC Keyed-hash Message Authentication Code HTTPS Hypertext Transfer Protocol Secure HSDPA High Speed Downlink Packet Access HSPA+ High Speed Packet Access Plus ID Identity IKE Internet Key Exchange IOMMU Input–Output Memory Management Unit IPsec Internet Protocol Security ISA Instruction Set Architecture IV Initialization Vector JSON JavaScript Object Notation JTAG Joint Test Action Group KAT Known Answer Test KDF Key Derivation Function KEK Key Encryption Key KEXT Kernel Extension KW Key Wrap L2CAP Logical Link Control and Adaptation Protocol LE Low Energy LLB Low-Level Bootloader LTE Long Term Evolution 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 VID: 11238 Page 188 of 208 © 2022 Apple Inc. Version: 1.2 MMU Memory Management Unit NDRNG Non-deterministic Random Number Generator NITZ Network, Identity and Time Zone NTP Network Time Protocol OCSP Online Certificate Status Protocol OSP Organizational Security Policy OTA Over-the-Air OTP-ROM One Time Programmable Read-Only Memory PAA Processor Algorithm Accelerator PAE Port Access Entity PAN Personal Area Network Profile PBAP Phone Book Access Profile PBKDF Password-Based Key Derivation Function PCIe Peripheral Component Interconnect Express PHY Physical Layer PKCS Public Key Cryptography Standards POST Power-On Self-Tests PP Protection Profile PRF Pseudorandom Function RAM Random Access Controller RBG Random Bit Generator RFCOMM Radio Frequency Communication 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 SCDMA Synchronous Code Division Multiple Access VID: 11238 Page 189 of 208 © 2022 Apple Inc. Version: 1.2 SCEP Simple Certificate Enrollment Protocol SDIO Secure Digital Input Output SEP Secure Enclave Processor SFR Security Functional Requirement SHA Secure Hash Algorithm SHS Secure Hash Standard SigGen Signature Generation SigVer Signature Verification SKS Secure Key Store SiP System-in-Package SoC System on a Chip 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 UDID Unique Device ID 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 VID: 11238 Page 190 of 208 © 2022 Apple Inc. Version: 1.2 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 VID: 11238 Page 191 of 208 © 2022 Apple Inc. Version: 1.2 Annex A: Devices Covered by this Evaluation This Annex lists the devices that are covered by this evaluation and gives the technical characteristics of each device. The instruction set architecture (ISA)—a.k.a. microarchitecture—is provided with each processor model. Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A9 (ARMv8.0-A) iPad 9.7-inch (5th gen) A1822 802.11 a/b/g/n/ac Wi-Fi only 4.2 Touch ID (Gen.1) 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: 11238 Page 192 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A9X (ARMv8.0-A) iPad Pro 9.7- inch A1673 802.11 /a/b/g/n/ac Wi-Fi only 4.2 Touch ID (Gen.1) 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 Touch ID (Gen.1) 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: 11238 Page 193 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A10 Fusion (ARMv8.1-A) iPad 9.7-inch (6th gen) A1893 802.11 /a/b/g/n/ac Wi-Fi only 4.2 Touch ID (Gen.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) iPad 10.2-inch (7th gen) A2197 802.11 /a/b/g/n/ac Wi-Fi only 4.2 Touch ID (Gen.3) A2200 Wi-Fi only A2199 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 66, 71) A2198 (Hong Kong) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 66, 71) VID: 11238 Page 194 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A10X Fusion (ARMv8.1-A) iPad Pro 12.9-inch (2nd gen) A1670 802.11 /a/b/g/n/ac Wi-Fi only 4.2 Touch ID (Gen.3) 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 Touch ID (Gen.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: 11238 Page 195 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A12 Bionic (ARMv8.3-A) iPad mini (5th gen) A2133 802.11 /a/b/g/n/ac Wi-Fi only 5.0 Touch ID (Gen.3) A2125 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) LTE Advanced (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) A2124 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 46, 66) A2126 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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) iPad Air 10.5- inch (3rd gen) A2152 Wi-Fi only A2154 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) LTE Advanced (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) A2123 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 46, 66) VID: 11238 Page 196 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A2153 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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) iPad 10.2-inch (8th gen) A2270 802.11 /a/b/g/n/ac; dual band (2.4GHz and 5GHz); HT80 with MIMO Wi-Fi only 4.2 Touch ID (Gen.4) A2428 UMTS/HSPA/HSPA+ /DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 66, 71) A2429 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) and 4G LTE Advanced (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, and 66) A2430 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) and 4G LTE Advanced (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, and 66) VID: 11238 Page 197 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A12X Bionic (ARMv8.3-A) iPad Pro 11- inch 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 Face ID (Gen.3) 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) iPad Pro 12.9- inch (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) 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) VID: 11238 Page 198 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A12Z Bionic (ARMv8.3-A) iPad Pro 11- inch (2nd gen) A2068 Wi-Fi 6 (802.11ax) UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (Models A2068 and A2069: bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 34, 38, 39, 40, 41, 42, 46, 48, 66, 71) 5.0 Face ID (Gen.3) A2228 Wi-Fi only A2230 UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (Models A2068 and A2069: bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 34, 38, 39, 40, 41, 42, 46, 48, 66, 71) A2231 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) iPad Pro 12.9- inch (4th gen) A2069 UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (Models A2068 and A2069: bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 34, 38, 39, 40, 41, 42, 46, 48, 66, 71) A2229 Wi-Fi only A2232 UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (Models A2068 and A2069: bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 34, 38, 39, 40, 41, 42, 46, 48, 66, 71) A2233 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz); GSM/EDGE (850, 900, 1800, 1900 MHz) VID: 11238 Page 199 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A13 Bionic (ARMv8.4-A) iPad 10.2-inch (9th gen) A2602 Wi-Fi 6 (802.11ax) Wi-Fi only 4.2 Touch ID (Gen.1) A2603 (US/CA) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) Gigabit-class LTE (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, 66, and 71) A2604 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) Gigabit-class LTE (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, and 66) A2605 UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) Gigabit-class LTE (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, and 66) VID: 11238 Page 200 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A14 Bionic (ARMv8.5-A) iPad Air (4th gen) A2316 Wi-Fi 6 (802.11ax) Wi-Fi only 5.0 Touch ID (Gen.4) A2324 (US/CA) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE (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, 48, 66, 71) A2072 (Global) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) Gigabit-class LTE, (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, 66) A2325 (China) UMTS/HSPA/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) 4G LTE Advanced (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29, 30, 32, 34, 38, 39, 40, 41, 42, 46, 48, 66) VID: 11238 Page 201 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A15 Bionic (ARMv8.6-A) iPad mini (6th gen) A2567 Wi-Fi 6 (802.11ax) Wi-Fi only 5.0 Touch ID (Gen.4) A2568 (Global) 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) A2569 (China) 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) VID: 11238 Page 202 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F M1 (ARMv8.5-A) iPad Pro 11- inch (3rd gen) A2301 (US/CA) Wi-Fi 6 (802.11ax) 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 5G NR mmWave (Bands n260, n261) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) 5.0 Face ID (Gen.4) A2377 Wi-Fi only A2460 (China) 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) iPad Pro 12.9- inch (5th gen) A2378 Wi-Fi 6 (802.11ax) Wi-Fi only 5.0 Face ID (Gen.4) A2379 Wi-Fi only A2461 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 5G NR mmWave (Bands n260, n261) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) VID: 11238 Page 203 of 208 © 2022 Apple Inc. Version: 1.2 Processor (ISA) Device Name Model Number Wi-Fi Cellular Blue- tooth B A F A2462 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66, n71, n77, n78, n79) 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, 71) TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48) UMTS/HSPA/HSPA+/DC‑HSDPA (850, 900, 1700/2100, 1900, 2100 MHz) GSM/EDGE (850, 900, 1800, 1900 MHz) Table 18: Devices Covered by the Evaluation VID: 11238 Page 204 of 208 © 2022 Apple Inc. Version: 1.2 Annex B: Wi-Fi Alliance Certificates The following table lists the Wi-Fi Alliance certificates for the devices covered by this evaluation. Processor Device Name Model Number Wi-Fi Alliance A9 iPad 9.7-inch (5th gen) A1822 WFA70147 / WFA70146 A1823 A9X iPad Pro 9.7-inch A1673 WFA64673 / WFA64672 A1674 A1675 iPad Pro 12.9-inch A1584 WFA61740 / WFA61525 A1652 A10 Fusion iPad 9.7-inch (6th gen) A1893 WFA76394 / WFA76387 A1954 iPad 10.2-inch (7th gen) A2197 WFA90120 / WFA90121 A2198 A2199 A2200 A10X Fusion iPad Pro 12.9-inch (2nd gen) A1670 WFA70412 / WFA70651 A1671 A1821 iPad Pro 10.5-inch A1701 WFA70413 / WFA70652 A1709 A1852 A12 Bionic iPad mini 7.9-inch (5th gen) A2125 WFA81121 / WFA81123 A2133 A2124 A2126 iPad Air 10.5-inch (3rd gen) A2152 WFA81122 / WFA81124 A2154 A2123 A2153 iPad 10.2-inch (8th gen) A2270 WFA101464 / WFA101465 A2428 VID: 11238 Page 205 of 208 © 2022 Apple Inc. Version: 1.2 Processor Device Name Model Number Wi-Fi Alliance A2429 A2430 A12X Bionic iPad Pro 11-inch A1934 WFA78760 A1979 A1980 A2013 iPad Pro 12.9-inch (3rd gen) A2014 WFA77796 A1876 A1895 A1983 A12Z Bionic iPad Pro 11-inch (2nd gen) A2068 WFA96501 / WFA96558 A2228 A2230 A2231 iPad Pro 12.9-inch (4th gen) A2069 WFA94633 / WFA94634 A2229 A2232 A2233 A13 Bionic iPad 10.2-inch (9th gen) A2602 WFA113796 A2603 WFA113795 A2604 WFA113795 A2605 WFA113796 A14 Bionic iPad Air (4th gen) A2316 WFA99939 / WFA99940 A2324 A2072 A2325 A15 Bionic iPad mini (6th gen) A2567 WFA113722 A2568 WFA112068 A2569 WFA112068 M1 iPad Pro 11-inch (3rd gen) A2301 WFA110479 A2377 VID: 11238 Page 206 of 208 © 2022 Apple Inc. Version: 1.2 Processor Device Name Model Number Wi-Fi Alliance A2460 iPad Pro 12.9-inch (5th gen) A2378 WFA110951 A2379 A2461 A2462 Table 19: Wi-Fi Alliance certificates VID: 11238 Page 207 of 208 © 2022 Apple Inc. Version: 1.2 Annex C: Biometric Data The tables in this annex contain proprietary information and only appear in the proprietary version of this ST. In the proprietary ST, this annex contains the tables of biometric data for Apple Touch ID and Apple Face ID referenced in section 8.5.1. VID: 11238 Page 208 of 208 © 2022 Apple Inc. Version: 1.2 Annex D: Inventory of TSF Binaries and Libraries The list in this annex is proprietary and only appears in the proprietary version of the ST. In the proprietary ST, this annex contains the inventory of TSF binaries and libraries required by the Assurance Activity for FPT_AEX_EXT.3. Note that the list is considered proprietary because entries in this list are specifically for internal development and do not reflect the production environment, however, by design one cannot capture the file listing on a production build of the TOE OS.