Apple Inc.

Apple iOS 16: iPhone
Security Target
Version: 1.1
Status: Final
Last Update: 2023-09-26
Validation Body: NIAP
Validation ID: VID11349
Classification: Public
Apple iOS 16: iPhone
Security Target
VID11349
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.
Legal Notice
This document is provided AS IS with no express or implied warranties. Use the information in this document
at your own risk.
This document may be reproduced and distributed only in its original entirety without revision.
Revision History
Version Date Author(s) Changes to Previous Revision
1.0 2023-09-08 Alejandro Masino Final.
1.1 2023-09-26 Alejandro Masino Update in conformance claims.
Version: 1.1 Classification: Public Page 2 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Table of Contents
1 Introduction ......................................................................................................................... 13
1.1 Security Target Identification ........................................................................................................... 13
1.2 TOE Identification ............................................................................................................................ 13
1.3 TOE Type ......................................................................................................................................... 13
1.4 TOE Overview .................................................................................................................................. 13
1.5 TOE Description ............................................................................................................................... 14
1.5.1 Introduction ............................................................................................................................. 14
1.5.1.1 General information ....................................................................................................... 14
1.5.1.2 Obtaining the mobile devices ........................................................................................ 15
1.5.1.3 Obtaining software updates .......................................................................................... 15
1.5.1.4 Supervising and configuring the mobile devices ........................................................... 15
1.5.2 TOE Architecture .................................................................................................................... 16
1.5.2.1 Physical Boundaries ...................................................................................................... 17
1.5.2.2 Security Functions provided by the TOE ...................................................................... 17
1.5.2.2.1 Cryptographic Support ........................................................................................ 17
1.5.2.2.2 User Data Protection ........................................................................................... 21
1.5.2.2.3 Identification and Authentication ......................................................................... 21
1.5.2.2.4 Security Management ......................................................................................... 21
1.5.2.2.5 Protection of the TSF .......................................................................................... 21
1.5.2.2.6 TOE Access ........................................................................................................ 22
1.5.2.2.7 Trusted Path/Channels ....................................................................................... 22
1.5.2.2.8 Audit ................................................................................................................... 22
1.5.3 TOE Documentation ............................................................................................................... 22
2 CC Conformance Claim ........................................................................................................ 25
2.1 Base-PP: Protection Profile for Mobile Device Fundamentals [MDF] .............................................. 25
2.2 PP-Module: collaborative PP-Module for Biometric enrolment and verification - for unlocking the
device [BIO] ............................................................................................................................................. 26
2.3 PP-Module for Bluetooth [BT] ........................................................................................................ 26
2.4 PP-Module for MDM Agents [Agent] .............................................................................................. 27
2.5 PP-Module for Virtual Private Network (VPN) Clients [VPNC] ........................................................ 27
2.6 PP-Module for WLAN Clients [WLANC] ......................................................................................... 28
2.7 Functional Package for Transport Layer Security (TLS) [TLSPKG] ................................................. 28
3 Security Problem Definition ................................................................................................. 30
3.1 Threat Environment ......................................................................................................................... 30
3.1.1 Threats countered by the TOE .............................................................................................. 30
3.2 Assumptions ................................................................................................................................... 33
3.3 Organizational Security Policies ..................................................................................................... 34
4 Security Objectives ............................................................................................................. 36
4.1 Objectives for the TOE ................................................................................................................... 36
4.2 Objectives for the Operational Environment ................................................................................... 39
4.3 Security Objectives Rationale ......................................................................................................... 40
Version: 1.1 Classification: Public Page 3 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
5 Extended Components Definition .......................................................................................... 41
6 Security Requirements ........................................................................................................ 42
6.1 TOE Security Functional Requirements ........................................................................................... 42
6.1.1 Security audit (FAU) .............................................................................................................. 48
6.1.1.1 FAU_ALT_EXT.2 Agent Alerts ...................................................................................... 48
6.1.1.2 FAU_GEN.1 Audit Data Generation .............................................................................. 48
6.1.1.3 FAU_GEN.1(2) Audit Data Generation .......................................................................... 51
6.1.1.4 FAU_GEN.1/BT Audit Data Generation (Bluetooth) ...................................................... 52
6.1.1.5 FAU_GEN.1/VPN Audit Data Generation ...................................................................... 53
6.1.1.6 FAU_GEN.1/WLAN Audit Data Generation (Wireless LAN) .......................................... 54
6.1.1.7 FAU_SAR.1 Audit Review ............................................................................................. 55
6.1.1.8 FAU_SEL.1(2) Security Audit Event Selection .............................................................. 55
6.1.1.9 FAU_STG.1 Audit Storage Protection .......................................................................... 56
6.1.1.10 FAU_STG.4 Prevention of Audit Data Loss ................................................................ 56
6.1.2 Cryptographic support (FCS) ................................................................................................ 56
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation ................................................................. 56
6.1.2.2 FCS_CKM.1/VPN VPN Cryptographic Key Generation (IKE) ........................................ 56
6.1.2.3 FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2/WPA3
Connections) ............................................................................................................................. 57
6.1.2.4 FCS_CKM.2/UNLOCKED Cryptographic Key Establishment ....................................... 57
6.1.2.5 FCS_CKM.2/LOCKED Cryptographic Key Establishment ............................................ 57
6.1.2.6 FCS_CKM.2/WLAN Cryptographic Key Distribution (Group Temporal Key for WLAN)
.................................................................................................................................................... 58
6.1.2.7 FCS_CKM_EXT.1 Cryptographic Key Support ............................................................. 58
6.1.2.8 FCS_CKM_EXT.2 Cryptographic Key Random Generation .......................................... 58
6.1.2.9 FCS_CKM_EXT.3 Cryptographic Key Generation ........................................................ 58
6.1.2.10 FCS_CKM_EXT.4 Key Destruction ............................................................................. 59
6.1.2.11 FCS_CKM_EXT.5 TSF Wipe ....................................................................................... 59
6.1.2.12 FCS_CKM_EXT.6 Salt Generation .............................................................................. 59
6.1.2.13 FCS_CKM_EXT.7 Cryptographic Key Support (REK) ................................................. 60
6.1.2.14 FCS_CKM_EXT.8 Bluetooth Key Generation ............................................................. 60
6.1.2.15 FCS_COP.1/ENCRYPT Cryptographic Operation ....................................................... 60
6.1.2.16 FCS_COP.1/HASH Cryptographic Operation ............................................................. 60
6.1.2.17 FCS_COP.1/SIGN Cryptographic Operation ............................................................... 60
6.1.2.18 FCS_COP.1/KEYHMAC Cryptographic Operation ...................................................... 61
6.1.2.19 FCS_COP.1/CONDITION Cryptographic Operation .................................................... 61
6.1.2.20 FCS_HTTPS_EXT.1 HTTPS Protocol .......................................................................... 61
6.1.2.21 FCS_IPSEC_EXT.1 IPsec ............................................................................................ 62
6.1.2.22 FCS_IV_EXT.1 Initialization Vector Generation .......................................................... 63
6.1.2.23 FCS_RBG_EXT.1/HW Random Bit Generation (Hardware) ........................................ 63
6.1.2.24 FCS_RBG_EXT.1/SW Random Bit Generation (Software) .......................................... 64
6.1.2.25 FCS_SRV_EXT.1 Cryptographic Algorithm Services .................................................. 64
6.1.2.26 FCS_STG_EXT.1 Cryptographic Key Storage ............................................................ 64
6.1.2.27 FCS_STG_EXT.2 Encrypted Cryptographic Key Storage ........................................... 65
Version: 1.1 Classification: Public Page 4 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.2.28 FCS_STG_EXT.3 Integrity of Encrypted Key Storage ................................................ 65
6.1.2.29 FCS_STG_EXT.4 Cryptographic Key Storage ........................................................... 65
6.1.2.30 FCS_TLS_EXT.1 TLS Protocol ................................................................................... 66
6.1.2.31 FCS_TLSC_EXT.1 TLS Client Protocol ....................................................................... 66
6.1.2.32 FCS_TLSC_EXT.1/WLAN TLS Client Protocol (EAP-TLS for WLAN) ......................... 66
6.1.2.33 FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication .............................. 67
6.1.2.34 FCS_TLSC_EXT.4 TLS Client Support for Renegotiation ........................................... 67
6.1.2.35 FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension ................... 67
6.1.2.36 FCS_WPA_EXT.1 Supported WPA Versions .............................................................. 67
6.1.3 User data protection (FDP) ................................................................................................... 68
6.1.3.1 FDP_ACF_EXT.1 Access Control for System Services ................................................. 68
6.1.3.2 FDP_ACF_EXT.2 Access Control for System Resources ............................................. 68
6.1.3.3 FDP_DAR_EXT.1 Protected Data Encryption ............................................................... 68
6.1.3.4 FDP_DAR_EXT.2 Sensitive Data Encryption ................................................................ 68
6.1.3.5 FDP_IFC_EXT.1 Subset Information Flow Control ........................................................ 69
6.1.3.6 FDP_RIP.2 Full Residual Information Protection .......................................................... 69
6.1.3.7 FDP_STG_EXT.1 User Data Storage ............................................................................ 69
6.1.3.8 FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection (Applications) ......... 69
6.1.3.9 FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection (Bluetooth) ... 70
6.1.3.10 FDP_VPN_EXT.1 Split Tunnel Prevention ................................................................... 70
6.1.4 Identification and authentication (FIA) ................................................................................... 70
6.1.4.1 FIA_AFL_EXT.1 Authentication Failure Handling .......................................................... 70
6.1.4.2 FIA_BLT_EXT.1 Bluetooth User Authorization .............................................................. 71
6.1.4.3 FIA_BLT_EXT.2 Bluetooth Mutual Authentication ........................................................ 71
6.1.4.4 FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections .................................... 71
6.1.4.5 FIA_BLT_EXT.4 Secure Simple Pairing ........................................................................ 71
6.1.4.6 FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization .................................... 72
6.1.4.7 FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization ................................. 72
6.1.4.8 FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management ....................... 72
6.1.4.9 FIA_MBE_EXT.1 Biometric enrolment .......................................................................... 72
6.1.4.10 FIA_MBE_EXT.2 Quality of biometric templates for biometric enrolment ................... 72
6.1.4.11 FIA_MBV_EXT.1 Biometric verification ........................................................................ 72
6.1.4.12 FIA_MBV_EXT.2 Quality of biometric samples for biometric verification .................... 73
6.1.4.13 FIA_PAE_EXT.1 Port Access Entity Authentication .................................................... 73
6.1.4.14 FIA_PMG_EXT.1 Password Management ................................................................... 73
6.1.4.15 FIA_TRT_EXT.1 Authentication Throttling .................................................................. 73
6.1.4.16 FIA_UAU.5 Multiple Authentication Mechanisms ....................................................... 73
6.1.4.17 FIA_UAU.6/CREDENTIAL Re-Authenticating (Credential Change) ............................ 74
6.1.4.18 FIA_UAU.6/LOCKED Re-Authenticating (TSF Lock) .................................................. 74
6.1.4.19 FIA_UAU.7 Protected Authentication Feedback ........................................................ 74
6.1.4.20 FIA_UAU_EXT.1 Authentication for Cryptographic Operation .................................... 74
6.1.4.21 FIA_UAU_EXT.2 Timing of Authentication ................................................................. 74
6.1.4.22 FIA_X509_EXT.1 X.509 Validation of Certificates ..................................................... 75
6.1.4.23 FIA_X509_EXT.1/WLAN X.509 Certificate Validation ................................................ 75
Version: 1.1 Classification: Public Page 5 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.4.24 FIA_X509_EXT.2 X.509 Certificate Authentication ................................................... 76
6.1.4.25 FIA_X509_EXT.2/WLAN X.509 Certificate Authentication (EAP-TLS for WLAN) ..... 76
6.1.4.26 FIA_X509_EXT.3 Request Validation of Certificates ................................................. 76
6.1.4.27 FIA_X509_EXT.6 Certificate Storage and Management ............................................ 77
6.1.5 Security management (FMT) ................................................................................................. 77
6.1.5.1 FMT_MOF_EXT.1 Management of Security Functions Behavior ................................... 77
6.1.5.2 FMT_POL_EXT.2 Agent Trusted Policy Update ........................................................... 77
6.1.5.3 FMT_SMF.1 Specification of Management Functions .................................................. 77
6.1.5.4 FMT_SMF.1/VPN Specification of Management Functions (VPN) ............................... 80
6.1.5.5 FMT_SMF.1/WLAN Specification of Management Functions (WLAN Client) ............... 80
6.1.5.6 FMT_SMF_EXT.1/BT Specification of Management Functions ..................................... 81
6.1.5.7 FMT_SMF_EXT.2 Specification of Remediation Actions .............................................. 82
6.1.5.8 FMT_SMF_EXT.4 Specification of Management Functions ......................................... 82
6.1.5.9 FMT_UNR_EXT.1 User Unenrollment Prevention ......................................................... 83
6.1.6 Protection of the TSF (FPT) .................................................................................................. 83
6.1.6.1 FPT_AEX_EXT.1 Application Address Space Layout Randomization ............................ 83
6.1.6.2 FPT_AEX_EXT.2 Memory Page Permissions ............................................................... 83
6.1.6.3 FPT_AEX_EXT.3 Stack Overflow Protection ................................................................ 83
6.1.6.4 FPT_AEX_EXT.4 Domain Isolation ............................................................................... 83
6.1.6.5 FPT_BDP_EXT.1 Biometric data processing ................................................................ 84
6.1.6.6 FPT_JTA_EXT.1 JTAG Disablement ............................................................................ 84
6.1.6.7 FPT_KST_EXT.1 Key Storage ...................................................................................... 84
6.1.6.8 FPT_KST_EXT.2 No Key Transmission ....................................................................... 84
6.1.6.9 FPT_KST_EXT.3 No Plaintext Key Export ................................................................... 84
6.1.6.10 FPT_NOT_EXT.1 Self-Test Notification ..................................................................... 84
6.1.6.11 FPT_PBT_EXT.1 Protection of biometric template ...................................................... 85
6.1.6.12 FPT_STM.1 Reliable Time Stamps ............................................................................. 85
6.1.6.13 FPT_TST_EXT.1 TSF Cryptographic Functionality Testing ........................................ 85
6.1.6.14 FPT_TST_EXT.1/VPN TSF Self-Test .......................................................................... 85
6.1.6.15 FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel) ........................... 85
6.1.6.16 FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel) ...................... 86
6.1.6.17 FPT_TST_EXT.3 TSF Integrity Testing ....................................................................... 86
6.1.6.18 FPT_TST_EXT.3/WLAN TSF Cryptographic Functionality Testing (WLAN Client) ..... 86
6.1.6.19 FPT_TUD_EXT.1 TSF Version Query ......................................................................... 86
6.1.6.20 FPT_TUD_EXT.2 TSF Update Verification ................................................................. 87
6.1.6.21 FPT_TUD_EXT.3 Application Signing ......................................................................... 87
6.1.6.22 FPT_TUD_EXT.4 Trusted Update Verification ........................................................... 87
6.1.6.23 FPT_TUD_EXT.5 Application Verification .................................................................. 87
6.1.6.24 FPT_TUD_EXT.6 Trusted Update Verification ........................................................... 87
6.1.7 TOE access (FTA) ................................................................................................................. 88
6.1.7.1 FTA_SSL_EXT.1 TSF- and User-initiated Locked State ............................................... 88
6.1.7.2 FTA_TAB.1 Default TOE Access Banners .................................................................... 88
6.1.7.3 FTA_WSE_EXT.1 Wireless Network Access ................................................................ 88
6.1.8 Trusted path/channels (FTP) ................................................................................................. 88
Version: 1.1 Classification: Public Page 6 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.8.1 FTP_BLT_EXT.1 Bluetooth Encryption ......................................................................... 88
6.1.8.2 FTP_BLT_EXT.2 Persistence of Bluetooth Encryption ................................................. 89
6.1.8.3 FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR) ................................ 89
6.1.8.4 FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE) ......................................... 89
6.1.8.5 FTP_ITC.1/WLAN Trusted Channel Communication (Wireless LAN) ........................... 89
6.1.8.6 FTP_ITC_EXT.1 Trusted Channel Communication ....................................................... 89
6.1.8.7 FTP_ITC_EXT.1(2) Trusted Channel Communication .................................................. 90
6.1.8.8 FTP_TRP.1(2) Trusted Path (for Enrollment) ............................................................... 90
6.2 Security Functional Requirements Rationale ................................................................................... 91
6.3 Security Assurance Requirements .................................................................................................. 91
6.3.1 ALC Life-cycle support .......................................................................................................... 91
6.3.1.1 ALC_TSU_EXT.1 Timely Security Updates .................................................................... 91
6.4 Security Assurance Requirements Rationale .................................................................................. 92
7 TOE Summary Specification ................................................................................................. 93
7.1 TOE Security Functionality ............................................................................................................. 118
7.1.1 Hardware Protection Functions ............................................................................................. 118
7.1.1.1 The Secure Enclave Processor (SEP) ........................................................................... 118
7.1.2 Cryptographic Support (FCS) ............................................................................................... 119
7.1.2.1 Overview of Key Management ..................................................................................... 119
7.1.2.2 Password based key derivation .................................................................................. 122
7.1.2.3 No plaintext key transmission and export ................................................................... 123
7.1.2.4 Storage of Persistent Secrets and Private Keys by the MDM Agent ........................... 123
7.1.2.5 Randomness extraction and expansion step .............................................................. 127
7.1.2.6 Explanation of usage for cryptographic functions ...................................................... 128
7.1.3 User Data Protection (FDP) .................................................................................................. 131
7.1.3.1 Protection of Files ....................................................................................................... 132
7.1.3.2 Application Access to Files ......................................................................................... 132
7.1.3.3 Declaring the Required Device Capabilities of an Application .................................... 132
7.1.3.4 App Groups ................................................................................................................ 133
7.1.3.5 Restricting Applications Access to Services ............................................................... 133
7.1.3.6 Keychain Data Protection ........................................................................................... 134
7.1.3.7 VPN ............................................................................................................................. 134
7.1.3.8 Keyed Hash ................................................................................................................ 135
7.1.4 Identification and Authentication (FIA) ................................................................................. 135
7.1.4.1 Biometric Authentication ............................................................................................. 136
7.1.4.1.1 Accuracy of Biometric Authentication ................................................................ 136
7.1.4.1.2 Biometric Sample Quality ................................................................................... 137
7.1.4.2 X.509v3 Certificates .................................................................................................. 138
7.1.4.3 MDM Server Reference ID .......................................................................................... 139
7.1.5 Specification of Management Functions (FMT) ................................................................... 140
7.1.5.1 Device Enrollment ....................................................................................................... 140
7.1.5.2 Configuration Profiles .................................................................................................. 141
7.1.5.3 Biometric Authentication Factors (BAFs) .................................................................... 143
Version: 1.1 Classification: Public Page 7 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.5.4 Device Unenrollment .................................................................................................. 143
7.1.5.5 Radios ......................................................................................................................... 144
7.1.5.6 Audio and Visual collection devices ........................................................................... 145
7.1.5.7 VPN Certificate Credentials ........................................................................................ 145
7.1.5.8 Removal of applications ............................................................................................. 145
7.1.6 Protection of the TSF (FPT) ................................................................................................. 145
7.1.6.1 Secure Boot ................................................................................................................ 145
7.1.6.2 Joint Test Action Group (JTAG) Disablement ............................................................ 146
7.1.6.3 Secure Software Update ............................................................................................ 146
7.1.6.4 Security Updates ........................................................................................................ 147
7.1.6.5 Domain Isolation ......................................................................................................... 148
7.1.6.6 Device Locking ........................................................................................................... 148
7.1.6.7 Time ............................................................................................................................ 149
7.1.6.8 Inventory of TSF Binaries and Libraries ...................................................................... 149
7.1.6.9 Self-Tests ................................................................................................................... 149
7.1.6.9.1 Apple corecrypto Module v13.0 [Apple ARM, User, Software, SL1] ................... 149
7.1.6.9.2 Apple corecrypto Module v13.0 [Apple ARM, Kernel, Software, SL1] ................ 151
7.1.6.9.3 Apple corecrypto Module v13.0 [Apple ARM, Secure Key Store, Hardware,
SL2] .................................................................................................................................... 152
7.1.6.9.4 Application integrity .......................................................................................... 153
7.1.7 TOE Access (FTA) ................................................................................................................ 153
7.1.7.1 Session Locking .......................................................................................................... 153
7.1.7.2 Restricting Access to Wireless Networks ................................................................... 154
7.1.7.3 Lock Screen/Access Banner Display .......................................................................... 154
7.1.8 Trusted Path/Channels (FTP) ............................................................................................... 154
7.1.8.1 EAP-TLS and TLS ....................................................................................................... 155
7.1.8.1.1 TLS mutual authentication ................................................................................. 156
7.1.8.1.2 TLS client renegotiation ..................................................................................... 156
7.1.8.2 Bluetooth .................................................................................................................... 156
7.1.8.3 Wireless LAN (WLAN) ................................................................................................ 158
7.1.8.4 VPN ............................................................................................................................ 158
7.1.8.4.1 AlwaysOn VPN .................................................................................................. 158
7.1.8.4.2 IPsec General .................................................................................................... 159
7.1.8.4.3 IPsec Characteristics ........................................................................................ 159
7.1.8.4.4 Peer authentication ........................................................................................... 160
7.1.8.4.5 IKE ..................................................................................................................... 160
7.1.8.4.6 Residual information protection and packet processing .................................... 161
7.1.9 Security Audit (FAU) ............................................................................................................. 161
7.1.9.1 Audit Records .............................................................................................................. 161
7.1.9.2 MDM Agent Alerts ....................................................................................................... 161
7.1.9.2.1 Queuing of Alerts .............................................................................................. 163
7.1.9.2.2 Alerts on successful application of policies ...................................................... 163
7.1.9.2.3 Alerts on receiving periodic reachability events ................................................ 164
8 Abbreviations, Terminology, and References ...................................................................... 165
Version: 1.1 Classification: Public Page 8 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
8.1 Abbreviations ................................................................................................................................. 165
8.2 References .................................................................................................................................... 174
A Appendixes ....................................................................................................................... 180
A.1 Devices Covered by this Evaluation .................................................................................. 180
A.2 Wi-Fi Alliance Certificates ............................................................................................... 202
A.3 SFR to CAVP certificate mappings .................................................................................. 205
A.4 Inventory of TSF Binaries and Libraries ............................................................................ 212
Version: 1.1 Classification: Public Page 9 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
List of Tables
Table 1: TOE documents .......................................................................................................................... 22
Table 2: NIAP TDs for MDF ..................................................................................................................... 25
Table 3: NIAP TDs for BIO ....................................................................................................................... 26
Table 4: NIAP TDs for BT ........................................................................................................................ 26
Table 5: NIAP TDs for Agent ................................................................................................................... 27
Table 6: NIAP TDs for VPNC ................................................................................................................... 27
Table 7: NIAP TDs for WLANC ................................................................................................................ 28
Table 8: NIAP TDs for TLSPKG ............................................................................................................... 28
Table 9: SFRs for the TOE ....................................................................................................................... 42
Table 10: Mandatory Auditable Events (MDF) ......................................................................................... 49
Table 11: Auditable Events (Agent) .......................................................................................................... 51
Table 12: Auditable Events (BT) .............................................................................................................. 52
Table 13: Auditable Events (VPN) ............................................................................................................ 53
Table 14: Auditable Events (WLAN) ........................................................................................................ 54
Table 15: Management Functions (MDF/VPNC) ...................................................................................... 78
Table 16: Management Functions (WLANC) ........................................................................................... 80
Table 17: Management Functions (BT) .................................................................................................... 81
Table 18: SARs ......................................................................................................................................... 91
Table 19: SFR to TSS mappings .............................................................................................................. 93
Table 20: Summary of keys and persistent secrets in the TOE OS ........................................................ 121
Table 21: Summary of keys and persistent secrets used by the MDM Agent ........................................ 123
Table 22: Explanation of usage for cryptographic functions in the cryptographic modules ................... 128
Table 23: Keychain to File-system Mapping .......................................................................................... 134
Table 24: MDM Server Reference Identifiers ......................................................................................... 140
Table 25: Removal of applications ......................................................................................................... 145
Table 26: Cryptographic Algorithm Tests .............................................................................................. 150
Table 27: Cryptographic Algorithm Tests ............................................................................................... 151
Table 28: Cryptographic Algorithm Tests .............................................................................................. 152
Table 29: Protocols used for trusted channels ...................................................................................... 154
Table 30: MDM Agent Status Commands .............................................................................................. 161
Table 31: SoC to ISA mappings ............................................................................................................. 180
Table 32: iPhone: A11 Bionic (ARMv8.2-A) models ............................................................................... 180
Table 33: iPhone: A12 Bionic (ARMv8.3-A) models .............................................................................. 182
Table 34: iPhone: A13 Bionic (ARMv8.4-A) models .............................................................................. 184
Table 35: iPhone: A14 Bionic (ARMv8.5-A) models .............................................................................. 186
Version: 1.1 Classification: Public Page 10 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Table 36: iPhone: A15 Bionic (ARMv8.6-A) models .............................................................................. 190
Table 37: iPhone: A16 Bionic (ARMv8.6-A) models .............................................................................. 198
Table 38: iPhone: Wi-Fi Alliance certificates ......................................................................................... 202
Table 39: SFRs to CAVP certificates for iPhones .................................................................................. 207
Table 40: Broadcom core supported algorithms and CAVP certificates for iPhones ............................. 210
Version: 1.1 Classification: Public Page 11 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
List of Figures
Figure 1: TOE OS layers ........................................................................................................................... 16
Figure 2: Block Diagram of the Apple corecrypto Module v13.0 [Apple ARM, User, Software, SL1] ...... 18
Figure 3: Block Diagram of the Apple corecrypto Module v13.0 [Apple ARM, Kernel, Software, SL1] ..... 19
Figure 4: Block Diagram of the Apple corecrypto Module v13.0 [Apple ARM, Secure Key Store, Hardware,
SL2] ................................................................................................................................................... 20
Figure 5: Key Hierarchy in the TOE OS .................................................................................................. 125
Version: 1.1 Classification: Public Page 12 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
1 Introduction
1.1 Security Target Identification
Title: Apple iOS 16: iPhone Security Target
Version: 1.1
Status: Final
Date: 2023-09-26
Sponsor: Apple Inc.
Developer: Apple Inc.
Validation Body: NIAP
Validation ID: VID11349
Keywords: Apple, iPhone, iOS, mobile device
1.2 TOE Identification
The TOE is the Apple iPhone with Apple iOS Version 16.3.
1.3 TOE Type
The TOE type is mobile device.
1.4 TOE Overview
This document is the Common Criteria (CC) Security Target (ST) for the following:
● Apple iOS 16: iPhones
The devices were tested using the following operating system release:
● iOS 16.3
The iPhone hardware platforms covered by this evaluation are provided in Appendix A.1 "Devices Covered by
this Evaluation". The listed hardware platforms, with Apple iOS 16.3 installed, were evaluated as mobile devices
in exact conformance with the protection profiles listed in Section 2 "CC Conformance Claim".
The TOE is a series of Apple iPhone mobile devices running the iOS 16 operating system and includes
components such as a Mobile Device Management (MDM) Agent, VPN client, WLAN client, Bluetooth, and
biometric authentication factors (BAFs).
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.
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.
Version: 1.1 Classification: Public Page 13 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 multiple 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.
From a hardware perspective, the devices use System on a Chip (SoC) technology. Each SoC contains multiple
components including the following:
● Application processor
● Secure Enclave
❍ Secure Enclave Processor (SEP)
❍ True Random Number Generator (TRNG)
❍ Secure Enclave AES Engine
The application processor runs the rich OS (i.e., iOS 16.3).
The Secure Enclave is a dedicated secure subsystem integrated into the SoC. It is isolated from the application
processor to provide an extra layer of security and is designed to keep sensitive user data secure even when
the application processor's kernel becomes compromised.
The Secure Enclave includes the SEP, which runs sepOS. (sepOS is bundled with the TOE OS.) The Secure
Enclave also includes a hardware TRNG and hardware AES engine. The TRNG and AES engine are directly
connected to the SEP and are only accessible through the SEP.
1.5 TOE Description
1.5.1 Introduction
1.5.1.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 Appendix A.1 "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.
Version: 1.1 Classification: Public Page 14 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TOE does not include the user apps that run on top of the operating system but does include controls that
limit the behavior of the apps 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.
1.5.1.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://www.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.5.1.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 through the Settings » General » Software
Update interface. Installation of the latest version of the operating system can be performed automatically (if
Automatic Updates is enabled), 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.5.1.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 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 Security Target. The evaluated configuration for this includes the following:
● 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
Version: 1.1 Classification: Public Page 15 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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
● The requirement of the certificates in the trust anchor database
1.5.2 TOE Architecture
The implementation of TOE architecture can be viewed as a set of layers, which are shown in Figure 1, below.
Lower layers contain fundamental services and technologies. Higher-level layers build upon the lower layers and
provide more sophisticated services and technologies.
Figure 1: 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.
Version: 1.1 Classification: Public Page 16 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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)
● The System Framework, providing the kernel environment, drivers, and low-level UNIX interfaces
(the kernel manages the virtual memory system, threads, file system, network, and inter-process
communication and is therefore responsible for separating apps from each other and controlling the
use of low-level resources)
The TOE is managed by an MDM solution that enables an enterprise to control and administer the TOE instances
that are enrolled in the MDM solution.
1.5.2.1 Physical Boundaries
The TOE's physical boundaries are those of the mobile devices.
1.5.2.2 Security Functions provided by the TOE
The TOE provides the security functionality required by the protection profiles listed in Section 2 "CC
Conformance Claim".
1.5.2.2.1 Cryptographic Support
The TOE provides cryptographic services via the following cryptographic modules:
● Apple corecrypto Module v13.0 [Apple ARM, User, Software, SL1] (User Space)
● Apple corecrypto Module v13.0 [Apple ARM, Kernel, Software, SL1] (Kernel Space)
● Apple corecrypto Module v13.0 [Apple ARM, Secure Key Store, Hardware, SL2] (SKS)
The Apple corecrypto Module v13.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.
Version: 1.1 Classification: Public Page 17 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Figure 2 below shows the logical boundary of the Apple corecrypto Module v13.0 [Apple ARM, User, Software,
SL1] within the TOE.
Figure 2: Block Diagram of the Apple corecrypto Module v13.0 [Apple ARM, User, Software, SL1]
Note that the Wi-Fi chip performs the bulk AES cryptography for Wi-Fi communications. See Section 7.1.8.3
"Wireless LAN (WLAN)" 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
Version: 1.1 Classification: Public Page 18 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The Apple corecrypto Module v13.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 v13.0 [Apple ARM, Kernel, Software,
SL1] within the TOE.
Figure 3: Block Diagram of the Apple corecrypto Module v13.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
● Key wrapping
Version: 1.1 Classification: Public Page 19 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The Apple corecrypto Module v13.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. It contains both firmware and hardware
cryptographic algorithm implementations. (The Secure Key Store is also known as the SKS.)
The cryptographic services provided by the module are the following:
● 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 v13.0 [Apple ARM, Secure Key Store,
Hardware, SL2] within the TOE.
Figure 4: Block Diagram of the Apple corecrypto Module
v13.0 [Apple ARM, Secure Key Store, Hardware, SL2]
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.
Version: 1.1 Classification: Public Page 20 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
1.5.2.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.2.3 Identification and Authentication
The user must authenticate using a passcode or a biometric (fingerprint or face) to use the device except when
performing the following:
● Accessing Medical ID information
● Answering calls
● Making emergency calls
● Using the cameras (unless their use is generally disallowed)
● Using the control center
● Using the flashlight
● Using the notification center
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 (including biometric enrollment)
● Install iOS 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.
The TOE's biometric face authentication is known as Face ID and its fingerprint authentication is known as Touch
ID. There are also multiple generations of these BAFs.
External entities connecting to the TOE via a secure protocol (e.g., Transport Layer Security (TLS), Extensible
Authentication Protocol Transport Layer Security (EAP-TLS), IPsec) can be authenticated using X.509
certificates.
1.5.2.2.4 Security Management
The security functions listed in Table 15, Table 16, and Table 17 can be managed either by the user or by an
authorized administrator through an MDM system. These tables identify the functions that can be managed and
indicate if the management can be performed by the user, by the authorized administrator, or both.
1.5.2.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.
Version: 1.1 Classification: Public Page 21 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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 startup—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.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.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 (v1.1, v1.2)
● TLS (v1.2)
● IPsec
● Bluetooth (v5.0, v5.3)
1.5.2.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.
Table 1: TOE documents
Reference Document name & location Location
Mobile Device Administrator Guidance
[CCGUIDE]☝ Apple iOS 16: iPhones and Apple
iPadOS 16: iPads Common Criteria
Configuration Guide
https://www.niap-ccevs.org/MMO/Product/ st_vid11
349-agd.pdf
[DEV_MAN]☝ Device Management https://developer.apple.com/documentation/ device
management
Mobile Device User Guidance
[iPhone_UG]☝ iPhone User Guide iOS 16.3 (2022) The latest iPhone User Guide:
Version: 1.1 Classification: Public Page 22 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Reference Document name & location Location
(This version is no longer available,
but screenshots exist in [CCGUIDE]☝.)
https://support.apple.com/guide/iphone/ welcome/io
s
[PASSCODE-Help]☝ Use a passcode with your iPhone, iPad
or iPod touch
https://support.apple.com/en-us/HT204060
International:
https://support.apple.com/HT204060
[BLUETOOTH_HELP]☝ 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/HT204091
Mobile Device Management
[AConfig]☝ Apple Configurator 2 User Guide
(online)
https://support.apple.com/guide/apple- configurato
r-2/welcome/mac
[ABM_Guide]☝ Apple Business Manager User Guide https://support.apple.com/guide/apple- business-m
anager/welcome/web
[PM_Help]☝ Profile Manager User Guide for macOS
Monterey
https://support.apple.com/guide/profile- manager/w
elcome/mac
Supporting Documents
[DeployRef]☝ Apple Platform Deployment https://support.apple.com/guide/deployment/ welco
me/web
[LOGGING]☝ Logging https://developer.apple.com/documentation/ os/log
ging?language=objc
[PROFS_LOGS]☝ Profiles and Logs https://developer.apple.com/bug-reporting/ profiles
-and-logs/?platforms=ios
[TRUST_STORE]☝ List of available trusted root
certificates in iOS 16, iPadOS 16,
macOS 13, tvOS 16, and watchOS 9
https://support.apple.com/en-us/HT213464
International:
https://support.apple.com/HT213464
[MANAGE_CARDS]☝ Change or remove the payment cards
that you use with Apple Pay
https://support.apple.com/en-us/HT205583
International:
https://support.apple.com/HT205583
[PAY_SETUP]☝ Set up Apple Pay https://support.apple.com/en-us/HT204506
International:
https://support.apple.com/HT204506
[CONTENT-CACHING]☝ Set up content caching on Mac https://support.apple.com/en-euro/guide/mac-help/
mchl3b6c3720/13.0/mac/13.0
[APFS_DOC]☝ File system formats available in Disk
Utility on Mac
https://support.apple.com/en-euro/guide/disk-utility
/dsku19ed921c/22.0/mac/13.0
App Developer Guidance
[CKTSREF]☝ Certificate, Key, and Trust Services https://developer.apple.com/documentation/ securit
y/certificate_key_and_trust_services
Version: 1.1 Classification: Public Page 23 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Reference Document name & location Location
[KEYCHAINPG]☝ Keychain Services https://developer.apple.com/documentation/ securit
y/keychain_services
[AP_SEC]☝ Apple Platform Security https://help.apple.com/pdf/security/en_US/ apple-pl
atform-security-guide.pdf
[APFS_DEV_DOC]☝ About Apple File System https://developer.apple.com/documentation/ founda
tion/file_system/ about_apple_file_system
[CertPinning]☝ Identity Pinning: How to configure
server certificates for your app
https://developer.apple.com/news/?id=g9ejcf8y
Version: 1.1 Classification: Public Page 24 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
2 CC Conformance Claim
This Security Target is CC Part 2 extended and CC Part 3 extended. Common Criteria [CC] version 3.1 revision
5 is the basis for this conformance claim.
This Security Target claims exact conformance to the "PP-Configuration for Mobile Device Fundamentals,
Biometric enrollment and verification – for unlocking the device, Bluetooth, MDM Agents, Virtual Private Network
(VPN) Clients, and WLAN Clients, version 1.0 [PP-Config]☝ (CFG_MDF-BIO-BT-MDMA-VPNC-WLANC_V1.0).
The PP configuration includes:
● [MDF]☝: Base-PP: Protection Profile for Mobile Device Fundamentals. Version 3.3 (PP_MDF_V3.3) as
of 2022-09-12.
● [BIO]☝: PP-Module: collaborative PP-Module for Biometric enrolment and verification - for unlocking
the device - [BIOPP-Module]. Version 1.1 (MOD_CPP_BIO_V1.1) as of 2022-09-12.
● [BT]☝: PP-Module for Bluetooth. Version 1.0 (MOD_BT_V1.0) as of 2021-04-15.
● [Agent]☝: PP-Module for MDM Agents. Version 1.0 (MOD_MDM_AGENT_V1.0) as of 2019-04-25.
● [VPNC]☝: PP-Module for Virtual Private Network (VPN) Clients. Version 2.4 (MOD_VPNC_V2.4) as of
2022-03-31.
● [WLANC]☝: PP-Module for WLAN Clients. Version 1.0 (MOD_WLANC_V1.0) as of 2022-03-31.
In addition this ST claims conformance to the following functional package:
● [TLSPKG]☝: Functional Package for Transport Layer Security (TLS). Version 1.1 (PKG_TLS_V1.1) as
of 2019-03-01.
The following sections describes the use cases that each document covers and the technical decisions applied.
2.1 Base-PP: Protection Profile for Mobile Device Fundamentals [MDF]
This document claims conformance to the following MDF Use Cases:
● [Use Case 3] Personally-owned device for personal and enterprise use: A personally-owned
device that is used for both personal activities and enterprise data is commonly called Bring Your
Own Device (BYOD). The device may be provisioned for access to enterprise resources after
significant personal usage has occurred.
● [Use Case 4] Personally-owned device for personal and limited enterprise use: A personally-
owned device that is used for both personal activities and enterprise data is commonly called Bring
Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources
such as enterprise email.
Table 2 contains the NIAP Technical Decisions (TDs) for this protection profile at the time of the evaluation and
a statement of applicability to the evaluation.
Table 2: NIAP TDs for MDF
NIAP TD TD description Applicable? Non-applicability rationale
TD0724 Format corrections for FAU_GEN.1.1 in MDF
3.3
Yes
TD0704 Part 3 (Extended) in CC Conformance
Claims for MDF 3.3
Yes
TD0689 RFC Update in FIA_X509_EXT.1 for MDF PP
v3.3
Yes
Version: 1.1 Classification: Public Page 25 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
NIAP TD TD description Applicable? Non-applicability rationale
TD0677 Correction to Symbol in FCS_RBG_EXT.1
Test EA for MDF 3.3
Yes
2.2 PP-Module: collaborative PP-Module for Biometric enrolment and
verification - for unlocking the device [BIO]
This document claims conformance to the following Biometric Use Case:
● [Use Case 1] Biometric verification for unlocking the computer: This use case is applicable for
any computers such as a desktop, laptop, tablet or smartphone that implement biometric enrolment
and verification functionality.
Table 3 contains the NIAP Technical Decisions (TDs) for this cPP-Module at the time of the evaluation and a
statement of applicability to the evaluation.
Table 3: NIAP TDs for BIO
NIAP TD TD description Applicable? Non-applicability rationale
TD0714 Minor discrepancy in posted Biometrics cPP-
Module
Yes
TD0700 BIT Technical Decision for incorrect SFR
reference in SD
Yes
2.3 PP-Module for Bluetooth [BT]
This document claims conformance to the following Bluetooth Use Case:
● [Use Case 2] Mobile Device: This use case is for a Bluetooth TOE that is part of a mobile operating
system that runs on a mobile device. Specifically, the Bluetooth TOE is expected to be part of the
mobile operating system itself and not a standalone third-party application that is acquired from the
mobile vendor's application store.
Table 4 contains the NIAP Technical Decisions (TDs) for this PP-Module at the time of the evaluation and a
statement of applicability to the evaluation.
Table 4: NIAP TDs for BT
NIAP TD TD description Applicable? Non-applicability rationale
TD0707 Formatting corrections for MOD_BT_V1.0 Yes
TD0685 BT missing multiple SFR-to-Obj mappings Yes
TD0671 Bluetooth PP-Module updated to allow for
new PP and PP-Module Versions
Yes
TD0650 Conformance claim sections updated to
allow for MOD_VPNC_V2.3 and 2.4
Yes
TD0645 Bluetooth audit details Yes
TD0640 Handling BT devices that do not support
encryption
Yes
Version: 1.1 Classification: Public Page 26 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
NIAP TD TD description Applicable? Non-applicability rationale
TD0600 Conformance claim sections updated to
allow for MOD_VPNC_V2.3
No MOD_VPNC_V2.3 is not used by this
ST.
2.4 PP-Module for MDM Agents [Agent]
This document claims conformance to the following MDM Agents Use Cases:
● [Use Case 3] Personally owned device for personal and enterprise use: A personally owned
device, which is used, for both personal activities and enterprise data is commonly called Bring
Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after
significant personal usage has occurred.
● [Use Case 4] Personally owned device for personal and limited enterprise use: A personally
owned device may also be given access to limited enterprise services such as enterprise email.
Table 5 contains the NIAP Technical Decisions (TDs) for this PP-Module at the time of the evaluation and a
statement of applicability to the evaluation.
Table 5: NIAP TDs for Agent
NIAP TD TD description Applicable? Non-applicability rationale
TD0755 MDM-Agent Policy Authenticity Yes
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
TD0650 Conformance claim sections updated to
allow for MOD_VPNC_V2.3 and 2.4
Yes
TD0600 Conformance claim sections updated to
allow for MOD_VPNC_V2.3
No MOD_VPNC_V2.3 is not used by this
ST.
TD0497 SFR Rationale, Consistency of SPD, and
Implicitly Satisfied SFRs
Yes
2.5 PP-Module for Virtual Private Network (VPN) Clients [VPNC]
This document claims conformance to the following VPN Client Use Case:
● [Use Case 1] TOE to VPN Gateway: A VPN client allows users on the TOE platform to establish an
encrypted IPsec tunnel across a less trusted, often unprotected, public network to a private network.
Table 6 contains the NIAP Technical Decisions (TDs) for this PP-Module at the time of the evaluation and a
statement of applicability to the evaluation.
Table 6: NIAP TDs for VPNC
NIAP TD TD description Applicable? Non-applicability rationale
TD0753 MOD_VPNC FTP_DIT_EXT.1 Alignment for
App PP 1.4
No App PP V1.4 is not used by this ST.
Version: 1.1 Classification: Public Page 27 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
NIAP TD TD description Applicable? Non-applicability rationale
TD0725 Correction to FCS_CKM_EXT.2/4 selections No TD changes only apply when using
GPOS PP and App PP, not MDF PP.
TD0711 FMT_SMF.1 direction when using MDF 3.3 Yes
TD0697 Alignment with App PP V1.4 for required
NIST curves in FCS_CKM.1/AK
No App PP V1.4 is not used by this ST.
TD0690 Missing EAs for FDP_VPN_EXT.1 Yes
TD0672 VPN Client PP-Module updated to allow for
new PP and PP-Module Versions
Yes
TD0662 Changes to Testing IPsec NAT Transversal
and XAUTH in MOD_VPNC 2.4
Yes
TD0647 Table 2 Applicability Yes
2.6 PP-Module for WLAN Clients [WLANC]
Table 7 contains the NIAP Technical Decisions (TDs) for this PP-Module at the time of the evaluation and a
statement of applicability to the evaluation.
Table 7: NIAP TDs for WLANC
NIAP TD TD description Applicable? Non-applicability rationale
TD0710 WPA version restrictions Yes
TD0703 Removal of FIA_X509_EXT.2/WLAN
evaluation activities for revocation checking
Yes
TD0674 WLAN Client PP-Module updated to allow for
new PP and PP-Module Versions
Yes
TD0667 Move Set Wireless Freq Band to Optional/
Objective
Yes
2.7 Functional Package for Transport Layer Security (TLS) [TLSPKG]
Table 8 contains the NIAP Technical Decisions (TDs) for this functional package at the time of the evaluation
and a statement of applicability to the evaluation.
Table 8: NIAP TDs for TLSPKG
NIAP TD TD description Applicable? Non-applicability rationale
TD0770 TLSS.2 connection with no client cert No The TOE does not contain TLS server
functionality.
TD0739 PKG_TLS_V1.1 has 2 different publication
dates
Yes
TD0726 Corrections to (D)TLSS SFRs in TLS 1.1 FP No The TOE does not contain (D)TLS
server functionality.
Version: 1.1 Classification: Public Page 28 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
NIAP TD TD description Applicable? Non-applicability rationale
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
Version: 1.1 Classification: Public Page 29 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
3 Security Problem Definition
The threats, assumptions, and organizational security policies (OSPs) are defined in the documents specified in
Section 2 "CC Conformance Claim". They are reproduced here for the convenience of the reader.
The following shorthand expressions are used to refer to the PP and PP-related documents used in this Security
Target.
Agent MDM Agents PP-Module
BIO Biometric Enrolment and Verification cPP-Module
BT Bluetooth PP-Module
MDF Mobile Device Fundamentals PP
TLSPKG TLS Functional Package
VPNC VPN Client PP-Module
WLANC WLAN Client PP-Module
3.1 Threat Environment
3.1.1 Threats countered by the TOE
T.NETWORK_EAVESDROP
PP Origin: MDF, BT
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 Origin: MDF, BT
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 Origin: MDF
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 Origin: MDF
Applications loaded onto the Mobile Device may include malicious or exploitable code. This code
could be included intentionally 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
Version: 1.1 Classification: Public Page 30 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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, camera, microphone) 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 Origin: MDF
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 as well as by its legitimate owner.
T.BACKUP
PP Origin: Agent
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.Casual_Attack
PP Origin: BIO
An attacker may attempt to impersonate as a legitimate user without being enroled in the TOE. In
order to perform the attack, the attacker only use one's own biometric characteristic (in form of a
zero-effort impostor attempt).
T.UNAUTHORIZED_ACCESS
PP Origin: VPNC
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 or manipulated directly by a malicious user or process on
intermediate systems, leading to a compromise of the TOE or to the secured environmental systems
that the TOE is being used to facilitate communications with. IPsec can be used to provide protection
for this communication; however, there are numerous 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
Version: 1.1 Classification: Public Page 31 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
prevent such attacks. Further, if the protocol is implemented with little-used or non-standard options,
it may be compliant with the protocol specification but will not be able to interact with other diverse
equipment that is typically found in large enterprises.
Even though the communication path is protected, there is a possibility that the IPsec peer could be
tricked 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 tricked 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.
PP Origin: WLANC
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.TSF_CONFIGURATION
PP Origin: VPNC
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 or failure of an ignorant
or careless administrator 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
PP Origin: VPNC
Data traversing the TOE could inadvertently be sent to a different user as a consequence of a poorly-
designed TOE; 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
PP Origin: VPNC, WLANC
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.UNDETECTED_ACTIONS
PP Origin: WLANC
Version: 1.1 Classification: Public Page 32 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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.
3.2 Assumptions
A.CONFIG
PP Origin: MDF
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 Origin: MDF
It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost
or stolen.
A.PRECAUTION
PP Origin: MDF
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 Origin: MDF, Agent
Mobile Device users are not willfully negligent or hostile, and use the device within compliance of a
reasonable Enterprise security policy.
A.CONNECTIVITY
PP Origin: Agent
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
PP Origin: Agent
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
PP Origin: Agent
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.NO_TOE_BYPASS
PP Origin: VPNC
Information cannot flow onto the network to which the VPN client's host is connected without passing
through the TOE.
PP Origin: WLANC
Version: 1.1 Classification: Public Page 33 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Information cannot flow between the wireless client and the internal wired network without passing
through the TOE.
A.PHYSICAL
PP Origin: VPNC
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
PP Origin: VPNC
Personnel configuring the TOE and its OE will follow the applicable security configuration guidance.
A.TRUSTED_ADMIN
PP Origin: WLANC
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner.
3.3 Organizational Security Policies
P.ACCOUNTABILITY
PP Origin: Agent
Personnel operating the TOE shall be accountable for their actions within the TOE.
P.ADMIN
PP Origin: Agent
The configuration of the mobile device security functions must adhere to the Enterprise security
policy.
P.DEVICE_ENROLL
PP Origin: Agent
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
PP Origin: Agent
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.
OSP.Enrol
PP Origin: BIO
The TOE shall enrol a user for biometric verification, only after successful authentication of a user. The
TOE shall ensure that templates are of sufficient quality in order to meet the relevant error rates for
biometric verification.
OSP.Protection
PP Origin: BIO
The TOE in cooperation with its environment shall protect itself, its configuration and biometric data.
OSP.Verification_Error
PP Origin: BIO
Version: 1.1 Classification: Public Page 34 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TOE shall meet relevant criteria for its security relevant error rates for biometric verification.
Version: 1.1 Classification: Public Page 35 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
4 Security Objectives
The security objectives are defined in the documents specified in Section 2 "CC Conformance Claim". They are
reproduced here for the convenience of the reader.
4.1 Objectives for the TOE
O.PROTECTED_COMMS
PP Origin: MDF, BT
To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack
(T.NETWORK_ATTACK) threats described in [MDF]☝ 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 must be capable of
communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The
TOE may optionally communicate using these standard protocols: IPsec, mutually-authenticated
DTLS, or Bluetooth. These 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 Origin: MDF
To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device
(T.PHYSICAL_ACCESS), 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.
PP Origin: Agent
To address the issue of loss of confidentiality of user data in the event of loss of a mobile device
(T.PHYSICAL_ACCESS), conformant TOEs will use platform provide key storage. The TOE is expected
to protect its persistent secrets and private keys.
O.CONFIG
PP Origin: MDF
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 Origin: MDF
To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device
(T.PHYSICAL_ACCESS), 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
Version: 1.1 Classification: Public Page 36 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
calling, text notification) can be accessed prior to entering the authentication factor. The device will
automatically lock following a configured period of inactivity in an attempt to ensure authorization will
be required in the event of the device being lost or stolen.
Authentication of the endpoints of a trusted communication path is required for network access to
ensure attacks are unable to establish unauthorized network connections to undermine the integrity of
the device.
Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay
between unsuccessful attempts.
O.INTEGRITY
PP Origin: MDF
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
T.PERSISTENT_PRESENCE.
To address the issue of an application containing malicious or flawed code (T.MALICIOUS_APP), 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 Origin: MDF
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.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats.
O.ACCOUNTABILITY
PP Origin: Agent
The TOE must provide logging facilities, which record management actions undertaken by its
administrators.
O.APPLY_POLICY
PP Origin: Agent
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
PP Origin: Agent
Data exchanged between the MDM Server and the MDM Agent must be protected from being
monitored, accessed, or altered.
Version: 1.1 Classification: Public Page 37 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
O.BIO_Verification
PP Origin: BIO
The TOE shall provide a biometric verification mechanism to verify a user with an adequate reliability.
The TOE shall meet the relevant criteria for its security relevant error rates for biometric verification.
O.Enrol
PP Origin: BIO
The TOE shall implement the functionality to enrol a user for biometric verification and bind the
template to the user only after successful authentication of the user using NBAF. The TOE shall create
templates of sufficient quality in order to meet the relevant error rates for biometric verification.
O.Protection
PP Origin: BIO
The TOE shall protect biometric data using the SEE provided by the TOE environment during runtime
and storage.
O.AUTHENTICATION
PP Origin: VPNC
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.
O.CRYPTOGRAPHIC_FUNCTIONS
PP Origin: VPNC
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.
PP Origin: WLANC
The TOE will 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.KNOWN_STATE
PP Origin: VPNC
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
PP Origin: VPNC
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 and prohibit transmission of packets through a connection until certain
conditions are met.
Version: 1.1 Classification: Public Page 38 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
O.AUTH_COMM
PP Origin: WLANC
The TOE will provide a means to ensure that it is communicating with an authorized access point and
not some other entity pretending to be an authorized access point, and will provide assurance to the
access point of its identity.
O.SELF_TEST
PP Origin: WLANC
The TOE will provide the capability to test some subset of its security functionality to ensure it is
operating properly.
O.SYSTEM_MONITORING
PP Origin: WLANC
The TOE will provide the capability to generate audit data.
O.TOE_ADMINISTRATION
PP Origin: WLANC
The TOE will provide mechanisms to allow administrators to be able to configure the TOE.
O.WIRELESS_ACCESS_POINT_CONNECTION
PP Origin: WLANC
The TOE will provide the capability to restrict the wireless access points to which it will connect.
4.2 Objectives for the Operational Environment
OE.CONFIG
PP Origin: MDF
TOE administrators will configure the Mobile Device security functions correctly to create the intended
security policy.
OE.NOTIFY
PP Origin: MDF
The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen.
OE.PRECAUTION
PP Origin: MDF
The mobile device user exercises precautions to reduce the risk of loss or theft of the Mobile Device.
OE.DATA_PROPER_USER
PP Origin: MDF
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.
PP Origin: Agent
Users of the mobile device are trained to securely use the mobile device and apply all guidance in a
trusted manner.
OE.DATA_PROPER_ADMIN
PP Origin: Agent
Version: 1.1 Classification: Public Page 39 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner.
OE.IT_ENTERPRISE
PP Origin: Agent
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
PP Origin: Agent
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
PP Origin: Agent
A wireless network will be available to the mobile devices.
OE.Protection
PP Origin: BIO
The TOE environment shall provide the SEE to protect the TOE, the TOE configuration and biometric
data during runtime and storage.
OE.NO_TOE_BYPASS
PP Origin: VPNC
Information cannot flow onto the network to which the VPN client's host is connected without passing
through the TOE.
PP Origin: WLANC
Information cannot flow between external and internal networks located in different enclaves without
passing through the TOE.
OE.PHYSICAL
PP Origin: VPNC
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
PP Origin: VPNC
Personnel configuring the TOE and its OE will follow the applicable security configuration guidance.
OE.TRUSTED_ADMIN
PP Origin: WLANC
TOE administrators are trusted to follow and apply all administrator guidance in a trusted manner.
4.3 Security Objectives Rationale
The security objectives rationale is defined in the documents specified in Section 2 "CC Conformance Claim".
Version: 1.1 Classification: Public Page 40 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
5 Extended Components Definition
The extended components definitions are defined in the documents specified in Section 2 "CC Conformance
Claim".
Version: 1.1 Classification: Public Page 41 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6 Security Requirements
6.1 TOE Security Functional Requirements
The table below summarizes the SFRs for the TOE and the operations performed on the components according
to CC part 1. Operations in the SFRs use the following convention:
● Iterations (Iter.) are identified by appending a suffix to the original SFR.
● Refinements (Ref.) added to the text are shown in italic text, deletions are shown as strikethrough
text.
● Assignments (Ass.) are shown in bold text.
● Selections (Sel.) are shown in bold text.
Table 9: SFRs for the TOE
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FAU_ALT_EXT.2 Agent Alerts Agent No No No Yes
FAU_GEN.1 Audit Data Generation MDF Yes Yes Yes Yes
FAU_GEN.1(2) Audit Data Generation FAU_GEN.1 Agent Yes Yes Yes Yes
FAU_GEN.1/BT Audit Data Generation
(Bluetooth)
FAU_GEN.1 BT Yes Yes No Yes
FAU_GEN.1/VPN Audit Data Generation FAU_GEN.1 VPNC Yes Yes No Yes
FAU_GEN.1/WLAN Audit Data
Generation (Wireless LAN)
FAU_GEN.1 WLANC Yes Yes No Yes
FAU_SAR.1 Audit Review MDF No No No No
FAU_SEL.1(2) Security Audit Event
Selection
FAU_SEL.1 Agent No No Yes Yes
FAU_STG.1 Audit Storage Protection MDF No No No No
FAU - Security
audit
FAU_STG.4 Prevention of Audit Data
Loss
MDF No No No No
FCS_CKM.1 Cryptographic Key
Generation
MDF Yes No No Yes
FCS_CKM.1/VPN VPN Cryptographic
Key Generation (IKE)
FCS_CKM.1 VPNC Yes No No Yes
FCS_CKM.1/WPA Cryptographic
Key Generation (Symmetric Keys for
WPA2/WPA3 Connections)
FCS_CKM.1 WLANC Yes No No Yes
FCS_CKM.2/UNLOCKED
Cryptographic Key Establishment
FCS_CKM.2 MDF Yes No No Yes
FCS -
Cryptographic
support
FCS_CKM.2/LOCKED Cryptographic
Key Establishment
FCS_CKM.2 MDF Yes No No Yes
Version: 1.1 Classification: Public Page 42 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FCS_CKM.2/WLAN Cryptographic Key
Distribution (Group Temporal Key for
WLAN)
FCS_CKM.2 WLANC Yes Yes No No
FCS_CKM_EXT.1 Cryptographic Key
Support
MDF No No No Yes
FCS_CKM_EXT.2 Cryptographic Key
Random Generation
MDF No No No Yes
FCS_CKM_EXT.3 Cryptographic Key
Generation
MDF No No No Yes
FCS_CKM_EXT.4 Key Destruction MDF No No No Yes
FCS_CKM_EXT.5 TSF Wipe MDF No No No Yes
FCS_CKM_EXT.6 Salt Generation MDF No No No No
FCS_CKM_EXT.7 Cryptographic Key
Support (REK)
MDF No No No No
FCS_CKM_EXT.8 Bluetooth Key
Generation
BT No No Yes No
FCS_COP.1/ENCRYPT Cryptographic
Operation
FCS_COP.1 MDF Yes No No Yes
FCS_COP.1/HASH Cryptographic
Operation
FCS_COP.1 MDF Yes No No Yes
FCS_COP.1/SIGN Cryptographic
Operation
FCS_COP.1 MDF Yes No No Yes
FCS_COP.1/KEYHMAC Cryptographic
Operation
FCS_COP.1 MDF Yes No Yes Yes
FCS_COP.1/CONDITION Cryptographic
Operation
FCS_COP.1 MDF Yes No Yes Yes
FCS_HTTPS_EXT.1 HTTPS Protocol MDF No No No Yes
FCS_IPSEC_EXT.1 IPsec VPNC No No Yes Yes
FCS_IV_EXT.1 Initialization Vector
Generation
MDF No Yes No No
FCS_RBG_EXT.1/HW Random Bit
Generation (Hardware)
FCS_RBG_EXT
.1
MDF Yes Yes No Yes
FCS_RBG_EXT.1/SW Random Bit
Generation (Software)
FCS_RBG_EXT
.1
MDF Yes No No Yes
FCS_SRV_EXT.1 Cryptographic
Algorithm Services
MDF No No No Yes
FCS_STG_EXT.1 Cryptographic Key
Storage
MDF No No No Yes
Version: 1.1 Classification: Public Page 43 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FCS_STG_EXT.2 Encrypted
Cryptographic Key Storage
MDF No No Yes Yes
FCS_STG_EXT.3 Integrity of Encrypted
Key Storage
MDF No No No Yes
FCS_STG_EXT.4 Cryptographic Key
Storage
Agent No No No No
FCS_TLS_EXT.1 TLS Protocol TLSPKG No No No Yes
FCS_TLSC_EXT.1 TLS Client Protocol TLSPKG Yes No No Yes
FCS_TLSC_EXT.1/WLAN TLS Client
Protocol (EAP-TLS for WLAN)
FCS_TLSC_EX
T.1
WLANC Yes No No Yes
FCS_TLSC_EXT.2 TLS Client Support
for Mutual Authentication
TLSPKG No No No No
FCS_TLSC_EXT.4 TLS Client Support
for Renegotiation
TLSPKG No No No No
FCS_TLSC_EXT.5 TLS Client Support
for Supported Groups Extension
TLSPKG No No No Yes
FCS_WPA_EXT.1 Supported WPA
Versions
WLANC No No No Yes
FDP_ACF_EXT.1 Access Control for
System Services
MDF No No No Yes
FDP_ACF_EXT.2 Access Control for
System Resources
MDF No No No Yes
FDP_DAR_EXT.1 Protected Data
Encryption
MDF No No No Yes
FDP_DAR_EXT.2 Sensitive Data
Encryption
MDF No No No No
FDP_IFC_EXT.1 Subset Information
Flow Control
MDF No No Yes Yes
FDP_RIP.2 Full Residual Information
Protection
VPNC No No No Yes
FDP_STG_EXT.1 User Data Storage MDF No No No No
FDP_UPC_EXT.1/APPS Inter-TSF User
Data Transfer Protection (Applications)
FDP_UPC_EXT
.1
MDF Yes No No Yes
FDP_UPC_EXT.1/BLUETOOTH Inter-
TSF User Data Transfer Protection
(Bluetooth)
FDP_UPC_EXT
.1
MDF Yes No No Yes
FDP - User data
protection
FDP_VPN_EXT.1 Split Tunnel
Prevention
VPNC No No No No
Version: 1.1 Classification: Public Page 44 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FIA_AFL_EXT.1 Authentication Failure
Handling
MDF No No Yes Yes
FIA_BLT_EXT.1 Bluetooth User
Authorization
BT No No No No
FIA_BLT_EXT.2 Bluetooth Mutual
Authentication
BT No No No No
FIA_BLT_EXT.3 Rejection of Duplicate
Bluetooth Connections
BT No No No No
FIA_BLT_EXT.4 Secure Simple Pairing BT No No No No
FIA_BLT_EXT.6 Trusted Bluetooth
Device User Authorization
BT No No Yes No
FIA_BLT_EXT.7 Untrusted Bluetooth
Device User Authorization
BT No No Yes No
FIA_ENR_EXT.2 Agent Enrollment of
Mobile Device into Management
Agent No No No No
FIA_MBE_EXT.1 Biometric enrolment BIO No No No No
FIA_MBE_EXT.2 Quality of biometric
templates for biometric enrolment
BIO No No Yes Yes
FIA_MBV_EXT.1 Biometric verification BIO No No Yes Yes
FIA_MBV_EXT.2 Quality of biometric
samples for biometric verification
BIO No No Yes Yes
FIA_PAE_EXT.1 Port Access Entity
Authentication
WLANC No No No No
FIA_PMG_EXT.1 Password
Management
MDF No No Yes Yes
FIA_TRT_EXT.1 Authentication
Throttling
MDF No No No Yes
FIA_UAU.5 Multiple Authentication
Mechanisms
MDF No No Yes Yes
FIA_UAU.6/CREDENTIAL Re-
Authenticating (Credential Change)
FIA_UAU.6 MDF Yes No No No
FIA_UAU.6/LOCKED Re-Authenticating
(TSF Lock)
FIA_UAU.6 MDF Yes No Yes No
FIA_UAU.7 Protected Authentication
Feedback
MDF No No No No
FIA_UAU_EXT.1 Authentication for
Cryptographic Operation
MDF No No No Yes
FIA - Identification
and authentication
FIA_UAU_EXT.2 Timing of
Authentication
MDF No No Yes Yes
Version: 1.1 Classification: Public Page 45 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FIA_X509_EXT.1 X.509 Validation of
Certificates
MDF Yes No No Yes
FIA_X509_EXT.1/WLAN X.509
Certificate Validation
FIA_X509_EXT
.1
WLANC Yes No No No
FIA_X509_EXT.2 X.509 Certificate
Authentication
MDF Yes No No Yes
FIA_X509_EXT.2/WLAN X.509
Certificate Authentication (EAP-TLS
for WLAN)
FIA_X509_EXT
.2
WLANC Yes No No No
FIA_X509_EXT.3 Request Validation of
Certificates
MDF No No No No
FIA_X509_EXT.6 Certificate Storage
and Management
WLANC No No No Yes
FMT_MOF_EXT.1 Management of
Security Functions Behavior
MDF No Yes No No
FMT_POL_EXT.2 Agent Trusted Policy
Update
Agent No No No No
FMT_SMF.1 Specification of
Management Functions
MDF Yes Yes Yes Yes
FMT_SMF.1/VPN Specification of
Management Functions (VPN)
FMT_SMF.1 VPNC Yes No No Yes
FMT_SMF.1/WLAN Specification of
Management Functions (WLAN Client)
FMT_SMF.1 WLANC Yes Yes No Yes
FMT_SMF_EXT.1/BT Specification of
Management Functions
FMT_SMF_EXT
.1
BT No Yes Yes Yes
FMT_SMF_EXT.2 Specification of
Remediation Actions
MDF No No No Yes
FMT_SMF_EXT.4 Specification of
Management Functions
Agent No No No Yes
FMT - Security
management
FMT_UNR_EXT.1 User Unenrollment
Prevention
Agent No No No Yes
FPT_AEX_EXT.1 Application Address
Space Layout Randomization
MDF No No No No
FPT_AEX_EXT.2 Memory Page
Permissions
MDF No No No No
FPT_AEX_EXT.3 Stack Overflow
Protection
MDF No No No No
FPT - Protection of
the TSF
FPT_AEX_EXT.4 Domain Isolation MDF No No No No
Version: 1.1 Classification: Public Page 46 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FPT_BDP_EXT.1 Biometric data
processing
BIO No No No No
FPT_JTA_EXT.1 JTAG Disablement MDF No No No Yes
FPT_KST_EXT.1 Key Storage MDF No Yes No No
FPT_KST_EXT.2 No Key Transmission MDF No Yes No No
FPT_KST_EXT.3 No Plaintext Key
Export
MDF No No No No
FPT_NOT_EXT.1 Self-Test Notification MDF No No No Yes
FPT_PBT_EXT.1 Protection of biometric
template
BIO No No No Yes
FPT_STM.1 Reliable Time Stamps MDF No No No No
FPT_TST_EXT.1 TSF Cryptographic
Functionality Testing
MDF Yes No No No
FPT_TST_EXT.1/VPN TSF Self-Test FPT_TST_EXT.1 VPNC Yes No Yes Yes
FPT_TST_EXT.2/PREKERNEL TSF
Integrity Checking (Pre-Kernel)
FPT_TST_EXT.
2
MDF Yes No No Yes
FPT_TST_EXT.2/POSTKERNEL TSF
Integrity Checking (Post-Kernel)
FPT_TST_EXT.
2
MDF Yes No Yes Yes
FPT_TST_EXT.3 TSF Integrity Testing MDF Yes No No No
FPT_TST_EXT.3/WLAN TSF
Cryptographic Functionality Testing
(WLAN Client)
FPT_TST_EXT.
3
WLANC Yes No No Yes
FPT_TUD_EXT.1 TSF Version Query MDF No No No No
FPT_TUD_EXT.2 TSF Update
Verification
MDF No No No Yes
FPT_TUD_EXT.3 Application Signing MDF No No No No
FPT_TUD_EXT.4 Trusted Update
Verification
MDF No No No No
FPT_TUD_EXT.5 Application
Verification
MDF No No No Yes
FPT_TUD_EXT.6 Trusted Update
Verification
MDF No No No No
FTA_SSL_EXT.1 TSF- and User-
initiated Locked State
MDF No No Yes No
FTA - TOE access
FTA_TAB.1 Default TOE Access
Banners
MDF No No No No
Version: 1.1 Classification: Public Page 47 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Operations
Security
functional class
Security functional requirement Base security
functional
component
Source
Iter. Ref. Ass. Sel.
FTA_WSE_EXT.1 Wireless Network
Access
WLANC No No No No
FTP_BLT_EXT.1 Bluetooth Encryption BT No No No Yes
FTP_BLT_EXT.2 Persistence of
Bluetooth Encryption
BT No No No Yes
FTP_BLT_EXT.3/BR Bluetooth
Encryption Parameters (BR/EDR)
FTP_BLT_EXT.
3
BT Yes No Yes No
FTP_BLT_EXT.3/LE Bluetooth
Encryption Parameters (LE)
FTP_BLT_EXT.
3
BT Yes No Yes No
FTP_ITC.1/WLAN Trusted Channel
Communication (Wireless LAN)
FTP_ITC.1 WLANC No No No No
FTP_ITC_EXT.1 Trusted Channel
Communication
MDF Yes No No Yes
FTP_ITC_EXT.1(2) Trusted Channel
Communication
FTP_ITC_EXT.1 Agent Yes No No Yes
FTP - Trusted
path/channels
FTP_TRP.1(2) Trusted Path (for
Enrollment)
Agent No No No Yes
6.1.1 Security audit (FAU)
6.1.1.1 FAU_ALT_EXT.2 Agent Alerts
PP Origin: Agent
FAU_ALT_EXT.2.1
The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the event of any of
the following audit events:
● successful application of policies to a mobile device,
● receiving periodic reachability events,
● no other events.
FAU_ALT_EXT.2.2
The MDM Agent shall queue alerts if the trusted channel is not available.
6.1.1.2 FAU_GEN.1 Audit Data Generation
PP Origin: MDF
Applied TDs: TD0724
FAU_GEN.1.1
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
Version: 1.1 Classification: Public Page 48 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 Table 10
7. no additional auditable events
Table 10: Mandatory Auditable Events (MDF)
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 No events specified N/A
FAU_SAR.1 No events specified N/A
FAU_STG.1 No events specified N/A
FAU_STG.4 No events specified N/A
FCS_CKM.1 None No additional information
FCS_CKM.2/UNLOCKED No events specified N/A
FCS_CKM.2/LOCKED No events specified N/A
FCS_CKM_EXT.1 None No additional information
FCS_CKM_EXT.2 No events specified N/A
FCS_CKM_EXT.3 No events specified N/A
FCS_CKM_EXT.4 No events specified N/A
FCS_CKM_EXT.5 None No additional information
FCS_CKM_EXT.6 No events specified N/A
FCS_COP.1/ENCRYPT No events specified N/A
FCS_COP.1/HASH No events specified N/A
FCS_COP.1/SIGN No events specified N/A
FCS_COP.1/KEYHMAC No events specified N/A
FCS_COP.1/CONDITION No events specified N/A
FCS_IV_EXT.1 No events specified N/A
FCS_SRV_EXT.1 No events specified N/A
Import or destruction of key Identity of key, role and identity of
requester
FCS_STG_EXT.1
None Identity of key, role and identity of
requester
FCS_STG_EXT.2 No events specified N/A
FCS_STG_EXT.3 Failure to verify integrity of stored
key
Identity of key being verified
FDP_ACF_EXT.1 No events specified N/A
Version: 1.1 Classification: Public Page 49 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Requirement Auditable Events Additional Audit Record
Contents
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 No events specified N/A
FDP_STG_EXT.1 Addition or removal of certificate
from Trust Anchor Database
Subject name of certificate
FIA_PMG_EXT.1 No events specified N/A
FIA_TRT_EXT.1 No events specified N/A
FIA_UAU.5 No events specified N/A
FIA_UAU.7 No events specified N/A
FIA_UAU_EXT.1 No events specified N/A
FIA_X509_EXT.1 Failure to validate X.509v3
certificate
Reason for failure of validation
FIA_X509_EXT.2 No events specified N/A
FMT_MOF_EXT.1 No events specified N/A
FPT_AEX_EXT.1 No events specified N/A
FPT_AEX_EXT.2 No events specified N/A
FPT_AEX_EXT.3 No events specified N/A
FPT_JTA_EXT.1 No events specified N/A
FPT_KST_EXT.1 No events specified N/A
FPT_KST_EXT.2 No events specified N/A
FPT_KST_EXT.3 No events specified N/A
FPT_NOT_EXT.1 None No additional information
FPT_STM.1 No events specified N/A
Initiation of self-test No additional information
FPT_TST_EXT.1
Failure of self-test No additional information
Start-up of TOE No additional information
FPT_TST_EXT.2/PREKERNEL
None No additional information
FPT_TUD_EXT.1 No events specified N/A
FTA_SSL_EXT.1 No events specified N/A
FTA_TAB.1 No events specified N/A
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
Version: 1.1 Classification: Public Page 50 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 Table 10
6. no additional information
6.1.1.3 FAU_GEN.1(2) Audit Data Generation
PP Origin: Agent
Applied TDs: TD0660
FAU_GEN.1.1(2)
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 1 Table 11, and no other events.
Table 11: Auditable Events (Agent)
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,
FCS_STG_EXT.1(2)
None.
Failure to establish a TLS session. Reason for failure.
Failure to verify presented
identifier.
Presented identifier and reference
identifier.
FCS_TLSC_EXT.1
Establishment/termination of a
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.
Version: 1.1 Classification: Public Page 51 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Requirement Auditable Events Additional Audit Record
Contents
FTP_ITC_EXT.1(2) Initiation and termination of
trusted channel.
Trusted channel protocol. Non-
TOE endpoint of connection.
FAU_GEN.1.2(2)
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 1 Table 11; 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.
6.1.1.4 FAU_GEN.1/BT Audit Data Generation (Bluetooth)
PP Origin: BT
Applied TDs: TD0645 TD0707
FAU_GEN.1.1/BT
The TSF shall be able to generate an audit record of the following auditable events:
a. Start-up and shutdown of the audit functions
b. All auditable events for the not specified level of audit
c. Specifically defined auditable events in the Auditable Events table (Table 12).
Table 12: Auditable Events (BT)
Requirement Auditable Events Additional Audit Record
Contents
FCS_CKM_EXT.8 None.
Failed user authorization of
Bluetooth device.
User authorization decision
(e.g., user rejected connection,
incorrect pin entry).
FIA_BLT_EXT.1
Failed user authorization for local
Bluetooth Service.
Complete BD_ADDR and name
of device. Bluetooth profile.
Identity of local service with
service ID.
Initiation of Bluetooth connection. Complete BD_ADDR and name
of device.
FIA_BLT_EXT.2
Failure of Bluetooth connection. Reason for failure.
FIA_BLT_EXT.3 (optional) Duplicate connection attempt. [selection: complete, last
[assignment: integer greater
than or equal to 2] octets of the]
BD_ADDR of connection attempt.
FIA_BLT_EXT.4 None.
FIA_BLT_EXT.5 (if claimed) None.
Version: 1.1 Classification: Public Page 52 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Requirement Auditable Events Additional Audit Record
Contents
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 (if
claimed)
None.
Application Note: FIA_BLT_EXT.3 is excluded from Table 12 because the rejection is
performed at the HCI layer. FIA_BLT_EXT.5 is not claimed.
FAU_GEN.1.2/BT
The TSF shall record within each audit record at least the following information:
a. Date and time of the event
b. Type of event
c. Subject identity
d. The outcome (success or failure) of the event
e. For each audit event type, based on the auditable event definitions of the functional components
included in the PP/ST, Additional information in the Auditable Events table (Table 12).
6.1.1.5 FAU_GEN.1/VPN Audit Data Generation
FAU_GEN.1.1/VPN
Applied TDs: TD0647
The TSF and TOE platform shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit;
c) All administrative actions;
d) Specifically defined auditable events listed in the Auditable Events tables (Table 13).
Table 13: Auditable Events (VPN)
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1/VPN No events specified. N/A
FCS_CKM.1/VPN No events specified. N/A
FCS_IPSEC_EXT.1 Decisions to DISCARD or BYPASS
network packets processed by
the TOE.
Presumed identity of source
subject. The entry in the SPD that
applied to the decision.
Version: 1.1 Classification: Public Page 53 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Requirement Auditable Events Additional Audit Record
Contents
FCS_IPSEC_EXT.1 Failure to establish an IPsec SA. Identity of destination subject.
Reason for failure.
FCS_IPSEC_EXT.1 Establishment/Termination of an
IPsec SA.
Identity of destination subject.
Transport layer protocol, if
applicable. Source subject service
identifier, if applicable. Non-
TOE endpoint of connection (IP
address) for both successes and
failures.
FDP_RIP.2 No events specified. N/A
FDP_VPN_EXT.1 No events specified. N/A
FMT_SMF.1/VPN Success or failure of management
function.
No additional information.
FPT_TST_EXT.1/VPN No events specified. N/A
FAU_GEN.1.2/VPN
The TSF and TOE platform shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of
the event; and
b) For each audit event type, based on the auditable event definitions of the functional components
included in the PP-Module/ST, information specified in column three of Auditable Events table.
6.1.1.6 FAU_GEN.1/WLAN Audit Data Generation (Wireless LAN)
PP Origin: WLANC
FAU_GEN.1.1/WLAN
The TSF shall implement functionality to generate an audit record of the following auditable events:
a. Startup and shutdown of the audit functions;
b. All auditable events for not specified level of audit; and
c. All auditable events for mandatory SFRs specified in Table 2 and selected SFRs in Table 5 Table 14.
Table 14: Auditable Events (WLAN)
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1/WLAN No events specified. N/A
FCS_CKM.1/WPA No events specified. N/A
FCS_CKM.2/WLAN No events specified. N/A
FCS_TLSC_EXT.1/WLAN Failure to establish an EAP-TLS
session.
Reason for failure. Non-TOE
endpoint of connection.
Version: 1.1 Classification: Public Page 54 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Requirement Auditable Events Additional Audit Record
Contents
Establishment/termination of an
EAP-TLS session.
Non-TOE endpoint of connection.
FCS_WPA_EXT.1 No events specified. N/A
FIA_PAE_EXT.1 No events specified. N/A
FIA_X509_EXT.1/WLAN Failure to validate X.509v3
certificate.
Reason for failure of validation.
FIA_X509_EXT.2/WLAN No events specified. N/A
Attempts to load certificates. None.
FIA_X509_EXT.6
Attempts to revoke certificates. None.
FMT_SMF.1/WLAN No events specified. N/A
Execution of this set of TSF self-
tests.
None.
FPT_TST_EXT.3/WLAN
None. None.
FTA_WSE_EXT.1 All attempts to connect to access
points.
For each access point record
the Complete SSID and MAC
of the MAC Address. Success
and failures (including reason for
failure).
FTP_ITC.1/WLAN All attempts to establish a trusted
channel.
Identification of the non-TOE
endpoint of the channel.
FAU_GEN.1.2/WLAN
The TSF shall record within each 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
b. For each audit event type, based on the auditable event definitions of the functional components
included in the PP-Module/ST, Additional Audit Record Contents as specified in Table 2 and Table 5
Table 14.
6.1.1.7 FAU_SAR.1 Audit Review
PP Origin: MDF
FAU_SAR.1.1
The TSF shall provide the administrator with the capability to read all audited events and record contents
from the audit records.
FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
6.1.1.8 FAU_SEL.1(2) Security Audit Event Selection
PP Origin: Agent
Version: 1.1 Classification: Public Page 55 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FAU_SEL.1.1(2)
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
b) success of auditable security events, failure of auditable security events, no other attributes.
6.1.1.9 FAU_STG.1 Audit Storage Protection
PP Origin: MDF
FAU_STG.1.1
The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
FAU_STG.1.2
The TSF shall be able to prevent unauthorized modifications to the stored audit records in the audit trail.
6.1.1.10 FAU_STG.4 Prevention of Audit Data Loss
PP Origin: MDF
FAU_STG.4.1
The TSF shall overwrite the oldest stored audit records if the audit trail is full.
6.1.2 Cryptographic support (FCS)
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation
PP Origin: MDF, VPNC
FCS_CKM.1.1
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key
generation algorithm
● ECC schemes using
❍ "NIST curves" P-384 and P-256 that meet the following: FIPS PUB 186-4, "Digital
Signature Standard (DSS)", Appendix B.4
❍ Curve25519 schemes that meet the following: RFC 7748
● FFC schemes using
❍ Diffie-Hellman group 14 that meet the following: RFC3526
❍ "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"'
6.1.2.2 FCS_CKM.1/VPN VPN Cryptographic Key Generation (IKE)
PP Origin: VPNC
Version: 1.1 Classification: Public Page 56 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FCS_CKM.1.1/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.
6.1.2.3 FCS_CKM.1/WPA Cryptographic Key Generation (Symmetric Keys for WPA2/
WPA3 Connections)
PP Origin: WLANC
FCS_CKM.1.1/WPA
The TSF shall generate symmetric cryptographic keys in accordance with a specified cryptographic key
generation algorithm PRF-384 and PRF-704 (as defined in IEEE 802.11-2012) and specified key sizes
256 bits and 128 bits using a Random Bit Generator as specified in FCS_RBG_EXT.1.
6.1.2.4 FCS_CKM.2/UNLOCKED Cryptographic Key Establishment
PP Origin: MDF, VPNC
FCS_CKM.2.1/UNLOCKED
The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key
establishment method
● RSA-based key establishment schemes that meet the following
❍ NIST Special Publication 800-56B, "Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography"
● Elliptic curve-based key establishment schemes that meet 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 meet the following: NIST Special
Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography"
● Key establishment schemes using Diffie-Hellman group 14 that meets the following: RFC
3526, Section 3
6.1.2.5 FCS_CKM.2/LOCKED Cryptographic Key Establishment
PP Origin: MDF
FCS_CKM.2.1/LOCKED
The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key
establishment method:
● Elliptic curve-based key establishment schemes that meet the following:
❍ RFC 7748, "Elliptic Curves for Security"
Version: 1.1 Classification: Public Page 57 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
for the purposes of encrypting sensitive data received while the device is locked.
6.1.2.6 FCS_CKM.2/WLAN Cryptographic Key Distribution (Group Temporal Key for
WLAN)
PP Origin: WLANC
FCS_CKM.2.1/WLAN
The TSF shall decrypt Group Temporal Key in accordance with a specified cryptographic key
distribution method AES Key Wrap (as defined in RFC 3394) in an EAPOL-Key frame (as defined in IEEE
802.11-2012) for the packet format and timing considerations and does not expose the cryptographic
keys.
6.1.2.7 FCS_CKM_EXT.1 Cryptographic Key Support
PP Origin: MDF
FCS_CKM_EXT.1.1
The TSF shall support mutable hardware REKs with a symmetric key of strength 256 bits.
FCS_CKM_EXT.1.2
Each REK shall be hardware-isolated from the OS on the TSF in runtime.
FCS_CKM_EXT.1.3
Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1.
6.1.2.8 FCS_CKM_EXT.2 Cryptographic Key Random Generation
PP Origin: MDF
FCS_CKM_EXT.2.1
All DEKs shall be randomly generated with entropy corresponding to the security strength of AES key
sizes of 256 bits.
6.1.2.9 FCS_CKM_EXT.3 Cryptographic Key Generation
PP Origin: MDF
FCS_CKM_EXT.3.1
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
The TSF shall generate all KEKs using one of the following methods:
● Derive the KEK from a Password Authentication Factor 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)
Version: 1.1 Classification: Public Page 58 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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.
6.1.2.10 FCS_CKM_EXT.4 Key Destruction
PP Origin: MDF
FCS_CKM_EXT.4.1
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
❍ For volatile memory, the destruction shall be executed by a single direct overwrite consisting
of zeros.
❍ 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.
❍ 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.
❍ For non-volatile flash memory, that is wear-leveled, the destruction shall be executed by a
block erase.
❍ For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a
single direct overwrite with a random pattern that is changed before each write.
FCS_CKM_EXT.4.2
The TSF shall destroy all plaintext keying material and critical security parameters when no longer
needed.
6.1.2.11 FCS_CKM_EXT.5 TSF Wipe
PP Origin: MDF
FCS_CKM_EXT.5.1
The TSF shall wipe all protected data by
● Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by
following the requirements in FCS_CKM_EXT.4.1.
FCS_CKM_EXT.5.2
The TSF shall perform a power cycle on conclusion of the wipe procedure.
6.1.2.12 FCS_CKM_EXT.6 Salt Generation
PP Origin: MDF
Version: 1.1 Classification: Public Page 59 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FCS_CKM_EXT.6.1
The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1.
Application Note: The salt is generated using FCS_RBG_EXT.1/HW.
6.1.2.13 FCS_CKM_EXT.7 Cryptographic Key Support (REK)
PP Origin: MDF
FCS_CKM_EXT.7.1
A REK shall not be able to be read from or exported from the hardware.
6.1.2.14 FCS_CKM_EXT.8 Bluetooth Key Generation
PP Origin: BT
FCS_CKM_EXT.8.1
The TSF shall generate public/private ECDH key pairs every new connection attempt.
6.1.2.15 FCS_COP.1/ENCRYPT Cryptographic Operation
PP Origin: MDF, VPNC
FCS_COP.1.1/ENCRYPT
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 .
6.1.2.16 FCS_COP.1/HASH Cryptographic Operation
PP Origin: MDF
FCS_COP.1.1/HASH
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.
6.1.2.17 FCS_COP.1/SIGN Cryptographic Operation
PP Origin: MDF
Version: 1.1 Classification: Public Page 60 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FCS_COP.1.1/SIGN
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
6.1.2.18 FCS_COP.1/KEYHMAC Cryptographic Operation
PP Origin: MDF
FCS_COP.1.1/KEYHMAC
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".
6.1.2.19 FCS_COP.1/CONDITION Cryptographic Operation
PP Origin: MDF
FCS_COP.1.1/CONDITION
The TSF shall perform conditioning in accordance with a specified cryptographic algorithm
HMAC-SHA-256 using a salt, and PBKDF2 with one iterations, repetitive AES-CBC-256
encryption with a duration between 100 and 150 milliseconds (50,000 repetition minimum) and
output cryptographic key sizes 256 that meet the following: NIST SP 800-132.
Application Note: The number of repetitions is calibrated to take at least 100 to 150 milliseconds with a
minimum of 50,000 repetitions. The number of repetitions may be greater in some devices.
6.1.2.20 FCS_HTTPS_EXT.1 HTTPS Protocol
PP Origin: MDF
FCS_HTTPS_EXT.1.1
The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2
The TSF shall implement HTTPS using TLS as defined in the Functional Package for Transport Layer
Security (TLS), version 1.1.
FCS_HTTPS_EXT.1.3
The TSF shall notify the application and request application authorization to establish the
connection if the peer certificate is deemed invalid.
Version: 1.1 Classification: Public Page 61 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.2.21 FCS_IPSEC_EXT.1 IPsec
PP Origin: VPNC
FCS_IPSEC_EXT.1.1
The TSF shall implement the IPsec architecture as specified in RFC 4301.
FCS_IPSEC_EXT.1.2
The TSF shall implement tunnel mode.
FCS_IPSEC_EXT.1.3
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
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.
FCS_IPSEC_EXT.1.5
The TSF shall implement the protocol:
● IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in
section 2.23), RFC 8784, RFC 8247, and no other RFCs for hash functions.
FCS_IPSEC_EXT.1.6
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 as specified in RFC 5282,
AES-GCM-256 as specified in RFC 5282.
FCS_IPSEC_EXT.1.7
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
The TSF shall ensure that all IKE protocols implement DH Groups
● 19 (256-bit Random ECP), 20 (384-bit Random ECP) according to RFC 5114 and
● 14 (2048-bit MODP), 15 (3072-bit MODP) according to RFC 3526.
FCS_IPSEC_EXT.1.9
The TSF shall generate the secret value x used in the IKE DH key exchange ("x" in g^x 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
Version: 1.1 Classification: Public Page 62 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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.
FCS_IPSEC_EXT.1.11
The TSF shall ensure that all IKE protocols perform peer authentication using RSA, ECDSA that use
X.509v3 certificates that conform to RFC 4945 and no other method.
FCS_IPSEC_EXT.1.12
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 values for the entity attempting to
establish a connection.
FCS_IPSEC_EXT.1.13
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
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.
6.1.2.22 FCS_IV_EXT.1 Initialization Vector Generation
PP Origin: MDF
FCS_IV_EXT.1.1
The TSF shall generate IVs in accordance with MDF Table 11: References and IV Requirements for NIST-
approved Cipher Modes.
6.1.2.23 FCS_RBG_EXT.1/HW Random Bit Generation (Hardware)
PP Origin: MDF
FCS_RBG_EXT.1.1/HW
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/HW
The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a 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/HW
The TSF shall be capable of providing output of the RBG to applications running on the TSF that request
random bits.
Version: 1.1 Classification: Public Page 63 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Application Note: FCS_RBG_EXT.1/HW is for the Secure Enclave RBG.
6.1.2.24 FCS_RBG_EXT.1/SW Random Bit Generation (Software)
PP Origin: MDF
FCS_RBG_EXT.1.1/SW
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/SW
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/SW
The TSF shall be capable of providing output of the RBG to applications running on the TSF that request
random bits.
Application Note: FCS_RBG_EXT.1/SW is for the kernel and user space RBG.
6.1.2.25 FCS_SRV_EXT.1 Cryptographic Algorithm Services
PP Origin: MDF
FCS_SRV_EXT.1.1
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
6.1.2.26 FCS_STG_EXT.1 Cryptographic Key Storage
PP Origin: MDF
FCS_STG_EXT.1.1
The TSF shall provide software-based secure key storage for asymmetric private keys and symmetric
keys, persistent secrets.
FCS_STG_EXT.1.2
The TSF shall be capable of importing keys or secrets into the secure key storage upon request of the
administrator and applications running on the TSF.
Version: 1.1 Classification: Public Page 64 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FCS_STG_EXT.1.3
The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of the
administrator.
FCS_STG_EXT.1.4
The TSF shall have the capability to allow only the application that imported the key or secret the use of
the key or secret. Exceptions may only be explicitly authorized by a common application developer.
FCS_STG_EXT.1.5
The TSF shall allow only the application that imported the key or secret to request that the key or secret
be destroyed. Exceptions may only be explicitly authorized by a common application developer.
6.1.2.27 FCS_STG_EXT.2 Encrypted Cryptographic Key Storage
PP Origin: MDF
FCS_STG_EXT.2.1
The TSF shall encrypt all DEKs, KEKs, WPA2/WPA3 (PSKs), IPsec (client certificates), Bluetooth
keys and all software-based key storage by KEKs that are
● Protected by the REK with
❍ encryption by a KEK chaining from a REK
● 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
DEKs, KEKs, WPA2/WPA3 (PSKs), IPsec (client certificates), 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.
6.1.2.28 FCS_STG_EXT.3 Integrity of Encrypted Key Storage
PP Origin: MDF
FCS_STG_EXT.3.1
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 previously known information.
FCS_STG_EXT.3.2
The TSF shall verify the integrity of the MAC of the stored key prior to use of the key.
6.1.2.29 FCS_STG_EXT.4 Cryptographic Key Storage
PP Origin: Agent
Version: 1.1 Classification: Public Page 65 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FCS_STG_EXT.4.1
The MDM Agent shall use the platform provided key storage for all persistent secret and private keys.
6.1.2.30 FCS_TLS_EXT.1 TLS Protocol
PP Origin: TLSPKG
FCS_TLS_EXT.1.1
The product shall implement TLS as a client.
6.1.2.31 FCS_TLSC_EXT.1 TLS Client Protocol
PP Origin: TLSPKG
Applied TDs: TD0442
FCS_TLSC_EXT.1.1
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_256_GCM_SHA384 as defined in RFC 5288
● 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
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
and also supports functionality for
● mutual authentication
● session renegotiation.
FCS_TLSC_EXT.1.2
The product shall verify that the presented identifier matches the reference identifier according to RFC
6125.
FCS_TLSC_EXT.1.3
The product shall not establish a trusted channel if the server certificate is invalid
● with no exceptions.
6.1.2.32 FCS_TLSC_EXT.1/WLAN TLS Client Protocol (EAP-TLS for WLAN)
PP Origin: WLANC
FCS_TLSC_EXT.1.1/WLAN
The TSF shall implement TLS 1.2 (RFC 5246) and TLS 1.1 (RFC 4346) in support of the EAP-TLS
protocol as specified in RFC 5216 supporting the following cipher suites:
● TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
● TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
Version: 1.1 Classification: Public Page 66 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
FCS_TLSC_EXT.1.2/WLAN
The TSF shall generate random values used in the EAP-TLS exchange using the RBG specified in
FCS_RBG_EXT.1.
FCS_TLSC_EXT.1.3/WLAN
The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1/WLAN.
FCS_TLSC_EXT.1.4/WLAN
The TSF shall verify that the server certificate presented includes the Server Authentication purpose (id-
kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
FCS_TLSC_EXT.1.5/WLAN
The TSF shall allow an authorized administrator to configure the list of CAs that are allowed to sign
authentication server certificates that are accepted by the TOE.
6.1.2.33 FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication
PP Origin: TLSPKG
FCS_TLSC_EXT.2.1
The product shall support mutual authentication using X.509v3 certificates.
6.1.2.34 FCS_TLSC_EXT.4 TLS Client Support for Renegotiation
PP Origin: TLSPKG
FCS_TLSC_EXT.4.1
The product shall support secure renegotiation through use of the "renegotiation_info" TLS extension in
accordance with RFC 5746.
6.1.2.35 FCS_TLSC_EXT.5 TLS Client Support for Supported Groups Extension
PP Origin: TLSPKG
FCS_TLSC_EXT.5.1
The product shall present the Supported Groups Extension in the Client Hello with the supported groups
● secp256r1
● secp384r1
● secp521r1
6.1.2.36 FCS_WPA_EXT.1 Supported WPA Versions
PP Origin: WLANC
FCS_WPA_EXT.1.1
Version: 1.1 Classification: Public Page 67 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TSF shall support WPA3 and WPA2 security type.
6.1.3 User data protection (FDP)
6.1.3.1 FDP_ACF_EXT.1 Access Control for System Services
PP Origin: MDF
FDP_ACF_EXT.1.1
The TSF shall provide a mechanism to restrict the system services that are accessible to an application.
FDP_ACF_EXT.1.2
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.
6.1.3.2 FDP_ACF_EXT.2 Access Control for System Resources
PP Origin: MDF
FDP_ACF_EXT.2.1
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.
6.1.3.3 FDP_DAR_EXT.1 Protected Data Encryption
PP Origin: MDF
FDP_DAR_EXT.1.1
Encryption shall cover all protected data.
FDP_DAR_EXT.1.2
Encryption shall be performed using DEKs with AES in the XTS mode with key size 128, 256 bits.
6.1.3.4 FDP_DAR_EXT.2 Sensitive Data Encryption
PP Origin: MDF
FDP_DAR_EXT.2.1
The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
FDP_DAR_EXT.2.2
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
Version: 1.1 Classification: Public Page 68 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used
for the protection of sensitive data according to FCS_STG_EXT.2.1 selection 2.
FDP_DAR_EXT.2.4
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.
6.1.3.5 FDP_IFC_EXT.1 Subset Information Flow Control
PP Origin: MDF, VPNC
FDP_IFC_EXT.1.1
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 Virtual Private Network (VPN) Clients, version 2.4
with the exception of IP traffic needed to manage the VPN connection, and AirPrint, cellular services,
voicemail, and initial Captive Network communication, when the VPN is enabled.
6.1.3.6 FDP_RIP.2 Full Residual Information Protection
PP Origin: VPNC
FDP_RIP.2.1
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.1.3.7 FDP_STG_EXT.1 User Data Storage
PP Origin: MDF
FDP_STG_EXT.1.1
The TSF shall provide protected storage for the Trust Anchor Database.
6.1.3.8 FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection
(Applications)
PP Origin: MDF
FDP_UPC_EXT.1.1/APPS
The TSF shall provide a means for non-TSF applications executing on the TOE to use
● Mutually authenticated TLS as defined in the Functional Package for Transport Layer Security (TLS),
version 1.1,
● HTTPS,
and
Version: 1.1 Classification: Public Page 69 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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
The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
6.1.3.9 FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection
(Bluetooth)
PP Origin: MDF
FDP_UPC_EXT.1.1/BLUETOOTH
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, version 1.0,
and
● Bluetooth LE in accordance with the PP-Module for Bluetooth, version 1.0
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
The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
6.1.3.10 FDP_VPN_EXT.1 Split Tunnel Prevention
PP Origin: VPNC
FDP_VPN_EXT.1.1
The TSF shall ensure that all IP traffic (other than IP traffic required to establish the VPN connection) flow
through the IPsec VPN client.
6.1.4 Identification and authentication (FIA)
6.1.4.1 FIA_AFL_EXT.1 Authentication Failure Handling
PP Origin: MDF
FIA_AFL_EXT.1.1
The TSF shall consider password and no other mechanism as critical authentication mechanisms.
FIA_AFL_EXT.1.2
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.
Version: 1.1 Classification: Public Page 70 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FIA_AFL_EXT.1.3
The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon
power off.
FIA_AFL_EXT.1.4
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
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
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user
that the authentication was unsuccessful.
6.1.4.2 FIA_BLT_EXT.1 Bluetooth User Authorization
PP Origin: BT
FIA_BLT_EXT.1.1
The TSF shall require explicit user authorization before pairing with a remote Bluetooth device.
6.1.4.3 FIA_BLT_EXT.2 Bluetooth Mutual Authentication
PP Origin: BT
FIA_BLT_EXT.2.1
The TSF shall require Bluetooth mutual authentication between devices prior to any data transfer over the
Bluetooth link.
6.1.4.4 FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections
PP Origin: BT
FIA_BLT_EXT.3.1
The TSF shall discard pairing and session initialization attempts from a Bluetooth device address
(BD_ADDR) to which an active session already exists.
6.1.4.5 FIA_BLT_EXT.4 Secure Simple Pairing
PP Origin: BT
FIA_BLT_EXT.4.1
Version: 1.1 Classification: Public Page 71 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the controller.
FIA_BLT_EXT.4.2
The TOE shall support Secure Simple Pairing during the pairing process.
6.1.4.6 FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization
PP Origin: BT
FIA_BLT_EXT.6.1
The TSF shall require explicit user authorization before granting trusted remote devices access to
services associated with the following Bluetooth profiles: none.
6.1.4.7 FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization
PP Origin: BT
FIA_BLT_EXT.7.1
The TSF shall require explicit user authorization before granting untrusted remote devices access to
services associated with the following Bluetooth profiles: none.
6.1.4.8 FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management
PP Origin: Agent
FIA_ENR_EXT.2.1
The MDM Agent shall record the reference identifier of the MDM Server during the enrollment process.
6.1.4.9 FIA_MBE_EXT.1 Biometric enrolment
PP Origin: BIO
Applied TDs: TD0714
FIA_MBE_EXT.1.1
The TSF shall provide a mechanism to enrol an authenticated user to the biometric system.
6.1.4.10 FIA_MBE_EXT.2 Quality of biometric templates for biometric enrolment
PP Origin: BIO
FIA_MBE_EXT.2.1
The TSF shall only use biometric samples of sufficient quality for enrolment. Sufficiency of sample data
shall be determined by measuring sample with a developer defined quality assessment method.
6.1.4.11 FIA_MBV_EXT.1 Biometric verification
PP Origin: BIO
FIA_MBV_EXT.1.1
Version: 1.1 Classification: Public Page 72 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TSF shall provide a biometric verification mechanism using face, fingerprint.
FIA_MBV_EXT.1.2
The TSF shall provide a biometric verification mechanism with the FAR not exceeding 0.01% for the
upper bound of 95% confidence interval and, FRR not exceeding 5% for the upper bound of 95%
confidence interval.
6.1.4.12 FIA_MBV_EXT.2 Quality of biometric samples for biometric verification
PP Origin: BIO
FIA_MBV_EXT.2.1
The TSF shall only use biometric samples of sufficient quality for verification. Sufficiency of sample data
shall be determined by measuring sample with a developer defined quality assessment method.
6.1.4.13 FIA_PAE_EXT.1 Port Access Entity Authentication
PP Origin: WLANC
FIA_PAE_EXT.1.1
The TSF shall conform to IEEE Standard 802.1X for a Port Access Entity (PAE) in the "Supplicant" role.
6.1.4.14 FIA_PMG_EXT.1 Password Management
PP Origin: MDF
FIA_PMG_EXT.1.1
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.
6.1.4.15 FIA_TRT_EXT.1 Authentication Throttling
PP Origin: MDF
FIA_TRT_EXT.1.1
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.
6.1.4.16 FIA_UAU.5 Multiple Authentication Mechanisms
PP Origin: MDF
FIA_UAU.5.1
The TSF shall provide password and biometric in accordance with the Biometric Enrollment and
Verification, version 1.1 to support user authentication.
Version: 1.1 Classification: Public Page 73 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FIA_UAU.5.2
The TSF shall authenticate any user's claimed identity according to the the validation of the user's
password, fingerprint, or face.
Application Note: The TSS describes authentication rules in more detail.
6.1.4.17 FIA_UAU.6/CREDENTIAL Re-Authenticating (Credential Change)
PP Origin: MDF
FIA_UAU.6.1/CREDENTIAL
The TSF shall re-authenticate the user via the Password Authentication Factor under the conditions
attempted change to any supported authentication mechanisms.
6.1.4.18 FIA_UAU.6/LOCKED Re-Authenticating (TSF Lock)
PP Origin: MDF
FIA_UAU.6.1/LOCKED
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, no other conditions.
6.1.4.19 FIA_UAU.7 Protected Authentication Feedback
PP Origin: MDF
FIA_UAU.7.1
The TSF shall provide only obscured feedback to the device's display to the user while the authentication
is in progress.
6.1.4.20 FIA_UAU_EXT.1 Authentication for Cryptographic Operation
PP Origin: MDF
FIA_UAU_EXT.1.1
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.
6.1.4.21 FIA_UAU_EXT.2 Timing of Authentication
PP Origin: MDF
FIA_UAU_EXT.2.1
The TSF shall allow
● Accessing Medical ID information
● Answering calls
● Making emergency calls
● Using the cameras (unless their use is generally disallowed)
Version: 1.1 Classification: Public Page 74 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Using the control center
● Using the flashlight
● Using the notification center
on behalf of the user to be performed before the user is authenticated.
FIA_UAU_EXT.2.2
The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated
actions on behalf of that user.
6.1.4.22 FIA_X509_EXT.1 X.509 Validation of Certificates
PP Origin: MDF
Applied TDs: TD0689
FIA_X509_EXT.1.1
The TSF shall validate certificates in accordance with the following rules:
● RFC 5280 certificate validation and certificate path validation.
● The certificate path must terminate with a 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:
❍ 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.
❍ 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.
❍ Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose
(id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]
❍ 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.
❍ OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp
9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]
FIA_X509_EXT.1.2
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and
the CA flag is set to TRUE.
6.1.4.23 FIA_X509_EXT.1/WLAN X.509 Certificate Validation
PP Origin: WLANC
FIA_X509_EXT.1.1/WLAN
The TSF shall validate certificates for EAP-TLS in accordance with the following rules:
Version: 1.1 Classification: Public Page 75 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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:
❍ 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
❍ 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
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.
6.1.4.24 FIA_X509_EXT.2 X.509 Certificate Authentication
PP Origin: MDF, VPNC
FIA_X509_EXT.2.1
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for mutually
authenticated TLS as defined in the
● Functional Package for Transport Layer Security (TLS), version 1.1
● HTTPS
● IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version
2.4
and
● code signing for system software updates
● code signing for mobile applications
● code signing for integrity verification
FIA_X509_EXT.2.2
When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF
shall accept the certificate.
6.1.4.25 FIA_X509_EXT.2/WLAN X.509 Certificate Authentication (EAP-TLS for
WLAN)
PP Origin: WLANC
FIA_X509_EXT.2.1/WLAN
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for EAP-TLS
exchanges.
6.1.4.26 FIA_X509_EXT.3 Request Validation of Certificates
PP Origin: MDF
Version: 1.1 Classification: Public Page 76 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FIA_X509_EXT.3.1
The TSF shall provide a certificate validation service to applications.
FIA_X509_EXT.3.2
The TSF shall respond to the requesting application with the success or failure of the validation.
6.1.4.27 FIA_X509_EXT.6 Certificate Storage and Management
PP Origin: WLANC
FIA_X509_EXT.6.1
The TSF shall store and protect certificate(s) from unauthorized deletion and modification.
FIA_X509_EXT.6.2
The TSF shall provide the capability for authorized administrators to load X.509v3 certificates
into the TOE for use by the TSF.
6.1.5 Security management (FMT)
6.1.5.1 FMT_MOF_EXT.1 Management of Security Functions Behavior
PP Origin: MDF
FMT_MOF_EXT.1.1
The TSF shall restrict the ability to perform the functions in column 4 of Table 7 Table 15 to the user.
FMT_MOF_EXT.1.2
The TSF shall restrict the ability to perform the functions in column 6 of Table 7 Table 15 to the
administrator when the device is enrolled and according to the administrator-configured policy.
6.1.5.2 FMT_POL_EXT.2 Agent Trusted Policy Update
PP Origin: Agent
Applied TDs: TD0755
FMT_POL_EXT.2.1
The MDM Agent shall only accept policies and policy updates that are digitally signed by a private key
that has been authorized for policy updates by the MDM Server.
FMT_POL_EXT.2.2
The MDM Agent shall not install policies if the signature check fails.
6.1.5.3 FMT_SMF.1 Specification of Management Functions
PP Origin: MDF, VPNC
Version: 1.1 Classification: Public Page 77 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Applied TDs: TD0711
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
Status Markers:
M - Mandatory
O - Optional/Objective
'-' - means that no value (M or O) can be assigned
(Y) - Optional and supported (i.e., Yes)
(N) - Optional and unsupported (i.e., No)
Table 15: Management Functions (MDF/VPNC)
# Management Function Impl. User
Only
Admin Admin
Only
1 configure password policy:
● Minimum password length
● Minimum password complexity
● Maximum password lifetime
M - M M
2 configure session locking policy:
● Screen-lock enabled/disabled
● Screen lock timeout
● Number of authentication failures
M - M M
3 enable/disable the VPN protection:
● Across device
● on a per-app basis
M (N) (Y) (N)
4 enable/disable Bluetooth, cellular, NFC, satellite, UWB,
and Wi-Fi radios
M (Y) (N) (N)
5 enable/disable cameras:
● Across device
● on a per-app basis
M (N) (Y) (N)
6 transition to the locked state M - M -
7 TSF wipe of protected data M - M -
8 configure application installation policy by
● denying installation of applications
M - M M
9 import keys or secrets into the secure key storage M (N) (Y) -
10 destroy imported keys or secrets and no other keys/secrets
in the secure key storage
M (N) (Y) -
11 import X.509v3 certificates into the Trust Anchor Database M - M (Y)
Version: 1.1 Classification: Public Page 78 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
12 remove imported X.509v3 certificates and no other X.509v3
certificates in the Trust Anchor Database
M (N) (Y) -
13 enroll the TOE in management M (Y) (N) (N)
14 remove applications M - M (Y)
15 update system software M - M (N)
16 install applications M - M (Y)
17 remove Enterprise applications M - M -
18 enable/disable display notification in the locked state of:
● all notifications
M (N) (Y) (N)
19 enable data-at-rest protection M (N) (N) (N)
20 enable removable media's data-at-rest protection M (Y) (N) (N)
21 enable/disable location services:
● Across device
● on a per-app basis
M (Y) (N) (N)
22 enable/disable the use of Biometric Authentication Factor (Y) (N) (Y) (Y)
23 configure whether to allow or disallow establishment of a TLS
trusted channel if the peer or server certificate is deemed
invalid.
(Y) (Y) (N) (N)
28 wipe Enterprise data (Y) (N) (Y) -
30 configure whether to allow or disallow establishment of a
trusted channel if the TSF cannot establish a connection to
determine the validity of a certificate
(Y) (N) (Y) (N)
32 read audit logs kept by the TSF (Y) (N) (Y) (N)
36 configure the unlock banner M - (Y) (Y)
37 configure the auditable items (Y) - (Y) (N)
44 unenroll the TOE from management (mandated by MDF Use
Case 3)
M - M -
45 enable/disable the Always On VPN protection:
● Across device
● no other method
(mandated by VPNC FMT_SMF.1)
M (N) (Y) (Y)
47 enable/disable microphones on a per-app basis (Y) (Y) (N) (N)
Version: 1.1 Classification: Public Page 79 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Application 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.
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.
Function 20 is supported in the evaluated configuration. Backups can be made using iTunes or
iCloud, and backup encryption can be made mandatory.
Function 23 is supported by TLS for the user. Function 23 is not supported by the VPN.
Function 26 has not been included in the table because the TOE does not support a developer
mode.
Function 27 has not been included in the table because the TOE (in its evaluated configuration)
does not support bypass of local user authentication.
Function 33 has not been included in the table because the feature is not configurable.
Functions 24,25,29,31,34,35,38,39,40,41,42,43, and 46 have not been included in the table
because the functions are optional.
6.1.5.4 FMT_SMF.1/VPN Specification of Management Functions (VPN)
PP Origin: VPNC
FMT_SMF.1.1/VPN
The TSF shall be capable of performing the following management functions:
● Specify VPN gateways to use for connections
6.1.5.5 FMT_SMF.1/WLAN Specification of Management Functions (WLAN Client)
PP Origin: WLANC
Applied TDs: TD0667
FMT_SMF.1.1/WLAN
The TSF shall be capable of performing the following management functions:
Status Markers:
M - Mandatory
O - Optional/Objective
X - Supported
'-' - Prohibited
Table 16: Management Functions (WLANC)
# Management Function Impl Admin User
WL-1 configure security policy for each wireless network: M M -
Version: 1.1 Classification: Public Page 80 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● specify the CA(s) from which the TSF will accept WLAN
authentication server certificate(s),
● security type,
● authentication protocol,
● client credentials to be used for authentication
WL-2 specify wireless networks (SSIDs) to which the TSF may connect M M -
WL-3 enable/disable disable wireless network bridging capability (for
example, bridging a connection between the WLAN and cellular
radios to function as a hotspot) authenticated by passcode
M M X
WL-4 enable/disable certificate revocation list checking - - -
WL-5 disable ad hoc wireless client-to-client connection capability
(a.k.a. Apple AirDrop)
X X X
WL-6 disable roaming capability X X -
WL-7 enable/disable IEEE 802.1X pre-authentication - - -
WL-8 loading X.509 certificates into the TOE X X -
WL-9 revoke X.509 certificates loaded into the TOE X X X
WL-10 enable/disable and configure PMK caching:
● set the amount of time (in minutes) for which PMK entries are
cached,
● set the maximum number of PMK entries that can be cached
- - -
WL-11 configure security policy for each wireless network: set wireless
frequency band to 2.4 GHz, 5 GHz, 6 GHz
- - -
6.1.5.6 FMT_SMF_EXT.1/BT Specification of Management Functions
PP Origin: BT
FMT_SMF_EXT.1.1/BT
The TSF shall be capable of performing the following Bluetooth management functions:
Status Markers:
M - Mandatory
X - Supported
'-' - Prohibited
Table 17: Management Functions (BT)
Function Impl. User
Only
Admin Admin
Only
BT-1. Configure the Bluetooth trusted channel.
● Disable/enable the Discoverable (for BR/EDR) and
Advertising (for LE) modes;
M X - -
Version: 1.1 Classification: Public Page 81 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
BT-2. Change the Bluetooth device name (separately for BR/EDR
and LE);
- - - -
BT-3. Provide separate controls for turning the BR/EDR and LE
radios on and off;
- - - -
BT-4. Allow/disallow the following additional wireless
technologies to be used with Bluetooth: no other wireless
technologies;
- - - -
BT-5. Configure allowable methods of Out of Band pairing (for
BR/EDR and LE);
- - - -
BT-6. Disable/enable the Discoverable (for BR/EDR) and
Advertising (for LE) modes separately;
- - - -
BT-7. Disable/enable the Connectable mode (for BR/EDR and
LE);
- - - -
BT-8. Disable/enable the Bluetooth list of Bluetooth service
and/or profiles available on the OS (for BR/EDR and LE);
- - - -
BT-9. Specify minimum level of security for each pairing (for BR/
EDR and LE);
- - - -
Application Note: The optional management functions are not supported.
6.1.5.7 FMT_SMF_EXT.2 Specification of Remediation Actions
PP Origin: MDF
FMT_SMF_EXT.2.1
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.
6.1.5.8 FMT_SMF_EXT.4 Specification of Management Functions
PP Origin: Agent
Applied TDs: TD0755
FMT_SMF_EXT.4.1
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
Version: 1.1 Classification: Public Page 82 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The MDM Agent shall be capable of performing the following functions:
● Enroll in management
● Configure whether users can unenroll from management
● no other functions.
6.1.5.9 FMT_UNR_EXT.1 User Unenrollment Prevention
PP Origin: Agent
FMT_UNR_EXT.1.1
The MDM Agent shall provide a mechanism to enforce the following behavior upon an attempt to unenroll
the mobile device from management:
● prevent the unenrollment from occurring
● apply remediation actions
6.1.6 Protection of the TSF (FPT)
6.1.6.1 FPT_AEX_EXT.1 Application Address Space Layout Randomization
PP Origin: MDF
FPT_AEX_EXT.1.1
The TSF shall provide address space layout randomization ASLR to applications.
FPT_AEX_EXT.1.2
The base address of any user-space memory mapping will consist of at least 8 unpredictable bits.
6.1.6.2 FPT_AEX_EXT.2 Memory Page Permissions
PP Origin: MDF
FPT_AEX_EXT.2.1
The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory.
6.1.6.3 FPT_AEX_EXT.3 Stack Overflow Protection
PP Origin: MDF
FPT_AEX_EXT.3.1
TSF processes that execute in a non-privileged execution domain on the application processor shall
implement stack-based buffer overflow protection.
6.1.6.4 FPT_AEX_EXT.4 Domain Isolation
PP Origin: MDF
FPT_AEX_EXT.4.1
Version: 1.1 Classification: Public Page 83 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TSF shall protect itself from modification by untrusted subjects.
FPT_AEX_EXT.4.2
The TSF shall enforce isolation of address space between applications.
6.1.6.5 FPT_BDP_EXT.1 Biometric data processing
PP Origin: BIO
FPT_BDP_EXT.1.1
Processing of plaintext biometric data shall be inside the SEE in runtime.
FPT_BDP_EXT.1.2
Transmission of plaintext biometric data between the capture sensor and the SEE shall be isolated from
the main computer operating system on the TSF in runtime.
6.1.6.6 FPT_JTA_EXT.1 JTAG Disablement
PP Origin: MDF
FPT_JTA_EXT.1.1
The TSF shall disable access through hardware to JTAG.
6.1.6.7 FPT_KST_EXT.1 Key Storage
PP Origin: MDF, BIO
FPT_KST_EXT.1.1
The TSF shall not store any plaintext key material or biometric data in readable non-volatile memory.
6.1.6.8 FPT_KST_EXT.2 No Key Transmission
PP Origin: MDF, BIO
FPT_KST_EXT.2.1
The TSF shall not transmit any plaintext key material or biometric data outside the security boundary of
the TOE.
6.1.6.9 FPT_KST_EXT.3 No Plaintext Key Export
PP Origin: MDF
FPT_KST_EXT.3.1
The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
6.1.6.10 FPT_NOT_EXT.1 Self-Test Notification
PP Origin: MDF
Version: 1.1 Classification: Public Page 84 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FPT_NOT_EXT.1.1
The TSF shall transition to non-operational mode and no other actions when the following types of
failures occur:
● failures of the self-tests
● TSF software integrity verification failures
● no other failures
6.1.6.11 FPT_PBT_EXT.1 Protection of biometric template
PP Origin: BIO
Applied TDs: TD0714
FPT_PBT_EXT.1.1
The TSF shall protect the biometric template using a password as an additional factor.
6.1.6.12 FPT_STM.1 Reliable Time Stamps
PP Origin: MDF
FPT_STM.1.1
The TSF shall be able to provide reliable time stamps for its own use.
6.1.6.13 FPT_TST_EXT.1 TSF Cryptographic Functionality Testing
PP Origin: MDF
FPT_TST_EXT.1.1
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.
6.1.6.14 FPT_TST_EXT.1/VPN TSF Self-Test
PP Origin: VPNC
FPT_TST_EXT.1.1/VPN
The TOE shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct
operation of the TSF.
FPT_TST_EXT.1.2/VPN
The TOE shall provide the capability to verify the integrity of stored TSF executable code when it is
loaded for execution through the use of the cryptographic services specified in FCS_COP.1/HASH ,
FCS_COP.1/SIGN , FCS_COP.1/KEYHMAC , or FIA_X509_EXT.1.
6.1.6.15 FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel)
PP Origin: MDF
Version: 1.1 Classification: Public Page 85 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FPT_TST_EXT.2.1/PREKERNEL
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.
6.1.6.16 FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel)
PP Origin: MDF
FPT_TST_EXT.2.1/POSTKERNEL
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.
6.1.6.17 FPT_TST_EXT.3 TSF Integrity Testing
PP Origin: MDF
FPT_TST_EXT.3.1
The TSF shall not execute code if the code signing certificate is deemed invalid.
6.1.6.18 FPT_TST_EXT.3/WLAN TSF Cryptographic Functionality Testing (WLAN
Client)
PP Origin: WLANC
FPT_TST_EXT.3.1/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.3.2/WLAN
The TOE shall provide the capability to verify the integrity of stored TSF executable code when it is
loaded for execution through the use of the TSF-provided cryptographic services.
6.1.6.19 FPT_TUD_EXT.1 TSF Version Query
PP Origin: MDF
FPT_TUD_EXT.1.1
The TSF shall provide authorized users the ability to query the current version of the TOE firmware/
software.
FPT_TUD_EXT.1.2
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
Version: 1.1 Classification: Public Page 86 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The TSF shall provide authorized users the ability to query the current version of installed mobile
applications.
6.1.6.20 FPT_TUD_EXT.2 TSF Update Verification
PP Origin: MDF
FPT_TUD_EXT.2.1
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
The TSF shall never update the TSF boot integrity key.
FPT_TUD_EXT.2.3
The TSF shall verify that the digital signature verification key used for TSF updates matches an
immutable hardware public key.
6.1.6.21 FPT_TUD_EXT.3 Application Signing
PP Origin: MDF
FPT_TUD_EXT.3.1
The TSF shall verify mobile application software using a digital signature mechanism prior to installation.
6.1.6.22 FPT_TUD_EXT.4 Trusted Update Verification
PP Origin: MDF
FPT_TUD_EXT.4.1
The TSF shall not install code if the code signing certificate is deemed invalid.
6.1.6.23 FPT_TUD_EXT.5 Application Verification
PP Origin: MDF
FPT_TUD_EXT.5.1
The TSF shall by default only install mobile applications cryptographically verified by a built-in X.509v3
certificate.
6.1.6.24 FPT_TUD_EXT.6 Trusted Update Verification
PP Origin: MDF
FPT_TUD_EXT.6.1
The TSF shall verify that software updates to the TSF are a current or later version than the current
version of the TSF.
Version: 1.1 Classification: Public Page 87 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.7 TOE access (FTA)
6.1.7.1 FTA_SSL_EXT.1 TSF- and User-initiated Locked State
PP Origin: MDF
FTA_SSL_EXT.1.1
The TSF shall transition to a locked state after a time interval of inactivity.
FTA_SSL_EXT.1.2
The TSF shall transition to a locked state after initiation by either the user or the administrator.
FTA_SSL_EXT.1.3
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.
6.1.7.2 FTA_TAB.1 Default TOE Access Banners
PP Origin: MDF
FTA_TAB.1.1
Before establishing a user session, the TSF shall display an advisory warning message regarding
unauthorized use of the TOE.
6.1.7.3 FTA_WSE_EXT.1 Wireless Network Access
PP Origin: WLANC
FTA_WSE_EXT.1.1
The TSF shall be able to attempt connections only to wireless networks specified as acceptable networks
as configured by the administrator in FMT_SMF.1/WLAN.
6.1.8 Trusted path/channels (FTP)
6.1.8.1 FTP_BLT_EXT.1 Bluetooth Encryption
PP Origin: BT
FTP_BLT_EXT.1.1
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
The TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption.
Version: 1.1 Classification: Public Page 88 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
6.1.8.2 FTP_BLT_EXT.2 Persistence of Bluetooth Encryption
PP Origin: BT
FTP_BLT_EXT.2.1
The TSF shall terminate the connection if the remote device stops encryption while connected to the
TOE.
6.1.8.3 FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR)
PP Origin: BT
FTP_BLT_EXT.3.1/BR
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.
6.1.8.4 FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE)
PP Origin: BT
FTP_BLT_EXT.3.1/LE
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.
6.1.8.5 FTP_ITC.1/WLAN Trusted Channel Communication (Wireless LAN)
PP Origin: WLANC
FTP_ITC.1.1/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
and provides assured identification of its end points and protection of the channel data from modification
or disclosure.
FTP_ITC.1.2/WLAN
The TSF shall permit the TSF to initiate communication via the trusted channel.
FTP_ITC.1.3/WLAN
The TSF shall initiate communication via the trusted channel for wireless access point connections.
6.1.8.6 FTP_ITC_EXT.1 Trusted Channel Communication
PP Origin: MDF, VPNC
FTP_ITC_EXT.1.1
The TSF shall use
● 802.11-2012 in accordance with the PP-Module for Wireless LAN Clients, version 1.0,
Version: 1.1 Classification: Public Page 89 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 802.1X in accordance with the PP-Module for Wireless LAN Clients, version 1.0,
● EAP-TLS in accordance with the PP-Module for Wireless LAN Clients, version 1.0,
● Mutually authenticated TLS in accordance with the Functional Package for Transport Layer Security
(TLS), version 1.1
and
● IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version
2.4
● 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
The TSF shall permit the TSF to initiate communication via the trusted channel.
FTP_ITC_EXT.1.3
The TSF shall initiate communication via the trusted channel for wireless access point connections,
administrative communication, configured enterprise connections, and OTA updates.
6.1.8.7 FTP_ITC_EXT.1(2) Trusted Channel Communication
PP Origin: Agent
FTP_ITC_EXT.1.1(2)
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)
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)
The TSF shall initiate communication via the trusted channel for all communication between the MDM
Agent and the MDM Server and no other communication
6.1.8.8 FTP_TRP.1(2) Trusted Path (for Enrollment)
PP Origin: Agent
FTP_TRP.1.1(2)
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.
Version: 1.1 Classification: Public Page 90 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FTP_TRP.1.2(2)
The TSF shall permit MD users to initiate communication via the trusted path.
FTP_TRP.1.3(2)
The TSF shall require the use of the trusted path for all MD user actions.
6.2 Security Functional Requirements Rationale
The SFR rationale is defined in the documents specified in Section 2 "CC Conformance Claim".
6.3 Security Assurance Requirements
The security assurance requirements (SARs) for the TOE are defined in assurance packages.
The following table shows the SARs, and the operations performed on the components according to CC part 3:
iteration (Iter.), refinement (Ref.), assignment (Ass.) and selection (Sel.).
Table 18: SARs
Operations
Security
assurance class
Security assurance requirement Source
Iter. Ref. Ass. Sel.
ALC_TSU_EXT.1 Timely Security Updates MDF No No No No
ALC_CMC.1 Labelling of the TOE No No No No
ALC Life-cycle
support
ALC_CMS.1 TOE CM coverage No No No No
ASE_CCL.1 Conformance claims No No No No
ASE_ECD.1 Extended components definition No No No No
ASE_INT.1 ST introduction No No No No
ASE_OBJ.1 Security objectives for the operational
environment
No No No No
ASE_REQ.1 Stated security requirements No No No No
ASE_SPD.1 Security problem definition No No No No
ASE Security
Target evaluation
ASE_TSS.1 TOE summary specification No No No No
ADV Development ADV_FSP.1 Basic functional specification No No No No
AGD_OPE.1 Operational user guidance No No No No
AGD Guidance
documents
AGD_PRE.1 Preparative procedures No No No No
ATE Tests ATE_IND.1 Independent testing - conformance No No No No
AVA Vulnerability
assessment
AVA_VAN.1 Vulnerability survey No No No No
6.3.1 ALC Life-cycle support
6.3.1.1 ALC_TSU_EXT.1 Timely Security Updates
Developer action elements:
Version: 1.1 Classification: Public Page 91 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
ALC_TSU_EXT.1.1D
The developer shall provide a description in the TSS of how timely security updates are made to the TOE.
Content and presentation elements:
ALC_TSU_EXT.1.2C
The description shall include the process for creating and deploying security updates for the TOE
software.
ALC_TSU_EXT.1.3C
The description shall express the time window as the length of time, in days, between public disclosure of
a vulnerability and the public availability of security updates to the TOE.
ALC_TSU_EXT.1.4C
The description shall include the mechanisms publicly available for reporting security issues pertaining to
the TOE.
ALC_TSU_EXT.1.5C
The description shall include where users can seek information about the availability of new updates
including details (e.g. CVE identifiers) of the specific public vulnerabilities corrected by each update.
Evaluator action elements:
ALC_TSU_EXT.1.6E
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
6.4 Security Assurance Requirements Rationale
The SAR rationale is defined in the documents specified in Section 2 "CC Conformance Claim".
Version: 1.1 Classification: Public Page 92 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7 TOE Summary Specification
Table 19 provides a mapping of SFRs to the TSS information.
Table 19: SFR to TSS mappings
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FAU
FAU_ALT_EXT.2.1
PP Origin: 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.
7.1.8 "Trusted Path/Channels (FTP)"
7.1.9.2 "MDM Agent Alerts"
Table 30 "MDM Agent Status
Commands"
7.1.9.2.3 "Alerts on receiving periodic
reachability events"
FAU_ALT_EXT.2.2
PP Origin: 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.
7.1.9.2.1 "Queuing of Alerts"
FAU_GEN.1
PP Origin: MDF
Lists all of the auditable events and provides a
format for audit records. Each audit record format
type must be covered, along with a brief description
of each field. Provides that every audit event type
mandated by the PP is described and that the
description of the fields contains the information
required in FAU_GEN.1.2.
7.1.9.1 "Audit Records"
Table 10 "Mandatory Auditable
Events (MDF)"
FAU_GEN.1.1(2)
PP Origin: Agent
Provides a format for audit records. Each audit
record format type must be covered, along with a
brief description of each field.
7.1.9.1 "Audit Records"
Table 11 "Auditable Events (Agent)"
FAU_GEN.1.2(2)
PP Origin: Agent
Provides a format for audit records, and a brief
description of each field.
7.1.9.1 "Audit Records"
FAU_GEN.1/BT
PP Origin: BT
Evaluated in the same manner as defined by the
Evaluation Activities for the claimed Base-PP.
7.1.9.1 "Audit Records"
Table 12 "Auditable Events (BT)"
FAU_GEN.1/VPN
PP Origin: VPNC
Describes the auditable events and the component
that is responsible for each type of auditable event.
7.1.9.1 "Audit Records"
Table 13 "Auditable Events (VPN)"
Table 7.1.8.4.2 "IPsec General"
FAU_GEN.1/WLAN
PP Origin: WLANC
Provides a format for audit records. Each audit
record format type must be covered, along with a
brief description of each field.
7.1.9.1 "Audit Records"
FAU_SAR.1 There are no TSS evaluation activities for this SFR.
Version: 1.1 Classification: Public Page 93 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
PP Origin: MDF
FAU_SEL.1.1(2)
PP Origin: Agent
There is no TSS assurance activity for this SFR.
FAU_STG.1.1
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FAU_STG.1.2
PP Origin: MDF
Lists the location of all logs and the access controls
of those files such that unauthorized modification
and deletion are prevented.
7.1.9.1 "Audit Records"
FAU_STG.4.1
PP Origin: 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.
7.1.9.1 "Audit Records"
7.1.5.2 "Configuration Profiles"
FCS
FCS_CKM.1
PP Origin: MDF, VPNC
Identifies the key sizes supported by the TOE. If the
ST specifies more than one scheme, it identifies the
usage for each scheme.
Table 22 "Explanation of usage
for cryptographic functions in the
cryptographic modules"
FCS_CKM.1/VPN
PP Origin: VPNC
Describes how the key generation functionality is
invoked.
7.1.8.4.3 "IPsec Characteristics"
FCS_CKM.1/WPA
PP Origin: WLANC
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.
7.1.8.3 "Wireless LAN (WLAN)"
A.2 "Wi-Fi Alliance Certificates"
FCS_CKM.2.1/UNLOCKED
PP Origin: MDF, VPNC
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.
7.1.2.1 "Overview of Key
Management"
7.1.2.2 "Password based key
derivation"
FCS_CKM.2.1/LOCKED
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FCS_CKM.2.1/WLAN
PP Origin: WLANC
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.
7.1.8.3 "Wireless LAN (WLAN)"
FCS_CKM_EXT.1
PP Origin: MDF
Shows that a REK is supported by the TOE. 7.1.1.1 "The Secure Enclave
Processor (SEP)"
Version: 1.1 Classification: Public Page 94 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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).
7.1.2.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
PP Origin: MDF
Describes how the functionality described by
FCS_RBG_EXT.1 is invoked to generate DEKs.
Figure 5 "Key Hierarchy in the TOE
OS"
7.1.1 "Hardware Protection
Functions"
7.1.2 "Cryptographic Support (FCS)"
FCS_CKM_EXT.3
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
Figure 5 "Key Hierarchy in the TOE
OS"
This RBG in the Secure Enclave has
been analyzed for compliance with
the requirements of FCS_RBG_EXT.1/
HW in the proprietary EAR, which has
been provided to NIAP.
Version: 1.1 Classification: Public Page 95 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FCS_CKM_EXT.4
PP Origin: MDF
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.
7.1.2.1 "Overview of Key
Management"
Table 20 "Summary of keys and
persistent secrets in the TOE OS"
Table 21 "Summary of keys and
persistent secrets used by the MDM
Agent"
FCS_CKM_EXT.5
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
Figure 5 "Key Hierarchy in the TOE
OS"
FCS_CKM_EXT.6
PP Origin: 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.
7.1.1 "Hardware Protection
Functions"
FCS_CKM_EXT.7
PP Origin: MDF
See FCS_CKM_EXT.1 in this table. See FCS_CKM_EXT.1 in this table.
Version: 1.1 Classification: Public Page 96 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FCS_CKM_EXT.8
PP Origin: 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.
7.1.8.2 "Bluetooth"
FCS_COP.1/ENCRYPT
PP Origin: MDF, VPNC
There is no TSS assurance activity for this SFR.
FCS_COP.1/HASH
PP Origin: MDF
Documents the association of the hash function
with other TSF cryptographic functions.
7.1.2 "Cryptographic Support (FCS)"
FCS_COP.1/SIGN
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FCS_COP.1/KEYHMAC
PP Origin: 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 22 "Explanation of usage
for cryptographic functions in the
cryptographic modules"
7.1.2 "Cryptographic Support (FCS)"
7.1.3.8 "Keyed Hash"
FCS_COP.1/CONDITION
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
7.1.2.2 "Password based key
derivation"
FCS_HTTPS_EXT.1
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FCS_IPSEC_EXT.1.1
PP Origin: VPNC
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.
7.1.8.4 "VPN"
7.1.8.4.1 "AlwaysOn VPN"
7.1.8.4.2 "IPsec General"
Version: 1.1 Classification: Public Page 97 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FCS_IPSEC_EXT.1.2
PP Origin: VPNC
States that the VPN can be established to operate in
tunnel mode and/or transport mode (as selected).
7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
FCS_IPSEC_EXT.1.3
PP Origin: VPNC
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.
7.1.8.4 "VPN"
7.1.8.4.2 "IPsec General"
FCS_IPSEC_EXT.1.4
PP Origin: VPNC
States that the algorithms AES-GCM-128, AES-
GCM-256, AES-CBC-128, and AES-CBC-256 are
implemented.
7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
FCS_IPSEC_EXT.1.5
PP Origin: VPNC
States that IKEv2 is implemented. 7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
FCS_IPSEC_EXT.1.6
PP Origin: VPNC
Identifies the algorithms used for encrypting the
IKEv2 payload (AES-CBC-128, AES-CBC-256, AES-
GCM-128, AES-GCM-256).
7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
FCS_IPSEC_EXT.1.7
PP Origin: VPNC
There is no TSS assurance activity for this SFR.
FCS_IPSEC_EXT.1.8
PP Origin: VPNC
Lists the supported DH groups.
Describes how a particular DH group is specified/
negotiated with a peer.
7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
7.1.8.4.5 "IKE"
FCS_IPSEC_EXT.1.9
FCS_IPSEC_EXT.1.10
PP Origin: VPNC
Describes, for each DH group supported,
the process for generating "x" (as defined in
FCS_IPSEC_EXT.1.9) and each nonce.
7.1.8.4 "VPN"
7.1.8.4.5 "IKE"
Version: 1.1 Classification: Public Page 98 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FCS_IPSEC_EXT.1.11
FCS_IPSEC_EXT.1.12
FCS_IPSEC_EXT.1.13
PP Origin: VPNC
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.
7.1.8.4 "VPN"
7.1.8.4.3 "IPsec Characteristics"
7.1.8.4.4 "Peer authentication"
FCS_IPSEC_EXT.1.14
PP Origin: VPNC
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.
7.1.8.4 "VPN"
7.1.8.4.5 "IKE"
FCS_IV_EXT.1
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
Figure 5 "Key Hierarchy in the TOE
OS"
FCS_RBG_EXT.1/HW
FCS_RBG_EXT.1/SW
PP Origin: 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.
FCS_SRV_EXT.1
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FCS_STG_EXT.1
PP Origin: 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.”
7.1.2.1 "Overview of Key
Management"
7.1.3.6 "Keychain Data Protection"
Version: 1.1 Classification: Public Page 99 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FCS_STG_EXT.2
PP Origin: MDF
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).
7.1.2.1 "Overview of Key
Management"
Figure 5 "Key Hierarchy in the TOE
OS"
FCS_STG_EXT.2
PP Origin: MDF
States in the key hierarchy description in that
each DEK and software-stored key is encrypted
according to FCS_STG_EXT.2.
7.1.2.1 "Overview of Key
Management"
Figure 5 "Key Hierarchy in the TOE
OS"
FCS_STG_EXT.3
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
FCS_STG_EXT.4
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
7.1.2.2 "Password based key
derivation"
7.1.2.4 "Storage of Persistent Secrets
and Private Keys by the MDM Agent"
FCS_TLS_EXT.1
PP Origin: TLSPKG
There is no TSS assurance activity for this SFR.
FCS_TLSC_EXT.1.1
PP Origin: TLSPKG
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.
7.1.8.1 "EAP-TLS and TLS"
FCS_TLSC_EXT.1.2
PP Origin: TLSPKG
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.
7.1.8.1 "EAP-TLS and TLS"
FCS_TLSC_EXT.1.3
PP Origin: TLSPKG
Describes how and when user or administrator
authorization is obtained.
7.1.8.1 "EAP-TLS and TLS"
Version: 1.1 Classification: Public Page 100 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FCS_TLSC_EXT.1/WLAN
PP Origin: WLANC
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.
7.1.4.2 "X.509v3 Certificates"
7.1.8.1 "EAP-TLS and TLS"
FCS_TLSC_EXT.2
PP Origin: TLSPKG
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.
7.1.8.1.1 "TLS mutual authentication"
7.1.4.2 "X.509v3 Certificates"
FCS_TLSC_EXT.4
PP Origin: TLSPKG
There is no TSS assurance activity for this SFR.
FCS_TLSC_EXT.5
PP Origin: TLSPKG
Describes the Supported Groups Extension. 7.1.8.1 "EAP-TLS and TLS"
FCS_WPA_EXT.1
PP Origin: WLANC
There are no TSS evaluation activities for this SFR.
FDP
FDP_ACF_EXT.1.1
PP Origin: 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.
7.1.3.1 "Protection of Files"
7.1.3.2 "Application Access to Files"
7.1.3.5 "Restricting Applications
Access to Services"
Version: 1.1 Classification: Public Page 101 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FDP_ACF_EXT.1.2
PP Origin: MDF
Describes which data sharing is permitted between
applications, which data sharing is not permitted,
and how disallowed sharing is prevented.
7.1.3.1 "Protection of Files"
7.1.3.2 "Application Access to Files"
7.1.3.5 "Restricting Applications
Access to Services"
FDP_ACF_EXT.2
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FDP_DAR_EXT.1
PP Origin: MDF
Indicates which data is protected by the DAR
implementation and what data is considered TSF
data. This data includes all protected data.
7.1.2.1 "Overview of Key
Management"
7.1.3.6 "Keychain Data Protection"
Figure 5 "Key Hierarchy in the TOE
OS"
FDP_DAR_EXT.2.1
PP Origin: 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.
7.1.3.6 "Keychain Data Protection"
Table 23 "Keychain to File-system
Mapping"
FDP_DAR_EXT.2.2
PP Origin: 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.
7.1.3.6 "Keychain Data Protection"
Table 23 "Keychain to File-system
Mapping"
FDP_DAR_EXT.2.3
PP Origin: 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.
7.1.3.6 "Keychain Data Protection"
Table 23 "Keychain to File-system
Mapping"
Version: 1.1 Classification: Public Page 102 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FDP_DAR_EXT.2.4
PP Origin: 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.
7.1.3.6 "Keychain Data Protection"
Table 23 "Keychain to File-system
Mapping"
FDP_IFC_EXT.1
PP Origin: MDF, VPNC
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).
7.1.8.4.1 "AlwaysOn VPN"
FDP_RIP.2
PP Origin: VPNC
Describes (for each supported platform) the extent
to which the client processes network packets and
addresses the FDP_RIP.2 requirement.
7.1.8.4.6 "Residual information
protection and packet processing"
FDP_STG_EXT.1
PP Origin: 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.1 and
FMT_MOF_EXT.1.
7.1.4.2 "X.509v3 Certificates"
FDP_UPC_EXT.1/APPS
PP Origin: MDF
Describes that all protocols listed in the TSS are
specified and included in the requirements in the
ST.
7.1.8 "Trusted Path/Channels (FTP)"
FDP_UPC_EXT.1/
BLUETOOTH
PP Origin: MDF
Describes that all protocols listed in the TSS are
specified and included in the requirements in the
ST.
7.1.8 "Trusted Path/Channels (FTP)"
FDP_VPN_EXT.1
PP Origin: VPNC
Describes the routing of IP traffic through processes
on the TSF when a VPN client is enabled.
7.1.8.4.1 "AlwaysOn VPN"
Version: 1.1 Classification: Public Page 103 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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).
FIA
FIA_AFL_EXT.1
PP Origin: 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.
7.1.5.2 "Configuration Profiles"
7.1.4 "Identification and
Authentication (FIA)"
FIA_BLT_EXT.1
PP Origin: 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.
7.1.8.2 "Bluetooth"
FIA_BLT_EXT.2
PP Origin: BT
Describes how data transfer of any type is
prevented before the Bluetooth pairing is
completed.
7.1.8.2 "Bluetooth"
Version: 1.1 Classification: Public Page 104 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
Specifically calls out any supported radio frequency
communication (RFCOMM) and L2CAP data transfer
mechanisms
FIA_BLT_EXT.3
PP Origin: 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.
7.1.8.2 "Bluetooth"
FIA_BLT_EXT.4
PP Origin: BT
There is no TSS assurance activity for this SFR.
FIA_BLT_EXT.6
PP Origin: 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'.
7.1.8.2 "Bluetooth"
FIA_BLT_EXT.7
PP Origin: BT
See FIA_BLT_EXT.6.1. See FIA_BLT_EXT.6.1.
FIA_ENR_EXT.2
PP Origin: Agent
Describes which types of reference identifiers are
acceptable and how the identifier is specified.
7.1.4.3 "MDM Server Reference ID"
Table 24 "MDM Server Reference
Identifiers"
FIA_MBE_EXT.1
PP Origin: BIO
Explains how the TOE meets FIA_MBE_EXT.1 at high
level description and describes how the TOE enrols
a user.
7.1.5.3 "Biometric Authentication
Factors (BAFs)"
FIA_MBE_EXT.2
PP Origin: BIO
Explains how the TOE meets FIA_MBE_EXT.2 at high
level description.
If standard quality metrics are selected and
assigned, the TSS shall include information (e.g.
name of quality metrics and section numbers that
define the metrics in the standard) to identify quality
metrics that the TOE implements.
If a developer defined quality assessment is
selected, the TSS shall include an overview of the
quality metrics used for the assessment.
Between the TSS and the Biometric Management
Design (BMD), describes how the TOE generates
templates of sufficient quality from samples at
enrolment.
7.1.4.1.2 "Biometric Sample Quality"
Version: 1.1 Classification: Public Page 105 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FIA_MBV_EXT.1
PP Origin: BIO
Explains how the TOE meets FIA_MBV_EXT.1 at
high level description and, between the TSS and the
Biometric Management Design (BMD), describes
how the TOE verifies a user with one's biometric
characteristics.
7.1.5.3 "Biometric Authentication
Factors (BAFs)"
7.1.4.1.1 "Accuracy of Biometric
Authentication"
FIA_MBV_EXT.2
PP Origin: BIO
Explains how the TOE meets FIA_MBV_EXT.2 at
high level description.
If standard quality metrics are selected and
assigned, it includes information (e.g. name of
quality metrics and section numbers that define the
metrics in the standard) to identify quality metrics
that the TOE implements.
If a developer defined quality assessment is
selected, it includes an overview of the quality
metrics used for the assessment.
Between the TSS and the Biometric Management
Design (BMD), describes how the TOE checks the
quality of the samples captured.
7.1.4.1.2 "Biometric Sample Quality"
FIA_PAE_EXT.1
PP Origin: WLANC
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
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FIA_TRT_EXT.1
PP Origin: 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.
7.1.4 "Identification and
Authentication (FIA)"
FIA_UAU.5
PP Origin: MDF
Describes each mechanism provided to support
user authentication and the rules describing
how the authentication mechanism(s) provide
authentication.
7.1.4 "Identification and
Authentication (FIA)"
FIA_UAU.6/CREDENTIAL
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FIA_UAU.6/LOCKED
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FIA_UAU.7
PP Origin: MDF
Describes the means of obscuring the
authentication entry, for all authentication methods
specified in FIA_UAU.5.1.
7.1.4 "Identification and
Authentication (FIA)"
Version: 1.1 Classification: Public Page 106 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FIA_UAU_EXT.1
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
FIA_UAU_EXT.2
PP Origin: MDF
Describes the actions allowed by unauthorized
users in the locked state.
7.1.4 "Identification and
Authentication (FIA)"
FIA_X509_EXT.1
PP Origin: MDF
FIA_X509_EXT.1/WLAN
PP Origin: WLANC
Describes where the check of validity of the
certificates takes place.
Describes the certificate path validation algorithm.
7.1.4.2 "X.509v3 Certificates"
FIA_X509_EXT.2
PP Origin: MDF, VPNC
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.
7.1.4.2 "X.509v3 Certificates"
FIA_X509_EXT.2/WLAN
PP Origin: WLANC
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.
7.1.8.3 "Wireless LAN (WLAN)"
FIA_X509_EXT.3
PP Origin: MDF
There is no TSS assurance activity for this SFR.
FIA_X509_EXT.6
PP Origin: WLANC
Describes all certificate stores implemented that
contain certificates used to meet the requirements
of this PP-Module. The description shall contain
information pertaining to how certificates are loaded
into the store, and how the store is protected from
unauthorized access.
7.1.4.2 "X.509v3 Certificates"
FMT
FMT_MOF_EXT.1.1
PP Origin: 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 15 "Management Functions
(MDF/VPNC)"
Version: 1.1 Classification: Public Page 107 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FMT_MOF_EXT.1.2
PP Origin: 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 15 "Management Functions
(MDF/VPNC)"
7.1.5.2 "Configuration Profiles"
FMT_POL_EXT.2.1
PP Origin: 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.
7.1.5.2 "Configuration Profiles"
FMT_POL_EXT.2.2
PP Origin: Agent
See FIA_X509_EXT.1.1 and FIA_X509_EXT.2.1 See FIA_X509_EXT.1.1 and
FIA_X509_EXT.2.1
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.
7.1.5 "Specification of Management
Functions (FMT)"
Table 15 "Management Functions
(MDF/VPNC)"
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.
7.1.4 "Identification and
Authentication (FIA)"
7.1.5.2 "Configuration Profiles"
Function 2:
Defines the range of values for both timeout
period and number of authentication failures for all
supported authentication mechanisms.
7.1.4 "Identification and
Authentication (FIA)"
7.1.5.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.
7.1.5.5 "Radios"
Appendix A.1 "Devices Covered by
this Evaluation"
Table 15 "Management Functions
(MDF/VPNC)"
FMT_SMF.1
PP Origin: MDF, VPNC
Function 5: 7.1.5.2 "Configuration Profiles"
Version: 1.1 Classification: Public Page 108 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
Describes each collection device and an indication if
it can be enabled/disabled along with what role can
do so.
7.1.5.6 "Audio and Visual collection
devices"
Table 15 "Management Functions
(MDF/VPNC)"
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.
7.1.5.2 "Configuration Profiles"
Function 9:
Describes each category of keys/secrets that can
be imported into the TSF's secure key storage.
7.1.2.1 "Overview of Key
Management"
Table 20 "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.
7.1.4.2 "X.509v3 Certificates"
Function 13:
Describes each management function that will
be enforced by the enterprise once the device is
enrolled.
7.1.5.2 "Configuration Profiles"
Function 14:
Indicates which applications can be removed along
with what role can do so
7.1.5.2 "Configuration Profiles"
Function 15:
There is no TSS assurance activity for this function.
Function 16:
There is no TSS assurance activity for this function.
Function 17:
There is no TSS assurance activity for this function.
Function 18:
There is no TSS assurance activity for this function.
Version: 1.1 Classification: Public Page 109 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
Function 19:
There is no TSS assurance activity for this function.
Function 20:
There is no TSS assurance activity for this function.
7.1.5.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.
7.1.5.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 32:
There is no TSS assurance activity for this function.
Function 36:
Describes any restrictions in banner settings.
7.1.7.3 "Lock Screen/Access Banner
Display"
Function 37:
There is no TSS assurance activity for this function.
Function 44:
There is no TSS assurance activity for this function.
Function 45:
Contains guidance to configure the VPN as Always-
On.
7.1.8.4.1 "AlwaysOn VPN"
Function 47:
Describes all assigned
security management
functions and their
intended behavior.
7.1.5.2 "Configuration Profiles"
7.1.5.6 "Audio and Visual collection devices"
Describes the Bluetooth profiles and services
supported and the Bluetooth security modes and
levels supported by the TOE.
7.1.8.2 "Bluetooth"
FMT_SMF_EXT.1/BT
PP Origin: BT
Function BT-1:
There is no TSS assurance activity for this function.
Version: 1.1 Classification: Public Page 110 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FMT_SMF.1/VPN
PP Origin: VPNC
Describes the client credentials and how they are
used by the TOE.
7.1.5.7 "VPN Certificate Credentials"
7.1.8.4.4 "Peer authentication"
FMT_SMF.1/WLAN
PP Origin: WLANC
There is no TSS assurance activity for this SFR.
FMT_SMF_EXT.2
PP Origin: 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.
7.1.2.1 "Overview of Key
Management"
7.1.5.4 "Device Unenrollment"
FMT_SMF_EXT.4.1
PP Origin: 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.
7.1.5.1 "Device Enrollment"
FMT_SMF_EXT.4.2
PP Origin: 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.
7.1.5.1 "Device Enrollment"
7.1.5.4 "Device Unenrollment"
FMT_UNR_EXT.1
PP Origin: Agent
Describes the mechanism used to prevent users
from unenrolling or the remediation actions applied
when unenrolled.
7.1.5.4 "Device Unenrollment"
FPT
FPT_AEX_EXT.1
PP Origin: MDF
Describes how the 8 bits are generated and
provides a justification as to why those bits are
unpredictable.
7.1.6.5 "Domain Isolation"
FPT_AEX_EXT.2
PP Origin: 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.
7.1.6.5 "Domain Isolation"
FPT_AEX_EXT.3
PP Origin: 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.
7.1.6.5 "Domain Isolation"
7.1.6.8 "Inventory of TSF Binaries and
Libraries"
FPT_AEX_EXT.4
PP Origin: 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.
7.1.6.5 "Domain Isolation"
Version: 1.1 Classification: Public Page 111 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FPT_BDP_EXT.1
PP Origin: BIO
Explains how the TOE meets FPT_BDP_EXT.1 at high
level description.
Contains the following:
a. All TSF modules and physical
interconnections are within the defined
boundary of the SEE and any entities outside
the SEE including the main computer
operating system can’t interfere with
transmission between and processing of
these modules.
b. All plaintext biometric data (whether
generated by the biometric capture sensor
or by the evaluation processes of the TSF)
is retained in volatile memory within the SEE
and any entities outside the SEE including
the main computer operating system can’t
access these data. Any TSFIs which may
exist, do not reveal plaintext biometric data
to any entities outside the SEE. The evaluator
shall examine TSFIs of TSF modules provided
by the biometric capture sensor (e.g. SDK)
because they may include testing or debug
codes and the developer who integrated the
sensor into the TOE may apply changes to
those modules.
7.1.5.3 "Biometric Authentication
Factors (BAFs)"
7.1.2.3 "No plaintext key transmission
and export"
FPT_JTA_EXT.1
PP Origin: 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.
7.1.6.2 "Joint Test Action Group
(JTAG) Disablement"
Version: 1.1 Classification: Public Page 112 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
Describes when the JTAG can be accessed, i.e.
what has the access to the signing key.
FPT_KST_EXT.1
PP Origin: MDF, BIO
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.
7 "TOE Summary Specification"
7.1.2.1 "Overview of Key
Management"
7.1.1.1 "The Secure Enclave
Processor (SEP)"
FPT_KST_EXT.2
PP Origin: MDF, BIO
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
7 "TOE Summary Specification"
7.1.2.1 "Overview of Key
Management"
7.1.2.3 "No plaintext key transmission
and export"
7.1.1.1 "The Secure Enclave
Processor (SEP)"
Version: 1.1 Classification: Public Page 113 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
security boundary of the TOE or to other functions
or systems that transmit information outside the
security boundary of the TOE.
FPT_KST_EXT.3
PP Origin: 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.
7.1.1.1 "The Secure Enclave
Processor (SEP)"
7.1.2.3 "No plaintext key transmission
and export"
FPT_NOT_EXT.1
PP Origin: MDF
Describes critical failures that may occur and the
actions to be taken upon these critical failures.
7.1.6.9 "Self-Tests"
FPT_PBT_EXT.1
PP Origin: BIO
Explains how the TOE meets FPT_PBT_EXT.1 at high
level description.
Between the TSS and guidance, identify any TSFI
through which the user can access (e.g. revoke) the
templates and that those TSFI require the use of a
Non-Biometric Authentication Factor (NBAF).
7.1.5.3 "Biometric Authentication
Factors (BAFs)"
FPT_STM.1
PP Origin: 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.
7.1.6.7 "Time"
FPT_TST_EXT.1
PP Origin: MDF
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.
7.1.6.9 "Self-Tests"
FPT_TST_EXT.1/VPN
PP Origin: VPNC
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.
7.1.6.9 "Self-Tests" describes in
detail the self-tests that are run by
the TSF on start-up
Version: 1.1 Classification: Public Page 114 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
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.
FPT_TST_EXT.2/
PREKERNEL
FPT_TST_EXT.2/
POSTKERNEL
FPT_TST_EXT.3
PP Origin: 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.
7.1.6.1 "Secure Boot"
FPT_TST_EXT.3/WLAN
PP Origin: WLANC
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.
7.1.6.9 "Self-Tests"
FPT_TUD_EXT.1
PP Origin: MDF
There is no TSS assurance activity for this SFR.
Version: 1.1 Classification: Public Page 115 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FPT_TUD_EXT.2
PP Origin: 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.
7.1.6.3 "Secure Software Update"
FPT_TUD_EXT.3
PP Origin: MDF
Describes how mobile application software is
verified at installation and uses a digital signature.
7.1.6.9.4 "Application integrity"
FPT_TUD_EXT.4
PP Origin: MDF
See FPT_TUD_EXT.2.3 and FPT_TUD_EXT.4.1. See FPT_TUD_EXT.2.3 and
FPT_TUD_EXT.4.1.
FPT_TUD_EXT.5
PP Origin: MDF
Describes how mobile application software is
verified at installation using a digital signature by a
code signing certificate.
7.1.4.2 "X.509v3 Certificates"
FPT_TUD_EXT.6
PP Origin: MDF
Describes the mechanism that prevents the TSF
from installing software updates that are an older
version that the currently installed version.
7.1.6.3 "Secure Software Update"
FTA
FTA_SSL_EXT.1
PP Origin: MDF
Describes the actions performed upon transitioning
to the locked state.
Describes the information allowed to be displayed to
unauthorized users.
7.1.6.6 "Device Locking"
7.1.5.2 "Configuration Profiles"
7.1.2.1 "Overview of Key
Management"
FTA_TAB.1
PP Origin: MDF
Describes when the banner is displayed. 7.1.7.3 "Lock Screen/Access Banner
Display"
Version: 1.1 Classification: Public Page 116 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FTA_WSE_EXT.1
PP Origin: WLANC
Specifically defines all of the attributes that can
be used to specify acceptable networks (access
points).
7.1.7.2 "Restricting Access to
Wireless Networks"
FTP
FTP_BLT_EXT.1
PP Origin: BT
Describes the use of encryption, the specific
Bluetooth protocol(s) it applies to, and whether it is
enabled by default.
7.1.8.2 "Bluetooth"
FTP_BLT_EXT.2
PP Origin: BT
Describes the TSF's behavior if a remote device
stops encryption while connected to the TOE.
7.1.8.2 "Bluetooth"
FTP_BLT_EXT.3/BR
PP Origin: 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.
7.1.8.2 "Bluetooth"
FTP_BLT_EXT.3/LE
PP Origin: 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.
7.1.8.2 "Bluetooth"
FTP_ITC.1/WLAN
PP Origin: WLANC
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.
7.1.8.3 "Wireless LAN (WLAN)"
7.1.8.1 "EAP-TLS and TLS"
FTP_ITC_EXT.1
PP Origin: MDF, VPNC
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 29 "Protocols used for trusted
channels"
7.1.6.3 "Secure Software Update"
FTP_ITC_EXT.1(2)
PP Origin: 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.
7.1.4.2 "X.509v3 Certificates"
7.1.4.3 "MDM Server Reference ID"
Version: 1.1 Classification: Public Page 117 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR TSS Requirements from Assurance Activities TSS Section/Reference
FTP_TRP.1(2)
PP Origin: Agent
Specifies that for mobile device enrollment, the
mobile device initiates a connection over HTTPS to
the MDM server.
7.1.4.3 "MDM Server Reference ID"
7.1 TOE Security Functionality
7.1.1 Hardware Protection Functions
7.1.1.1 The Secure Enclave Processor (SEP)
The SEP, which is part of the Secure Enclave, is a coprocessor fabricated in all of the Apple processors listed
in Appendix A.1 "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 Secure Enclave includes a hardware random bit 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 Secure Enclave has its own physical noise source and random bit 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 7.1.2.2 "Password based key derivation".)
Other salt values used for functions in the TOE OS are generated using the TRNG in the Secure Enclave. 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.
Version: 1.1 Classification: Public Page 118 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.2 Cryptographic Support (FCS)
7.1.2.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-Rev1]☝ DRBG
(CTR_DRBG(AES)) of the Secure Enclave 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 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 Secure Enclave's TRNG (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 bit generator (DRBG)
(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 the TRNG to seed the CTR_DRBG.
The EMF key is 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 Secure Enclave 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 bit generator of the Secure Enclave (i.e., FCS_RBG_EXT.1/HW). 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 devices with an Apple ARM A14 and later SoC and M1 and later SoC,
the encryption uses AES-256 in XTS mode in the Secure Enclave. On Apple ARM A9 through A13 devices, the
encryption uses AES-128 in XTS mode in the Secure Enclave 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 [RFC3394]☝.
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.
Version: 1.1 Classification: Public Page 119 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 because 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-Rev3]☝). The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described
in 5.8.1 of [SP800-56A-Rev3]☝. 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. Because 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.
Version: 1.1 Classification: Public Page 120 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The keys for both file and Keychain Data Protection classes are collected and managed in keybags. The TOE
OS uses the following keybags: system (a.k.a. user and device keybags), backup, escrow, and iCloudBackup.
The keys are stored in the system keybag with some keys stored in the escrow keybag. The escrow keybag is
used for device update and by MDM, which are both relevant functions defined in [MDF]☝.
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 20 summarizes the storage for keys in persistent storage.
Table 20: Summary of keys and persistent secrets in the TOE OS
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 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
Version: 1.1 Classification: Public Page 121 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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
7.1.2.2 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).
Version: 1.1 Classification: Public Page 122 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The input to the PBKDF2 is the 128-bit random salt generated by the SEP (as described in Section 7.1.1.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 with a
minimum of 50,000 iterations. The number of iterations is device-specific and may be greater than 50,000 on
some devices.
7.1.2.3 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 Secure Enclave. The Secure Enclave is the Separate Execution
Environment (SEE). 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 Secure Enclave. The capture sensor and the SEE are isolated
from the device's main operating system in runtime.
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 7.1.2.1, the Secure Enclave preserves the
security of these keys.
7.1.2.4 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 21 summarizes the keys, authentication token, and persistent secrets stored for the MDM Agent. They
are used on all devices listed in this Security Target.
Table 21: Summary of keys and persistent secrets used by the MDM Agent
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
Version: 1.1 Classification: Public Page 123 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Key / Persistent
Secret
Purpose Storage
(for all devices)
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
Figure 5 provides an overview on the key management hierarchy implemented in the TOE OS.
Version: 1.1 Classification: Public Page 124 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Figure 5: Key Hierarchy in the TOE OS
The Data Protection API can be used by applications to define the class to which a new file belongs
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 7.1.1.1.
Version: 1.1 Classification: Public Page 125 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● All file system items and all keychain items are stored in encrypted form only.
● 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 their passphrase.
● All decryption errors are handled in compliance with [SP800-56B-Rev1]☝.
● 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 bit generator of the Secure
Enclave.
● 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 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.
Version: 1.1 Classification: Public Page 126 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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 v13.0 [Apple ARM, User, Software, SL1] and
Apple corecrypto Module v13.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.
7.1.2.5 Randomness extraction and expansion step
"Concatenating the keys and using a KDF (as described in SP800-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-Rev2]☝. This RFC exactly specifies the order
of the concatenation of the input data used for the extraction steps as well as the data concatenation and the
counter maintenance of the expansion phase.
Extraction:
HKDF-Extract(salt, IKM) -> PRK
Options:
Hash A hash function; HashLen denotes the length of the
hash function output in octets.
Inputs:
salt Optional salt value (a non-secret random value);
if not provided, it is set to a string of HashLen zeros.
IKM Input keying material.
Output:
PRK A pseudorandom key (of HashLen octets).
The output PRK is calculated as follows:
PRK = HMAC-Hash(salt, IKM)
Expansion:
HKDF-Expand(PRK, info, L) -> OKM
Options:
Hash A hash function; HashLen denotes the length of the
hash function output in octets.
Inputs:
PRK A pseudorandom key of at least HashLen octets
Version: 1.1 Classification: Public Page 127 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
(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.
7.1.2.6 Explanation of usage for cryptographic functions
Table 22 enumerates the various cryptographic functions specified in the SFRs and maps them to their modules.
The corecrypto modules are abbreviated as: User Space, Kernel Space, and SKS.
Table 22: Explanation of usage for cryptographic functions in the cryptographic modules
SFR Cryptographic
Function
Algorithm Modes/Notes Key/Curve
size
Module
ECDSA KeyGen and
KeyVer
[FIPS186-4]☝
(ECC scheme)
Notes: Used for TLS,
Bluetooth, and memory
encryption scheme.
P-256
P-384
Curve25519
User Space
Kernel Space
SKS
Diffie-Hellman Group
14
[RFC3526]☝
(FFC scheme)
Notes: Used for IPsec. MODP-2048 User Space
FCS_CKM.1
Asymmetric key
pair generation
Safe-primes
[SP800-56A-Rev3]☝
(FFC scheme)
Notes: Used for IPsec. MODP-2048
MODP-3072
User Space
Version: 1.1 Classification: Public Page 128 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Cryptographic
Function
Algorithm Modes/Notes Key/Curve
size
Module
FCS_CKM.1/VPN
Asymmetric key
pair generation
ECDSA KeyGen and
KeyVer
[FIPS186-4]☝
(ECC scheme)
Notes: Used for IPsec. P-256
P-384
User Space
RSA
[SP800-56B-Rev1]☝
Modulo:
2048
3072
4096
User Space
ECC Key
Establishment
(KAS-ECC-SSC)
[SP800-56A-Rev3]☝
Scheme: ephemeralUnified P-256
P-384
User Space
SKS
Diffie-Hellman Group
14
(FFC scheme)
[RFC3526]☝
Notes: Used for IPsec. MODP-2048 User Space
FCS_CKM.2/
UNLOCKED
Key establishment
FFC Key
Establishment
(KAS-FFC-SSC)
[SP800-56A-Rev3]☝
Scheme: dhEphem
Notes: Used for IPsec.
MODP-2048
MODP-3072
User Space
FCS_CKM.2/
LOCKED
Key establishment ECC Scheme
[RFC7748]☝
Curve25519 SKS
CCM, GCM
[SP800-38C]☝ (CCM),
[SP800-38D]☝ (GCM)
128-bit
256-bit
User Space
Kernel Space
SKS
CBC, XTS
[SP800-38A]☝ (CBC),
[SP800-38E]☝ (XTS)
128-bit
256-bit
User Space
Kernel Space
SKS
FCS_COP.1/
ENCRYPT
Symmetric
encryption/
decryption
AES
[FIPS197]☝
KW
[SP800-38F]☝ (KW)
128-bit
256-bit
User Space
Kernel Space
Version: 1.1 Classification: Public Page 129 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Cryptographic
Function
Algorithm Modes/Notes Key/Curve
size
Module
SKS
CBC
[SP800-38A]☝ (CBC)
encrypt only
128-bit
256-bit
SKS Hardware
CCMP
[SP800-38C]☝ (CCM)
128-bit
256-bit
Wi-Fi core/chip
GCMP
[SP800-38D]☝ (GCM)
256-bit Wi-Fi core/chip
FCS_COP.1/HASH
Hashing SHS
[FIPS180-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).
User Space
Kernel Space
SKS
RSA SigGen
[FIPS186-4]☝
Using
SHA-256
SHA-384
SHA-512
Modulo:
2048
3072
4096
User Space
Kernel Space
RSA SigVer
[FIPS186-4]☝
Using
SHA-1
SHA-256
SHA-384
SHA-512
Modulo:
2048
3072
4096
User Space
Kernel Space
ECDSA SigGen
[FIPS186-4]☝
Using
SHA-256
SHA-384
SHA-512
P-256
P-384
P-521
User Space
Kernel Space
SKS
FCS_COP.1/SIGN
Digital signature
generation;
Digital signature
verification
ECDSA SigVer
[FIPS186-4]☝
Using
SHA-1
SHA-256
SHA-384
SHA-512
P-256
P-384
P-521
User Space
Kernel Space
SKS
Version: 1.1 Classification: Public Page 130 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Cryptographic
Function
Algorithm Modes/Notes Key/Curve
size
Module
HMAC-SHA-1
Block size: 512
Output MAC: 160
Greater than or
equal to 112 bits
User Space
Kernel Space
SKS
HMAC-SHA-256
Block size: 512
Output MAC: 256
Greater than or
equal to 112 bits
User Space
Kernel Space
SKS
HMAC-SHA-384
Block size: 1024
Output MAC: 384
Greater than or
equal to 112 bits
User Space
Kernel Space
SKS
FCS_COP.1/
KEYHMAC
Keyed-hash HMAC
[FIPS198-1]☝
HMAC-SHA-512
Block size: 1024
Output MAC: 512
Greater than or
equal to 112 bits
User Space
Kernel Space
SKS
FCS_COP.1/
CONDITION
Salted HMAC-SHA
and PBKDF2
HMAC-SHA-256 HMAC-SHA-256
Block size: 512
Output MAC: 256
Greater than or
equal to 112 bits
User Space
Kernel Space
SKS
FCS_RBG_EXT.1/HW
Random bit
generation;
Symmetric key
generation
CTR_DRBG(AES)
[SP800-90A-Rev1]☝
AES-256 SKS Hardware
FCS_RBG_EXT.1/SW
Random bit
generation;
Symmetric key
generation
CTR_DRBG(AES)
[SP800-90A-Rev1]☝
AES-256 User Space
Kernel Space
7.1.3 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 Section 7.1.3.1 and Section 7.1.3.2. These are applicable to all applications
on the TOE that are all allowed access to these two System Services.
A further set of high-level system services is presented to applications and monitored by the TOE OS allowing
users to grant access to these services, or not.
Version: 1.1 Classification: Public Page 131 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.3.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 that 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 always be accessed. 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 passcode. If the user has not defined
a passcode, 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.
7.1.3.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 multiple 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 multiple directories that the app can use to sort and
organize its data. The app may also request access to additional containers—for example, the iCloud container
—at runtime.
When a built-in 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.
7.1.3.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.
Version: 1.1 Classification: Public Page 132 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.3.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
7.1.3.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 & Security interface:
● Location Services
● Tracking
● Contacts
● Calendars
● Reminders
● Photos
● Bluetooth
● Local Network
● Nearby Interactions
● Microphone
● Speech Recognition
● Camera
● Health
● Research Sensor & Usage Data
● HomeKit
● Media & Apple Music
● Files and Folders
● Motion & Fitness
● Focus
● Safety Check
● Analytics & Improvements
Version: 1.1 Classification: Public Page 133 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Apple Advertising
● App Privacy Report
● Lockdown Mode
7.1.3.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 23 shows the Keychain classes and their equivalent file system classes.
Table 23: Keychain to File-system Mapping
Keychain data protection
class
File data protection class
When unlocked NSFileProtectionComplete
While locked NSFileProtectionCompleteUnlessOpen
After first unlock NSFileProtectionCompleteUntilFirstUserAuthentication
Always NSFileProtectionNone
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.
Keychains can use access control lists (ACLs) to set policies for accessibility and authentication requirements.
Items can establish conditions that require user presence by specifying that they cannot be accessed unless
authenticated by entering the device's passcode. 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.2.5.
7.1.3.7 VPN
VPN packet processing is handled by the TOE.
Version: 1.1 Classification: Public Page 134 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Because all the TSF binaries and libraries are protected from stack-based buffer overflow (see Section 7.1.6.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.
7.1.3.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.
7.1.4 Identification and Authentication (FIA)
The user must authenticate using a passcode or a biometric (face or fingerprint) to use the device except when
performing the following:
● Accessing Medical ID information
● Answering calls
● Making emergency calls
● Using the cameras (unless their use is generally disallowed)
● Using the control center
● Using the flashlight
● Using the notification center
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.
TOE devices support either Face ID (face) or Touch ID (fingerprint) BAFs. Historically, there are multiple
generations of these BAFs as improvements were made over time. Appendix A.1 provides the BAF and BAF
generation for each TOE device.
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.
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.
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)
Version: 1.1 Classification: Public Page 135 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 7.1.5.
Devices that support Touch ID do not support Face ID and vice versa. The passcode and the device's BAF cannot
be combined for two-factor authentication.
In addition, the following behavior applies to BAFs. 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. Face ID and Touch ID use a separate failed attempt counter from the passcode counter that is not
maintained over a power loss or reboot (i.e., the Face ID and Touch 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 5-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 unlock counter to increment
only once for those multiple attempts even though these are all passcode failed unlock attempts. Different
passcodes must be entered in order for the passcode failed unlock counter to increment. (This description only
applies to the passcode failed unlock 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.
7.1.4.1 Biometric Authentication
7.1.4.1.1 Accuracy of Biometric Authentication
Touch ID
Performance assessment of Touch ID verification is conducted in the form of an offline 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.
Version: 1.1 Classification: Public Page 136 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The False Acceptance Rate (FAR) test protocols differ between sensor generations as follows:
● For Gen.1 (generation 1) and Gen.4 (generation 4), a full cross-comparison scheme is used. Each
user is enrolled and each template is attacked by all other user data.
● For Gen.3(generation 3), a partial cross-comparison is done. In this scheme, the test population is
split between users and impostors. Users are enrolled and each template is attacked by all impostor
data.
Gen.2 (generation 2) is not used on the TOE devices.
Face ID
Performance assessment is designed to cover representative Face ID usage cases (e.g., variation of
environment, unlock poses and distance, accessory changes) across a representative age, gender and ethnicity
distribution.
Data collection for the assessment is submitted to the following controls:
● Check the number of actions in each visit to ensure diversity of actions completed by each
participant
● Image quality assessment
● Score distribution plots from Face ID modules to ensure that scores are in the expected range and
data is of high quality.
● Image visualization to remove subjects with identity contamination from evaluation
iPhone 12 and later allow for facial recognition of a user wearing a mask. This feature is known as the "Face ID
with a Mask" setting. For devices that support the "Face ID with a Mask" setting, this setting must be disabled
in the evaluated configuration.
7.1.4.1.2 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 criteria:
For Touch ID:
● Finger motion
● Sensor coverage
● Fixed pattern noise (FPN)
For Face ID:
● Pose: Pose angles
● Distance: Within a specific range
● Occlusion: Visible face region
● Attention: Subject must be looking at the device
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.
Version: 1.1 Classification: Public Page 137 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Additionally, the biometric system is tested by feeding artificially created images containing different geometric
patterns.
7.1.4.2 X.509v3 Certificates
There are multiple 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 email 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 website.
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 [MDF]☝. 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
● AppleIPsec
● AppleCodeSigning
● AppleIDValidation
● AppleTimeStamping
External entities can be authenticated using a digital certificate. Out of the box, the TOE includes multiple
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
Version: 1.1 Classification: Public Page 138 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Downloaded from a website
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 [RFC5280]☝. 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.
The certificate chain searches for the certificates in the TOE's 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. The trust
store stores and protects certificates from unauthorized deletion and modifications. Authorized administrators
can load certificates into the trust store. 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.
7.1.4.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 Device 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)1
. 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
1 More information about SCEP can be found [RFC8894]☝.
Version: 1.1 Classification: Public Page 139 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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 24.
Table 24: MDM Server Reference Identifiers
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
7.1.5 Specification of Management Functions (FMT)
Since all the mobile devices specified in this Security Target 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 15, Table 16, and Table 17 describe the management functions of the devices as well as the MDM Agent
that are available when the device is enrolled in MDM.
7.1.5.1 Device Enrollment
The methods by which an MDM Agent can be enrolled in to MDM are as follows:2
● Manually, using Apple's Profile Manager
● Manually, using Apple Configurator 2
● Distributing an enrollment profile via email or a website
● Apple Business Manager (This is an automated and enforced method of automatically enrolling new
devices.)
A more detailed description is found in Section 7.1.4.3. In addition, the enrollment process is discussed in
[DeployRef]☝.
The MDM server provides the agent with an MDM certificate. This certificate is used as the authentication
token by the MDM agent. Similarly, the Apple Configurator 2 installs a certificate when the device allows Apple
Configurator 2 to manage it. This certificate is also used as the authentication token.
2 Lockdown Mode prevents the installation of Configuration Profiles and the enrollment in MDM and device supervision.
Version: 1.1 Classification: Public Page 140 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.5.2 Configuration Profiles
The TOE can be configured using Configuration Profiles3
that are installed on the TOE. Configuration Profiles are
XML files that may contain settings for multiple 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.
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:
❍ Via an email message
❍ Via a webpage
❍ 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 Security Target that have to be configured using Configuration Profiles are as
follows:
● The password policy—the administrator can define this using the Passcode Payload and:
❍ Define the minimum password length
❍ Define requirements for the password complexity
❍ Define the maximum password lifetime
3 Lockdown Mode prevents the installation of Configuration Profiles and the enrollment in MDM and device supervision.
Version: 1.1 Classification: Public Page 141 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
❍ Define the maximum time of inactivity after which the device is locked automatically
❍ Define the maximum number of consecutive authentication failures after which the device
is wiped
● The VPN policy as follows:
❍ Specify that VPN is always on
❍ Define the authentication method (certificate)
❍ Specification of certificates or shared keys
● The Wi-Fi policy as follows:
❍ The EAP types allowed including security type and authentication protocol (WL-1)
❍ CAs from which to accept WLAN authentication server certificates (WL-1)
❍ Client credentials to be used for authentication (WL-1)
❍ The service set identifiers (SSIDs) allowed to connect to (WL-2)
❍ The encryption type(s) allowed
❍ Enabling/disabling Wi-Fi hotspot functionality (WL-3)
❍ Disabling ad hoc wireless client-to-client connections a.k.a. AirDrop (WL-5))
❍ Disable roaming capability (WL-6)
❍ Loading X.509 certificates into the TOE (WL-8)
❍ Revoking X.509 certificates loaded into the TOE (WL-9)
● General restrictions as follows:
❍ Allowing or disallowing specific services (e.g., remote backup) or using devices like the
cameras
❍ Allowing or disallowing notifications when locked
❍ Allowing or disallowing a prompt when an untrusted certificate is presented in a TLS/
HTTPS connection
❍ 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
● 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
Version: 1.1 Classification: Public Page 142 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● The ability to pair with a host other than the supervision host
● The ability for the user to install Configuration Profiles or certificates interactively
● 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 [iPhone_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 15, Table 16, and Table
17. 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.
7.1.5.3 Biometric Authentication Factors (BAFs)
The enrollment and management of biometric authentication factors and credentials is detailed in [iPhone_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 the
finger is mapped to. 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 following 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 following 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 enrollment 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.
The biometric templates are protected by the passcode. To remove a biometric template or create a new
enrollment authentication template, the user must first supply a valid passcode. This can be performed using
the Settings » Face ID & Passcode for Face ID and the Settings » Touch ID & Passcode for Touch ID.
7.1.5.4 Device Unenrollment
The TOE supports both preventing device unenrollment from an MDM server from occurring as well as applying
remediation actions when a device is unenrolled.
Version: 1.1 Classification: Public Page 143 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
[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 of 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.
7.1.5.5 Radios
The following radios are found in the TOE:
● Bluetooth
● Cellular
● Near Field Communication (NFC)
● Satellite (Not supported by all devices. See Appendix A.1.)
Version: 1.1 Classification: Public Page 144 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Ultra-Wideband (UWB) (Not supported by all devices. See Appendix A.1.)
● Wi-Fi
These are more fully described, including the frequencies employed, in Appendix A.1 "Devices Covered by this
Evaluation".
As indicated in Table 15, 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 unlocks 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 unlocked the device. Communication requiring no
credentials such as unprotected Wi-Fi may commence before the user unlocks the device 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).
7.1.5.6 Audio and Visual collection devices
The following audio and visual collection devices are found in the TOE:
● Cameras
● Microphones
Table 15 describes the roles that can enable/disable them.
7.1.5.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.
7.1.5.8 Removal of applications
The following table indicates which application types can be removed along with the role that can remove them.
Table 25: Removal of applications
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
7.1.6 Protection of the TSF (FPT)
7.1.6.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.
Version: 1.1 Classification: Public Page 145 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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.
A failure of the Boot ROM to load iBoot results in the device entering DFU mode. In the case of a failure in 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 an Apple ARM A10 SoC and later as well as an Apple
ARM M1 SoC and later
● DFU Mode: Set by Boot ROM on devices with an Apple ARM A12 SoC and later as well as an Apple
ARM M1 SoC and later
7.1.6.2 Joint Test Action Group (JTAG) Disablement
The TOE devices 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 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.
7.1.6.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.
Version: 1.1 Classification: Public Page 146 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The startup process, described in Section 7.1.6.1 "Secure Boot" 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 7.1.6.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, 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.
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.
7.1.6.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/
Version: 1.1 Classification: Public Page 147 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.6.5 Domain Isolation
When a TOE device with cellular capabilities (i.e., a dialer) is in the lock state, only the Emergency Call dialer
(Emergency SOS) 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
● 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 Secure Enclave's 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.
7.1.6.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.
Version: 1.1 Classification: Public Page 148 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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.
7.1.6.7 Time
The following security functional requirements make use of time (FPT_STM.1):
● FAU_GEN.1.2 and similar SFRs (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)
● FMT_SMF.1 Function 1 (Password lifetime)
● FMT_SMF.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.
7.1.6.8 Inventory of TSF Binaries and Libraries
The inventory of TSF binaries and libraries is provided in Appendix A.4 "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.
7.1.6.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 because 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.
7.1.6.9.1 Apple corecrypto Module v13.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.
Version: 1.1 Classification: Public Page 149 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The execution of an independent application for invoking the self-tests in the libcorecrypto.dylib library makes
use of features of the TOE OS architecture: the module, implemented in libcorecrypto.dylib, is linked by the
libcommoncrypto.dylib library, which is linked by the libSystem.dylib library. 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 applications linking to that library. In this way, the module always stays in memory.
Therefore, the self-test during startup time is sufficient as it tests the module instance loaded in memory, which
is subsequently used by every application on 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 v13.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, then the device powers itself off. To rerun the self-tests on demand, the user must
reboot the device. If the following tests succeed, then the device continues with its normal power-up process.
Cryptographic Algorithm Tests
Table 26: 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
SigGen, SigVer Pair-wise consistency checks
RSA 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
Software/Firmware Integrity Tests
A software integrity test is performed on the runtime image of the Apple corecrypto Module v13.0 [Apple ARM,
User, Software, SL1]. 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, then 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 v13.0 [Apple ARM,
User, Software, SL1]:
Version: 1.1 Classification: Public Page 150 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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-
Rev1]☝; 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.
7.1.6.9.2 Apple corecrypto Module v13.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, then 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 v13.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 fail, then the device shuts down automatically. To run the self-tests on demand, the user may
reboot the device. If the followings tests succeed, then the device continues with its normal power-up process.
Cryptographic Algorithm Tests
Table 27: 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
Software/Firmware Integrity Tests
A software integrity test is performed on the runtime image of the Apple corecrypto Module v13.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, then the device continues with its normal
power-up process.
Critical Function Tests
No other critical function test is performed on power up.
Version: 1.1 Classification: Public Page 151 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Conditional Tests
The following items describe the conditional tests supported by the Apple corecrypto Module v13.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-
Rev1]☝; 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.
7.1.6.9.3 Apple corecrypto Module v13.0 [Apple ARM, Secure Key Store, Hardware, SL2]
[FIPS140-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 fail, then the device powers itself off.
To rerun the self-tests on demand, the user must reboot the device. If the followings tests succeed, then the
device continues with its normal power-up process.
Cryptographic Algorithm Tests
Table 28: Cryptographic Algorithm Tests
Algorithm Modes Test
AES Implementation selected by the module for the
corresponding environment
AES-128
ECB, CBC KAT4
Separate encryption/decryption
operations are performed
AES SKG Hardware Accelerator Implementation
AES-256
ECB KAT
Separate encryption/decryption
operations are performed
4 Self-test is subject to the "selector" approach for the different implementations of AES.
Version: 1.1 Classification: Public Page 152 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Algorithm Modes Test
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 KAT5
ECDSA SigGen,
SigVer
PCT
EC Diffie-Hellman "Z" computation N/A KAT
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, then 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 v13.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
The module performs a subset of the assurance tests as specified in section 11 of [SP800-90A-
Rev1]☝; 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.
7.1.6.9.4 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.
7.1.7 TOE Access (FTA)
7.1.7.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.
5 Self-test is subject to the "selector" approach for the different implementations of SHA.
Version: 1.1 Classification: Public Page 153 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Displaying notifications when in the locked state can be prohibited via the allowLockScreenNotificationsView
key in the Restrictions Payload of a Configuration Profile.
7.1.7.2 Restricting Access to Wireless Networks
Users and administrators can restrict the wireless networks to which a TOE device connects. Using the
Configuration Profile, administrators can define the wireless networks to which the device is allowed to connect
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 Appendix A.1 "Devices Covered by this Evaluation". The
standards listed there define the frequency ranges.
7.1.7.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.1 Function 36.
Because 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.
7.1.8 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 29.
Table 29: Protocols used for trusted channels
Protocol ST requirements Used for
802.11ax
802.11ac-2013
In addition to the minimum trusted
channel requirements and supported by
FCS_COP.1.
Wireless access points
802.11-2012 FTP_ITC_EXT.1
FTP_ITC.1/WLAN
Wireless access points
802.1X FTP_ITC_EXT.1
FTP_ITC.1/WLAN
WLAN
EAP-TLS FTP_ITC_EXT.1
FTP_ITC.1/WLAN
WLAN
TLS 1.1 FCS_TLSC_EXT.1/WLAN Secure data transfer
TLS 1.2 FCS_TLSC_EXT.1
FCS_TLSC_EXT.1/WLAN
FDP_UPC_EXT.1/APPS
Secure data transfer
IPsec FCS_IPSEC_EXT.1
FTP_ITC_EXT.1
VPN
Version: 1.1 Classification: Public Page 154 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Protocol ST requirements Used for
Bluetooth (v5.0,
v5.3) with BR/
EDR and LE
FDP_UPC_EXT.1/BLUETOOTH Trusted IT products
HTTPS FCS_HTTPS_EXT.1
FDP_UPC_EXT.1/APPS
FTP_ITC_EXT.1
FTP_ITC_EXT.1(2)
FTP_TRP.1(2)
OTA updates;
secure communication over a
network
IPsec supports authentication using shared keys or certificate-based authentication. The TOE's TLS client
supports certificate-based mutual authentication.
7.1.8.1 EAP-TLS and TLS
For Wi-Fi, the TOE supports EAP-TLS using TLS v1.1 and v1.2 and supports the following ciphersuites:
● TLS_RSA_WITH_AES_128_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
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) or Wi-Fi Protected
Access 3 (WPA3) 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 the following ciphersuites from FCS_TLSC_EXT.1:
● TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● 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
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_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)
Version: 1.1 Classification: Public Page 155 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
The additional supported elliptic curve extension below is also always enabled by the TOE OS:
● Curve25519
The TOE OS supports RSA [SP800-56B-Rev1]☝ 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).
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.
7.1.8.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.
7.1.8.1.2 TLS client renegotiation
The TOE supports TLS client secure renegotiation through the use of the "renegotiation_info" TLS extension in
accordance with [RFC5746]☝.
7.1.8.2 Bluetooth
The TOE supports Bluetooth (v5.0, v5.3) 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)
● Audio/Video Remote Control Profile (AVRCP 1.4)
Version: 1.1 Classification: Public Page 156 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Personal Area Network Profile (PAN)
● Human Interface Device Profile (HID)
● Message Access Profile (MAP)
By default, Bluetooth is enabled. The supported Bluetooth version depends on the device. For the mapping of
devices to Bluetooth versions, see Appendix A.1 "Devices Covered by this Evaluation".
Users can pair their TOE 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 TOE's device list. Explicit user authorization
is required for both pairing and removing a Bluetooth device from the TOE's device list.
Manual authorization is implicitly configured since pairing can only occur when explicitly authorized through
the Settings » Bluetooth interface. During the pairing time, another device (or the 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 and authorized and thus can communicate with and a device to which
the TOE is connected but not yet authorized 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 manually 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 the TOE OS to use Secure Simple Pairing, which uses ECDH-based
authentication and key exchange with curve P-256. See the Bluetooth Specifications [BT_SPEC]☝ for details.
The TOE generates a new ephemeral ECDH key pair for every new connection attempt. The ECDH keys are
generated in user space using the corecrypto user space module. 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.
The Wi-Fi chip performs the bulk Bluetooth AES-CCM-128 cryptography. 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.
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_SPEC]☝.
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.
A service ID is used to identify the local service.
Version: 1.1 Classification: Public Page 157 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.8.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/SW).
The Wi-Fi Alliance certificates for the devices in this evaluation are in Appendix A.2 "Wi-Fi Alliance Certificates".
7.1.8.4 VPN
7.1.8.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 (AirPrint, cellular services, voicemail)
● The definition of exceptions for Captive networking (if any)
The TOE supports separate configurations for cellular and Wi-Fi.
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):
Version: 1.1 Classification: Public Page 158 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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.)
7.1.8.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.2 "TOE Architecture".
The TOE implements the IPsec protocol as specified in [RFC4301]☝. 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 AirPrint, cellular
services, voicemail, and applications that make use of Captive Networking Identifiers. 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 7.1.5.2 "Configuration
Profiles" for more information.
All data, other than that described in Section 7.1.8.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.
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 (see
FMT_SMF.1 Function 3 enable/disable the VPN protection).
The TOE OS is responsible for each type of VPN auditable event.
7.1.8.4.3 IPsec Characteristics
The TOE platform supports the following IPsec connection characteristics:
● IKEv2 (as defined in RFCs 7296 and 4307)
Version: 1.1 Classification: Public Page 159 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● 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):
❍ DH Group 14 (2048-bit MODP)
❍ DH Group 15 (3072-bit MODP)
❍ DH Group 19 (256-bit Random ECP)
❍ DH Group 20 (384-bit Random ECP)
Each of these cryptographic mechanisms is provided by one of the following two cryptographic modules: Apple
corecrypto Module v13.0 [Apple ARM, User, Software, SL1] or Apple corecrypto Module v13.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-Rev3]☝, ECDSA key generation algorithm in [FIPS186-4]☝, Diffie-Hellman
Group (MODP) key generation [RFC 3526], and IKEv2 key derivation function in [RFC5996]☝.
7.1.8.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 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 session will not be established.
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.
7.1.8.4.5 IKE
The TOE (and product) 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's software DRBG (as specified in FCS_RBG_EXT.1/SW). 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.
Version: 1.1 Classification: Public Page 160 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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]☝.
7.1.8.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.
7.1.9 Security Audit (FAU)
7.1.9.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 7.1.5.2 "Configuration Profiles". These profiles
must also be used to determine the audit storage capacity as well as default action when capacity is reached.
Although the specific audit record format is determined via Configuration Profile, the following attributes form
the baseline:
● Date and time the audit record was generated
● Process ID or information about the cause of the event
● Information about the intended operation
● Success or failure (where appropriate)
Audit record information is not available to TOE users or administrators on TOE devices and is only accessible
externally on trusted workstations via the Apple Configurator 2 or to an MDM server on enrolled devices.
Depending on the underlying OS of the trusted workstation or MDM server, the audit records are transferred
to the following locations:
● macOS
❍ ~/Library/Logs/CrashReporter/MobileDevice/[Your_Device_Name]/
● Windows
❍ C:\Users\[Your_User_Name]\AppData\Roaming\Apple Computer\Logs\CrashReporter
\MobileDevice\[Your_Device_Name]\
7.1.9.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 30 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.
Table 30: MDM Agent Status Commands
Key Type Content
Status String Status. Legal values are described as:
Version: 1.1 Classification: Public Page 161 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Key Type Content
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 Unique Device ID (UDID) of the device
CommandUUID String Universally Unique ID (UUID) of the command that this response is
for (if any)
ErrorChain Array Optional—Array of dictionaries representing the chain of errors that
occurred
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 (Device Push 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 Push Token may change. When a change is detected, the device automatically
checks in with the MDM Server to report its new push notification token (Device Push 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.
Version: 1.1 Classification: Public Page 162 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
When an MDM Server wants to communicate with a TOE device, a silent notification is sent to the TOE's 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.
7.1.9.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 regarding the successful installation of policies is queued until the device is able
to communicate with the server again. The queue cannot become long because if the device is out of
communication with the MDM Server, no additional requests can be received. If the MDM Server does not receive
the alert, the MDM Server should re-initiate the transfer until a response is received from the device.
There are certain times when the device is not able to do what the MDM Server requests. For example, databases
cannot be modified while the device is locked with Data Protection. When a device cannot perform a command
due to these types of situations, it will send the NotNow status without performing the command. The server
may send another command immediately after receiving this status but chances are the following command will
also be refused.
After sending a NotNow status, the device will poll the server at some future time. The device will continue to
poll the server until a successful transaction is completed.
The device does not cache the command that was refused. If the server wants the device to retry the command,
it must send the same command again later, when the device polls the server.
The server does not need to send another push notification in response to this status. However, the server may
send another push notification to the device to have it poll the server immediately.
The following commands are guaranteed to execute on the TOE OS and never return NotNow:
● DeviceInformation
● ProfileList
● DeviceLock
● EraseDevice
● ClearPasscode
● CertificateList
● ProvisioningProfileList
● InstalledApplicationList
● Restrictions
7.1.9.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 7.1.5.2 "Configuration Profiles".
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".
Version: 1.1 Classification: Public Page 163 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
7.1.9.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 7.1.9.1
"Audit Records," above.
Version: 1.1 Classification: Public Page 164 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
8 Abbreviations, Terminology, and References
8.1 Abbreviations
A2DP
Advanced Audio Distribution Profile
ABM
Apple Business Manager
ACL
Access Control List
AES
Advanced Encryption Standard
APFS
Apple File System
API
Application Programming 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 Factor
BMD
Biometric Management Design
BR/EDR
Basic Rate/Enhanced Data Rate
CAVP
Cryptographic Algorithm Validation Program
CBC
Cipher Block Chaining
CC
Common Criteria
Version: 1.1 Classification: Public Page 165 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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
DN
Distinguished Name
DNS
Domain Name Server
DRBG
Deterministic Random Bit Generator
DSA
Digital Signature Algorithm
Version: 1.1 Classification: Public Page 166 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
DNS
Domain Name System
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
EST
Enrollment over Secure Transport
EV-DO
Evolution-Data Optimized
FAR
False Acceptance Rate
FDD-LTE
Frequency-Division Duplex-Long Term Evolution
FIA
False Acceptance Rate
Version: 1.1 Classification: Public Page 167 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
FIPS
Federal Information Processing Standard
FPN
Fixed Pattern Noise
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
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
Version: 1.1 Classification: Public Page 168 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
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
ltc
LibTomCrypt
LTE
Long Term Evolution
MAC
Message Authentication Code
MAP
Message Access Profile
MD
Mobile Device
MDFPP
Mobile Device Fundamentals Protection Profile
MDM
Mobile Device Management
Version: 1.1 Classification: Public Page 169 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
MMI
Man-Machine Interface
MMU
Memory Management Unit
NDRNG
Non-deterministic Random Number Generator
neon
ARM NEON instructions
NFC
Near-Field Communication
NITZ
Network, Identity and Time Zone
NTP
Network Time Protocol
OCSP
Online Certificate Status Protocol
OSP
Organizational Security Policy
OTA
Over-the-Air
OTP-ROM
One Time Programmable Read-Only Memory
PAA
Processor Algorithm Accelerator
PAD
Presentation Attack Detection
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
Version: 1.1 Classification: Public Page 170 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
PMK
Pairwise Master Key
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
SAN
Subject Alternative Name
SAR
Security Assurance Requirement
SAT
Satellite radio
SCDMA
Synchronous Code Division Multiple Access
SCEP
Simple Certificate Enrollment Protocol
SDIO
Secure Digital Input Output
Version: 1.1 Classification: Public Page 171 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SEE
Separate Execution Environment
SEP
Secure Enclave Processor
SFR
Security Functional Requirement
SHA
Secure Hash Algorithm
SHS
Secure Hash Standard
SigGen
Signature Generation
SigVer
Signature Verification
skg
Secure Key Generation
SKS
Secure Key Store
SiP
System-in-Package
SoC
System on a Chip
SP
Security Policy
SP
Special Publication
SPD
Security Policy Database
SSID
Service Set Identifier
SSL
Secure Sockets Layer
ST
Security Target
TD
Technical Decision
TD-LTE
Time Division Long-Term Evolution
TD-SCDMA
Time Division Synchronous Code Division Multiple Access
Version: 1.1 Classification: Public Page 172 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
TLS
Transport Layer Security
TOE
Target of Evaluation
TRNG
True Random Number Generator
TSF
TOE Security Functionality
TSS
TOE Summary Specification
UDID
Unique Device Identifier
UI
User Interface
UMTS
Universal Mobile Telecommunications System
USSD
Unstructured Supplementary Service Data
UID
Unique Identifier
UUID
Universally Unique Identifier
UWB
Ultra-Wideband
vng
Vector Next Generation
VPN
Virtual Private Network
VPP
Volume Purchase Program
WLAN
Wireless Local Area Network
WPA2
Wi-Fi Protected Access 2
WPA3
Wi-Fi Protected Access 3
XN
Execute Never
XEX
Xor-Encrypt-Xor
Version: 1.1 Classification: Public Page 173 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
XTS
XEX-based tweaked-codebook mode with ciphertext stealing
8.2 References
Apple Business Manager User Guide
Date 2022-04-27
ABM_Guide
Location https://support.apple.com/guide/apple-business-manager/welcome/w
eb
Apple Configurator 2 User Guide
Date 2022
AConfig
Location https://support.apple.com/guide/apple-configurator-2/welcome/mac
PP-Module for MDM Agents
Version 1.0 (MOD_MDM_AGENT_V1.0)
Date 2019-04-25
Agent
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=441&id=441
Apple Platform Security
Date 2022-05
AP_SEC
Location https://help.apple.com/pdf/security/en_US/apple-platform-security-gu
ide.pdf
About Apple File System
Date 2022
APFS_DEV_DOC
Location https://developer.apple.com/documentation/foundation/file_system/ab
out_apple_file_system
File system formats available in Disk Utility on Mac
Date 2022
APFS_DOC
Location https://support.apple.com/guide/disk-utility/dsku19ed921c/21.0/mac/1
2.0
PP-Module: collaborative PP-Module for Biometric enrolment and verification
- for unlocking the device - [BIOPP-Module]
Version 1.1 (MOD_CPP_BIO_V1.1)
Date 2022-09-12
BIO
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=476&id=476
Pair a third-party Bluetooth accessory with your iPhone, iPad,or iPod touch
Date 2021-11-19
BLUETOOTH_HELP
Location https://support.apple.com/en-us/HT204091
PP-Module for Bluetooth
Version 1.0 (MOD_BT_V1.0)
Date 2021-04-15
BT
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=425&id=425
Bluetooth Specifications
Author(s) Bluetooth SIG, Inc.
BT_SPEC
Date 2021-07-13
Version: 1.1 Classification: Public Page 174 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Location https://www.bluetooth.com/specifications/
Common Criteria for Information Technology Security Evaluation
Version 3.1R5
Date April 2017
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R5.pdf
CC
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf
Apple iOS 16: iPhones and Apple iPadOS 16: iPads Common Criteria
Configuration Guide
Date 2023
CCGUIDE
Location https://www.niap-ccevs.org/MMO/Product/st_vidnnnnn-agd.pdf
Identity Pinning: How to configure server certificates for your app
Date 2021-01-14
CertPinning
Location https://developer.apple.com/news/?id=g9ejcf8y
Certificate, Key, and Trust Services
Date 2022
CKTSREF
Location https://developer.apple.com/documentation/security/certificate_key_an
d_trust_services
Set up content caching on Mac
Date 2022
CONTENT-CACHING
Location https://support.apple.com/guide/mac-help/set-up-content-caching-on
-mac-mchl3b6c3720/12.0/mac/12.0
Apple Platform Deployment
Date 2022-06
DeployRef
Location https://support.apple.com/guide/deployment/welcome/web
Device Management
Date 2022
DEV_MAN
Location https://developer.apple.com/documentation/devicemanagement
Security Requirements for Cryptographic Modules
Date 2019-03-22
FIPS140-3
Location https://csrc.nist.gov/pubs/fips/140-3/final
Secure Hash Standard (SHS)
Date 2015-08-04
FIPS180-4
Location https://csrc.nist.gov/pubs/fips/180-4/upd1/final
Digital Signature Standard (DSS)
Date 2013-07-19
FIPS186-4
Location https://csrc.nist.gov/pubs/fips/186-4/final
Advanced Encryption Standard (AES)
FIPS197
Date 2023-05-09
Version: 1.1 Classification: Public Page 175 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Location https://csrc.nist.gov/pubs/fips/197/final
The Keyed-Hash Message Authentication Code (HMAC)
Date 2008-07-16
FIPS198-1
Location https://csrc.nist.gov/pubs/fips/198-1/final
iPhone User Guide iOS 16 (latest)
Version iOS 16
Date 2022
iPhone_UG
Location https://support.apple.com/guide/iphone/welcome/ios
Keychain Services (Programming Guide)
Date 2022
KEYCHAINPG
Location https://developer.apple.com/documentation/security/keychain_services
Logging
Date 2022
LOGGING
Location https://developer.apple.com/documentation/os/logging?language=objc
Change or remove the payment cards that you use with Apple Pay
Date 2021-12-16
MANAGE_CARDS
Location https://support.apple.com/en-us/HT205583
Base-PP: Protection Profile for Mobile Device Fundamentals
Version 3.3 (PP_MDF_V3.3)
Date 2022-09-12
MDF
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=468&id=468
Use a passcode with your iPhone, iPad or iPod touch
Date 2022-03-28
PASSCODE-Help
Location https://support.apple.com/en-us/HT204060
Set up Apple Pay
Date 2022-03-18
PAY_SETUP
Location https://support.apple.com/en-us/HT204506
Profile Manager User Guide for macOS Monterey
Date 2022
PM_Help
Location https://support.apple.com/guide/profile-manager/welcome/mac
PP-Configuration for Mobile Device Fundamentals, Biometric enrollment
and verification – for unlocking the device, Bluetooth, MDM Agents, Virtual
Private Network (VPN) Clients, and WLAN Clients
Version 1.0 (CFG_MDF-BIO-BT-MDMA-VPNC-WLANC_V1.0)
Date 2022-10-11
PP-Config
Location https://www.niap-ccevs.org/MMO/PP/CFG_MDF-BIO-BT-MDMA-VPN
C-WLANC_V1.0.pdf
Profiles and Logs
Date 2022
PROFS_LOGS
Location https://developer.apple.com/bug-reporting/profiles-and-logs/?platform
=ios
Version: 1.1 Classification: Public Page 176 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Advanced Encryption Standard (AES) Key Wrap Algorithm
Author(s) J. Schaad, R. Housley
Date 2002-09-01
RFC3394
Location http://www.ietf.org/rfc/rfc3394.txt
More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)
Author(s) T. Kivinen, M. Kojo
Date 2003-05-01
RFC3526
Location http://www.ietf.org/rfc/rfc3526.txt
Security Architecture for the Internet Protocol
Author(s) S. Kent, K. Seo
Date 2005-12-01
RFC4301
Location http://www.ietf.org/rfc/rfc4301.txt
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
Author(s) D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Date 2008-05-01
RFC5280
Location http://www.ietf.org/rfc/rfc5280.txt
Transport Layer Security (TLS) Renegotiation Indication Extension
Author(s) E. Rescorla, M. Ray, S. Dispensa, N. Oskov
Date 2010-02-01
RFC5746
Location http://www.ietf.org/rfc/rfc5746.txt
Internet Key Exchange Protocol Version 2 (IKEv2)
Author(s) C. Kaufman, P. Hoffman, Y. Nir, P. Eronen
Date 2010-09-01
RFC5996
Location http://www.ietf.org/rfc/rfc5996.txt
Elliptic Curves for Security
Author(s) A. Langley, M. Hamburg, S. Turner
Date 2016-01-01
RFC7748
Location http://www.ietf.org/rfc/rfc7748.txt
Simple Certificate Enrolment Protocol
Author(s) P. Gutmann
Date 2020-09-01
RFC8894
Location http://www.ietf.org/rfc/rfc8894.txt
Recommendation for Password-Based Key Derivation: Part 1: Storage
Applications
Date 2010-12-22
SP800-132
Location https://csrc.nist.gov/pubs/sp/800/132/final
Recommendation for Block Cipher Modes of Operation: Methods and
Techniques
Date 2001-12-01
SP800-38A
Location https://csrc.nist.gov/pubs/sp/800/38/a/final
Version: 1.1 Classification: Public Page 177 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Recommendation for Block Cipher Modes of Operation: the CCM Mode for
Authentication and Confidentiality
Date 2007-07-20
SP800-38C
Location https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode
(GCM) and GMAC
Date 2007-11-28
SP800-38D
Location https://csrc.nist.gov/pubs/sp/800/38/d/final
Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode
for Confidentiality on Storage Devices
Date 2010-01-18
SP800-38E
Location https://csrc.nist.gov/pubs/sp/800/38/e/final
Recommendation for Block Cipher Modes of Operation: Methods for Key
Wrapping
Date 2012-12-13
SP800-38F
Location https://csrc.nist.gov/pubs/sp/800/38/f/final
Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete
Logarithm Cryptography
Date 2018-04-16
SP800-56A-Rev3
Location https://csrc.nist.gov/pubs/sp/800/56/a/r3/final
Recommendation for Pair-Wise Key Establishment Schemes Using Integer
Factorization Cryptography
Date 2014-09
SP800-56B-Rev1
Location https://csrc.nist.gov/pubs/sp/800/56/b/r1/final
Recommendation for Key-Derivation Methods in Key-Establishment Schemes
Date 2020-08-18
SP800-56C-Rev2
Location https://csrc.nist.gov/pubs/sp/800/56/c/r2/final
Recommendation for Random Number Generation Using Deterministic
Random Bit Generators
Date 2015-06-24
SP800-90A-Rev1
Location https://csrc.nist.gov/pubs/sp/800/90/a/r1/final
Functional Package for Transport Layer Security (TLS)
Version 1.1 (PKG_TLS_V1.1)
Date 2019-03-01
TLSPKG
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439
List of available trusted root certificates in iOS 16, iPadOS 16, macOS 13,
tvOS 16, and watchOS 9
Date 2021-09-27
TRUST_STORE
Location https://support.apple.com/en-us/HT212773
PP-Module for Virtual Private Network (VPN) Clients
VPNC
Version 2.4 (MOD_VPNC_V2.4)
Version: 1.1 Classification: Public Page 178 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Date 2022-03-31
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=467&id=467
PP-Module for WLAN Clients
Version 1.0 (MOD_WLANC_V1.0)
Date 2022-03-31
WLANC
Location https://www.niap-ccevs.org/Profile/Info.cfm?PPID=463&id=463
Version: 1.1 Classification: Public Page 179 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
A Appendixes
A.1 Devices Covered by this Evaluation
This appendix lists the devices that are covered by this evaluation and provides the technical characteristics
of each device including the instruction set architecture a.k.a. microarchitecture.
The following shorthand expressions are used in this section.
BAF Biometric Authentication Factor Type
BT Bluetooth (version) (2400 MHz to 2483.5 MHz)
Core Wi-Fi/Bluetooth chip core
ISA Instruction Set Architecture
NFC Near Field Communication (13.56 MHz)
SAT Satellite (Emergency SOS via satellite) (Globalstar's L and S bands)
SoC System on a Chip
UWB Ultra-Wideband
Table 31: SoC to ISA mappings
SoC ISA
A11 Bionic ARMv8.2-A
A12 Bionic ARMv8.3-A
A13 Bionic ARMv8.4-A
A14 Bionic ARMv8.5-A
A15 Bionic
A16 Bionic
ARMv8.6-A
Table 32: iPhone: A11 Bionic (ARMv8.2-A) models
Device Info Model
No.
Cellular
A1863 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
iPhone 8
BAF: Touch ID (Gen.3)
BT: 5.0
NFC: Yes
SAT: No
SoC: A11 Bionic
UWB: No
Wi-Fi: 802.11 /a/b/g/n/ac
A1905 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 180 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1906
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
Core: 4357
A1907 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1864 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1897
(GSM)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1898
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
iPhone 8 Plus
BAF: Touch ID (Gen.3)
BT: 5.0
NFC: Yes
SAT: No
SoC: A11 Bionic
UWB: No
Wi-Fi: 802.11 /a/b/g/n/ac
Core: 4357
A1899 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1865
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone X
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A11 Bionic
UWB: No A1901 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
Version: 1.1 Classification: Public Page 181 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz))
Wi-Fi: 802.11 /a/b/g/n/ac
Core: 4357
A1902
(Japan)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 29, 30, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900, 2100 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Table 33: iPhone: A12 Bionic (ARMv8.3-A) models
Device Info Model
No.
Cellular
A1920
(US /
CA / HK)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2097 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2098
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28,
29, 30, 32, 66)
TD LTE bands 34, 38, 39, 40, 41, 42, and 46.
A2099
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66 and 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone XS
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A12 Bionic
UWB: No
Wi-Fi: 802.11 /a/b/g/n/ac
Core: 4377
A2100
(China)
FDD-LTE (1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32, 66,
71)
TD-LTE (34, 38, 39, 40, 41, 46)
TD-SCDMA 1900 (F), 2000 (A)
Version: 1.1 Classification: Public Page 182 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1921
(US/CA)
Dual SIM
(nano-
SIM and
eSIM)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2101
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2102
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28,
29, 30, and 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, and 46)
iPhone XS Max
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A12 Bionic
UWB: No
Wi-Fi: 802.11 /a/b/g/n/ac
Core: 4377
A2104
(China /
HK)
FDD-LTE (1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32, 66,
71)
TD-LTE (34, 38, 39, 40, 41, 46)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A1984
(US/CA)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone XR
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A12 Bionic
UWB: No
Wi-Fi: 802.11 /a/b/g/n/ac
Core: 4377
A2105
(Global)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Version: 1.1 Classification: Public Page 183 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
A2106
(Japan)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28,
29, 30, and 66)
TD LTE (Bands 34, 38, 39, 40, 41, and 42)
A2107
(US/CA)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66 and 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 46)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2108
(HK /
China)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 32,
66, and 71)
TD LTE (Bands 34, 38, 39, 40, and 41)
Table 34: iPhone: A13 Bionic (ARMv8.4-A) models
Device Info Model
No.
Cellular
A2111 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2221 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26, 28, 29,
30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 11
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A13 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
Core: 4378
A2223 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
TD-SCDMA 1900 (F), 2000 (A)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 11 Pro
BAF: Face ID (Gen.1)
BT: 5.0
A2160 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
Version: 1.1 Classification: Public Page 184 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2215 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26, 28, 29,
30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
NFC: Yes
SAT: No
SoC: A13 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
Core: 4378
A2217 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2161 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2218 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26, 28, 29,
30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 11 Pro Max
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A13 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
Core: 4378
A2220 FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone SE (2nd gen)
BAF: Touch ID (Gen.3)
BT: 5.0
NFC: Yes
A2275
(US/CA)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 185 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2296
(Global)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26, 28, 29,
30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV DO Rev. A (800, 1900 MHz) (Japan Only)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
SAT: No
SoC: A13 Bionic
UWB: No
Wi-Fi: Wi-Fi 6 (802.11ax)
Core: 4378
A2298
(China)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 29, 30, 66,
71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
TD SCDMA 1900 (F), 2000 (A); CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Table 35: iPhone: A14 Bionic (ARMv8.5-A) models
Device Info Model
No.
Cellular
A2176 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 12 mini
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A14 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2398 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 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+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 186 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2399 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz); UMTS/HSPA+/DC HSDPA (850, 900,
1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2400 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2172 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 12
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A14 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2402 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 12, 13, 14, 17, 18, 19, 20, 21, 25, 26, 28, 29,
30, 32, 66, 71)
Version: 1.1 Classification: Public Page 187 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2403 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48); CDMA EV-DO Rev. A (800,
1900 MHz)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2404 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2341 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 12 Pro
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A14 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2406 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n71, n77, n78, n79)
Version: 1.1 Classification: Public Page 188 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 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+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2407 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2408 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz); UMTS/HSPA+/DC HSDPA (850, 900,
1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2342 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 12 Pro Max
BAF: Face ID (Gen.1)
BT: 5.0
NFC: Yes
SAT: No
SoC: A14 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2410 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
Version: 1.1 Classification: Public Page 189 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
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, 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+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2411 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz); UMTS/HSPA+/DC HSDPA (850, 900,
1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2412 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
CDMA EV-DO Rev. A (800, 1900 MHz); UMTS/HSPA+/DC HSDPA (850, 900,
1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Table 36: iPhone: A15 Bionic (ARMv8.6-A) models
Device Info Model
No.
Cellular
iPhone 13 mini
BAF: Face ID (Gen.2)
BT: 5.0
NFC: Yes
SAT: No
SoC: A15 Bionic
UWB: 6GHz – 8.5GHz
A2481 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, 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)
Version: 1.1 Classification: Public Page 190 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2626 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2628 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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)
A2629 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2630 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48); UMTS/HSPA+/DC-HSDPA
(850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 191 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2482 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2631 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2633 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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)
iPhone 13
BAF: Face ID (Gen.2)
BT: 5.0
NFC: Yes
SAT: No
SoC: A15 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2634 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
Version: 1.1 Classification: Public Page 192 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2635 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2483 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2636 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 13 Pro
BAF: Face ID (Gen.2)
BT: 5.0
NFC: Yes
SAT: No
SoC: A15 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2638 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n38, n40, n41, n66,
n71, n77, n78, n79)
Version: 1.1 Classification: Public Page 193 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
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)
A2639 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2640 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2484 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, 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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 13 Pro Max
BAF: Face ID (Gen.2)
BT: 5.0
NFC: Yes
SAT: No
SoC: A15 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2641 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
Version: 1.1 Classification: Public Page 194 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
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)
CDMA EV DO Rev. A (800, 1900 MHz)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2643 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
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)
A2644 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2645 5G (sub-6 GHz and mmWave) with 4x4 MIMO
Gigabit LTE with 4x4 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone SE (3rd gen)
BAF: Touch ID (Gen.4)
BT: 5.0
NFC: Yes
SAT: No
A2595 5G (sub-6 GHz) with 2x2 MIMO
LTE Advanced with 2x2 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
Version: 1.1 Classification: Public Page 195 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2782 5G (sub-6 GHz) with 2x2 MIMO
LTE Advanced with 2x2 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 11, 12, 13, 17, 18, 19, 20, 21, 25, 26, 28, 30,
32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2783 5G (sub-6 GHz) with 2x2 MIMO
LTE Advanced with 2x2 MIMO and LAA
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)
SoC: A15 Bionic
UWB: No
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2785 5G (sub-6 GHz) with 2x2 MIMO
LTE Advanced with 2x2 MIMO and LAA
5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n30, n38, n40, n41,
n48, n66, n77, n78, n79)
FDD LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 14
BAF: Face ID (Gen.2)
BT: 5.3
NFC: Yes
SAT: Yes
SoC: A15 Bionic
UWB: 6GHz – 8.5GHz
A2649 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, n260, n261)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Version: 1.1 Classification: Public Page 196 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2881 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2882 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n14, n20, n25, n26, n28, n29, n30,
n38, n40, n41, n48, n53, n66, n70, 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, 53); UMTS/HSPA+/DC-HSDPA
(850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2883 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2884 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 14 Plus
BAF: Face ID (Gen.2)
BT: 5.3
NFC: Yes
SAT: Yes
SoC: A15 Bionic
A2632 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, n260, n261)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 197 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2885 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2886 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n14, n20, n25, n26, n28, n29, n30,
n38, n40, n41, n48, n53, n66, n70, 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, 53); UMTS/HSPA+/DC-HSDPA
(850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz
A2887 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2888 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Table 37: iPhone: A16 Bionic (ARMv8.6-A) models
Device Info Model
No.
Cellular
iPhone 14 Pro A2650 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
Version: 1.1 Classification: Public Page 198 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
5G NR mmWave (Bands n258, n260, n261)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2889 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2890 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n14, n20, n25, n26, n28, n29, n30,
n38, n40, n41, n48, n53, n66, n70, 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, 53); UMTS/HSPA+/DC-HSDPA
(850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
A2891 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
BAF: Face ID (Gen.2)
BT: 5.3
NFC: Yes
SAT: Yes
SoC: A16 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2892 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
Version: 1.1 Classification: Public Page 199 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
A2651 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
5G NR mmWave (Bands n258, n260, n261)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2893 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n29, n30, n38, n40,
n41, n48, n66, n71, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30,
32, 66, 71)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
5G (sub-6 GHz and mmWave) with 4x4 MIMO
5G, Gigabit-class LTE with 4x4 MIMO and LAA
A2894 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n14, n20, n25, n26, n28, n29, n30,
n38, n40, n41, n48, n53, n66, n70, 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, 53); UMTS/HSPA+/DC-HSDPA
(850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz
A2895 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
GSM/EDGE (850, 900, 1800, 1900 MHz)
iPhone 14 Pro Max
BAF: Face ID (Gen.2)
BT: 5.3
NFC: Yes
SAT: Yes
SoC: A16 Bionic
UWB: 6GHz – 8.5GHz
Wi-Fi: Wi-Fi 6 (802.11ax)
with 2.2 MIMO
Core: 4387
A2896 5G NR (Bands n1, n2, n3, n5, n7, n8, n12, n20, n25, n26, n28, n30, n38, n40,
n41, n48, n66, n70, n77, n78, n79)
FDD-LTE (Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 30, 32, 66)
TD-LTE (Bands 34, 38, 39, 40, 41, 42, 46, 48)
UMTS/HSPA+/DC-HSDPA (850, 900, 1700/2100, 1900, 2100 MHz)
Version: 1.1 Classification: Public Page 200 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
Device Info Model
No.
Cellular
GSM/EDGE (850, 900, 1800, 1900 MHz)
Version: 1.1 Classification: Public Page 201 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
A.2 Wi-Fi Alliance Certificates
The following table lists the Wi-Fi Alliance certificates for the devices covered by this evaluation.
Table 38: iPhone: Wi-Fi Alliance certificates
SoC Device Name Model No. Wi-Fi Alliance
A1863
A1906
A1907
iPhone 8
A1905
WFA72374 / WFA72354
A1864
A1898
A1899
iPhone 8 Plus
A1897
WFA72375 / WFA72355
A1865
A1902
A11 Bionic
iPhone X
A1901
WFA72376 / WFA72356
A1920
A2097
A2098
A2099
iPhone XS
A2100
WFA77787
A1921
A2101
A2102
iPhone XS Max
A2104
WFA78758
A1984
A2105
A2106
A2107
A12 Bionic
iPhone XR
A2108
WFA77788
A2111
A2221
iPhone 11
A2223
WFA90122 / WFA90123
A13 Bionic
iPhone 11 Pro A2160 WFA91330 / WFA91331
Version: 1.1 Classification: Public Page 202 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SoC Device Name Model No. Wi-Fi Alliance
A2215
A2217
A2161
A2218
iPhone 11 Pro Max
A2220
WFA91332 / WFA91333
A2275
A2296
iPhone SE
(2nd gen)
A2298
WFA96502 / WFA96560
A2176
A2398
A2399
iPhone 12 mini
A2400
WFA101651 / WFA101652
A2172
A2402
A2403
iPhone 12
A2404
WFA98093 / WFA98094
A2341
A2406
A2407
iPhone 12 Pro
A2408
WFA101653 / WFA101654
A2342
A2410
A2411
A14 Bionic
iPhone 12 Pro Max
A2412
WFA101655 / WFA101656
A2481 WFA112066
A2626 WFA112066
A2628 WFA113723
A2629 WFA113724
iPhone 13 mini
A2630 WFA113724
A2482 WFA113788
A2631 WFA113788
A2633 WFA113789
A15 Bionic
iPhone 13
A2634 WFA113790
Version: 1.1 Classification: Public Page 203 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SoC Device Name Model No. Wi-Fi Alliance
A2635 WFA113789
A2483 WFA113782
A2636 WFA113782
A2638 WFA113783
A2639 WFA113784
iPhone 13 Pro
A2640 WFA113783
A2484 WFA113785
A2641 WFA113785
A2643 WFA113786
A2644 WFA113787
iPhone 13 Pro Max
A2645 WFA113786
A2595 WFA118096
A2782 WFA118096
A2783 WFA118097
iPhone SE
(3rd gen)
A2785 WFA118098
A2649 WFA120039
A2881 WFA120039
A2882 WFA120851
A2883 WFA120851
iPhone 14
A2884 WFA120583
A2632 WFA120860
A2885 WFA120860
A2886 WFA120861
A2887 WFA120861
iPhone 14 Plus
A2888 WFA120862
A2650 WFA120854
A2889 WFA120854
A2890 WFA120855
A2891 WFA120855
iPhone 14 Pro
A2892 WFA120856
A2651 WFA120857
A2893 WFA120857
A16 Bionic
iPhone 14 Pro Max
A2894 WFA120859
Version: 1.1 Classification: Public Page 204 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SoC Device Name Model No. Wi-Fi Alliance
A2895 WFA120858
A2896 WFA120859
A.3 SFR to CAVP certificate mappings
This appendix maps the SFRs to the CAVP certificates.
The CAVP certificates contain several different SoCs in the operational environment (OE). The SoCs used by
the TOE are specified in Table 31.
CAVP Module Implementation Names
Below are the CAVP module (Mod) implementation names of the implementations used in Table 39.
USR
The user space software module implementation names for v13.0 are:
1. Apple corecrypto Module [Apple ARM, User, Software, SL1] (asm_arm)
2. Apple corecrypto Module [Apple ARM, User, Software, SL1] (c_asm)
3. Apple corecrypto Module [Apple ARM, User, Software, SL1] (c_ltc)
4. Apple corecrypto Module [Apple ARM, User, Software, SL1] (vng_asm)
5. Apple corecrypto Module [Apple ARM, User, Software, SL1] (vng_ltc)
6. Apple corecrypto Module [Apple ARM, User, Software, SL1] (vng_neon)
KRN
The kernel space software module names for v13.0 are:
1. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (asm_arm)
2. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (c_asm)
3. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (c_ltc)
4. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (vng_asm)
5. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (vng_ltc)
6. Apple corecrypto Module [Apple ARM, Kernel, Software, SL1] (vng_neon)
SKS-FW
The secure key store (SKS) firmware module implementation names for v13.0 are:
1. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (asm_arm)
2. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (c_asm)
3. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (c_ltc)
4. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (vng_asm)
5. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (vng_ltc)
6. Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (vng_neon)
SKS-HW
The secure key store (SKS) hardware module implementation names for v2.0 are:
1. A11 Bionic:
● Apple Secure Enclave Processor Hardware DRBG (Apple A11)
● Apple Secure Enclave Processor Hardware SKG (A11 Bionic)
2. A12 Bionic:
● Apple Secure Enclave Processor Hardware DRBG (A12 Bionic)
Version: 1.1 Classification: Public Page 205 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Apple Secure Enclave Processor Hardware SKG (A12 Bionic)
3. A13 Bionic:
● Apple Secure Key Store CoreCrypto Module Hardware (trng)
● Apple Secure Key Store CoreCrypto Module Hardware (skg)
4. A14 Bionic:
● Apple corecrypto Module [Apple silicon, Secure Key Store, Hardware] (trng)
● Apple corecrypto Module [Apple silicon, Secure Key Store, Hardware] (skg)
5. A15 Bionic:
● Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (trng)
● Apple corecrypto Module [Apple ARM, Secure Key Store, Hardware, SL2] (skg)
6. A16 Bionic:
● Apple corecrypto Module [Apple silicon, Secure Key Store, Hardware, SL2] (trng)
● Apple corecrypto Module [Apple silicon, Secure Key Store, Hardware, SL2] (skg)
BC
The Broadcom core hardware module implementation names are:
1. 4357:
● Cryptographic Hardware Module
2. 4377:
● Cryptographic Hardware Module
3. 4378 Aux (2.4 GHz):
● Crypto Hardware Module aes_core_gcm.vhd
4. 4378 Main (5 GHz):
● Crypto Hardware Module aes_core_gcm_simult_enc_mic.vhd
5. 4387 Aux (2.4 GHz):
● Crypto Hardware Module aes_core_gcm.vhd
6. 4387 Main (5 GHz):
● Crypto Hardware Module aes_core_gcm_simult_enc_mic.vhd
CAVP Operational Environments (OEs)
The CAVP OEs for USR, KRN, and SKS-FW are:
1. iOS 16 on Apple A Series (ARMv8.2-A) A11 Bionic
2. iOS 16 on Apple A Series (ARMv8.3-A) A12 Bionic
3. iOS 16 on Apple A Series (ARMv8.4-A) A13 Bionic
4. iOS 16 on Apple A Series (ARMv8.5-A) A14 Bionic
5. iOS 16 on Apple A Series (ARMv8.6-A) A15 Bionic
6. iOS 16 on Apple A Series (ARMv8.6-A) A16 Bionic
The CAVP OEs for SKS-HW are:
1. A11 Bionic:
● Apple Secure Enclave Processor Hardware DRBG (Apple A11)
● Apple Secure Enclave Processor Hardware SKG (A11 Bionic)
2. A12 Bionic:
Version: 1.1 Classification: Public Page 206 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
● Apple Secure Enclave Processor Hardware DRBG (A12 Bionic)
● Apple Secure Enclave Processor Hardware SKG (A12 Bionic)
3. A13 Bionic:
● Apple A Series A13 Bionic
4. A14 Bionic:
● Apple A Series A14 Bionic
5. A15 Bionic:
● Apple A Series A15 Bionic
6. A16 Bionic:
● Apple A Series (ARMv8.6-A) A16 Bionic
The CAVP OEs for BC are:
1. 4357:
● Cryptographic Hardware Module
2. 4377:
● Cryptographic Hardware Module
3. 4378 Aux (2.4 GHz):
● Crypto Hardware Module aes_core_gcm.vhd
4. 4378 (5 Ghz):
● Crypto Hardware Module aes_core_gcm_simult_enc_mic.vhd
5. 4387 Aux (2.4 GHz):
● Crypto Hardware Module aes_core_gcm.vhd
6. 4387 Aux (5 GHz):
● Crypto Hardware Module aes_core_gcm_simult_enc_mic.vhd
CAVP Mapping Table
Table 39: SFRs to CAVP certificates for iPhones
SFR Algorithm Modes / Other Mod Implementation CAVP
USR vng_ltc A3428
KRN vng_ltc A3686
ECDSA KeyGen and
KeyVer
[FIPS186-4]☝
P-256, P-384
SKS-FW vng_ltc A4109
FCS_CKM.1
Safe Primes KeyGen
[SP800-56A-Rev3]☝
MODP-2048,
MODP-3072
USR c_ltc A3426
FCS_CKM.1/VPN ECDSA KeyGen and
KeyVer
[FIPS186-4]☝
P-256, P-384 USR vng_ltc A3428
USR c_ltc A3426
FCS_CKM.2/
UNLOCKED
ECC Key
Establishment
(KAS-ECC-SSC
Sp800-56Ar3)
P-256, P-384
SKS-FW c_ltc A4106
Version: 1.1 Classification: Public Page 207 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Algorithm Modes / Other Mod Implementation CAVP
[SP800-56A-Rev3]☝
FFC Key
Establishment
(KAS-FFC-SSC
Sp800-56Ar3)
[SP800-56A-Rev3]☝
MODP-2048,
MODP-3072
USR c_ltc A3426
RSA Key
Establishment
[SP800-56B-Rev1]☝
2048, 3072, 4096 USR c_ltc Vendor
Affirmation
as per PL#5
Add2 v2.0
USR asm_arm A3423
KRN asm_arm A3682
CBC
128-bit, 256-bit
encrypt, decrypt
[SP800-38A]☝ (CBC)
SKS-FW asm_arm A4103
A11 Bionic (skg) C319
A12 Bionic (skg) C320
A13 Bionic (skg) A510
A14 Bionic (skg) A1469
A15 Bionic (skg) A2863
CBC
128-bit, 256-bit
encrypt only
[SP800-38A]☝ (CBC)
SKS-HW
A16 Bionic (skg) A3496
USR vng_asm A3427
KRN vng_asm A3685
SKS-FW vng_asm A4108
4357 AES 4152
4377 AES 4791
4378 Aux AES 5926
4378 Main AES 5927
4387 Aux AES 5926
CCM
128-bit
[SP800-38C]☝ (CCM)
BC
4387 Main AES 5927
USR vng_asm A3427
KRN vng_asm A3685
SKS-FW vng_asm A4108
4378 Aux AES 5952
4378 Main AES 5953
FCS_COP.1/
ENCRYPT
AES
[FIPS197]☝
CCM
256-bit
[SP800-38C]☝ (CCM)
BC
4387 Aux AES 5952
Version: 1.1 Classification: Public Page 208 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Algorithm Modes / Other Mod Implementation CAVP
4387 Main AES 5953
USR vng_asm A3427
KRN vng_asm A3685
SKS-FW vng_asm A4108
4357 AES 4152
4377 AES 4791
4378 Aux AES 5926
4378 Main AES 5927
4387 Aux AES 5926
GCM
128-bit
encrypt, decrypt
[SP800-38D]☝ (GCM) BC
4387 Main AES 5927
USR vng_asm A3427
KRN vng_asm A3685
SKS-FW vng_asm A4108
4378 Aux AES 5926
4378 Main AES 5927
4387 Aux AES 5926
GCM
256-bit
encrypt, decrypt
[SP800-38D]☝ (GCM) BC
4387 Main AES 5927
USR c_asm A3424
KRN c_asm A3683
KW
128-bit, 256-bit
encrypt, decrypt
[SP800-38F]☝ (KW)
SKS-FW c_asm A4104
USR asm_arm A3423
KRN asm_arm A3682
XTS
128-bit, 256-bit
encrypt, decrypt
[SP800-38E]☝ (XTS)
SKS-FW asm_arm A4103
USR vng_neon A3429
KRN vng_neon A3687
SHA2-256
SKS-FW vng_neon A4110
USR vng_ltc A3428
KRN vng_ltc A3686
FCS_COP.1/HASH SHS
Byte-oriented mode
[FIPS180-4]☝
SHA-1, SHA2-384,
SHA2-512
SKS-FW vng_ltc A4109
USR vng_ltc A3428
FCS_COP.1/SIGN RSA SigGen
PKCS 1.5 and
PKCSPSS
Modulo:
2048, 3072, 4096
KRN vng_ltc A3686
Version: 1.1 Classification: Public Page 209 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
SFR Algorithm Modes / Other Mod Implementation CAVP
[FIPS186-4]☝
using
SHA2-256, SHA2-384,
SHA2-512
USR vng_ltc A3428
RSA SigVer
PKCS 1.5 and
PKCSPSS
[FIPS186-4]☝
Modulo:
2048, 3072, 4096
using
SHA-1, SHA2-256,
SHA2-384, SHA2-512
KRN vng_ltc A3686
USR vng_ltc A3428
KRN vng_ltc A3686
ECDSA SigGen
[FIPS186-4]☝
P-256, P-384, P-521
using
SHA2-256, SHA2-384,
SHA2-512
SKS-FW vng_ltc A4109
USR vng_ltc A3428
KRN vng_ltc A3686
ECDSA SigVer
[FIPS186-4]☝
P-256, P-384, P-521
using
SHA-1, SHA2-256,
SHA2-384, SHA2-512
SKS-FW vng_ltc A4109
USR vng_neon A3429
KRN vng_neon A3687
HMAC-SHA2-256
SKS-FW vng_neon A4110
USR vng_ltc A3428
KRN vng_ltc A3686
FCS_COP.1/
KEYHMAC
HMAC
Byte-oriented mode
[FIPS198-1]☝
HMAC-SHA-1,
HMAC-SHA2-384,
HMAC-SHA2-512
SKS-FW vng_ltc A4109
A11 Bionic DRBG 2014
A12 Bionic C323
A13 Bionic (trng) A501
A14 Bionic (trng) A1362
A15 Bionic (trng) A2864
FCS_RBG_EXT.1/HW CTR_DRBG(AES)
[SP800-90A-Rev1]☝
AES-256 SKS-HW
A16 Bionic (trng) A3490
USR vng_asm A3427
FCS_RBG_EXT.1/SW CTR_DRBG(AES)
[SP800-90A-Rev1]☝
AES-256
KRN vng_asm A3685
CAVP Mapping of Broadcom Cores
Table 40 maps iPhones to Broadcom cores and Broadcom CAVP certificates.
Table 40: Broadcom core supported algorithms and CAVP certificates for iPhones
iPhone Broadcom Core #
(Version)
Supported
Algorithms
CAVP
iPhone 8 (A11 Bionic) 4357 AES-CCM-128 AES 4152
Version: 1.1 Classification: Public Page 210 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
iPhone Broadcom Core #
(Version)
Supported
Algorithms
CAVP
iPhone 8 Plus (A11 Bionic)
iPhone X (A11 Bionic)
(aes_core_gcm.vhd rev 2) AES-GCM-128
iPhone Xs (A12 Bionic)
iPhone Xs Max (A12 Bionic)
iPhone XR (A12 Bionic)
4377
(aes_core_gcm.vhd rev 4)
AES-CCM-128
AES-GCM-128
AES 4791
AES-CCM-128
AES-GCM-128
AES-GCM-256
AES 5926
4378 Aux (2.4 GHz)
(aes_core_gcm.vhd rev 6)
AES-CCM-256 AES 5952
AES-CCM-128
AES-GCM-128
AES-GCM-256
AES 5927
iPhone 11 (A13 Bionic)
iPhone 11 Pro (A13 Bionic)
iPhone 11 Pro Max (A13 Bionic)
iPhone SE (2nd gen) (A13 Bionic)
4378 Main (5 GHz)
(aes_core_gcm_simult_
enc_mic.vhd rev 6)
AES-CCM-256 AES 5953
AES-CCM-128
AES-GCM-128
AES-GCM-256
AES 5926
4387 Aux (2.4 GHz)
(aes_core_gcm.vhd rev 6)
AES-CCM-256 AES 5952
AES-CCM-128
AES-GCM-128
AES-GCM-256
AES 5927
iPhone 12 mini (A14 Bionic)
iPhone 12 (A14 Bionic)
iPhone 12 Pro (A14 Bionic)
iPhone 12 Pro Max (A14 Bionic)
iPhone 13 mini (A15 Bionic)
iPhone 13 (A15 Bionic)
iPhone 13 Pro (A15 Bionic)
iPhone 13 Pro Max (A15 Bionic)
iPhone SE (3rd gen) (A15 Bionic)
iPhone 14 (A15 Bionic)
iPhone 14 Plus (A15 Bionic)
iPhone 14 Pro (A16 Bionic)
iPhone 14 Pro Max (A16 Bionic)
4387 Main (5 GHz)
(aes_core_gcm_simult_
enc_mic.vhd rev 6)
AES-CCM-256 AES 5953
Version: 1.1 Classification: Public Page 211 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.
Apple iOS 16: iPhone
Security Target
VID11349
A.4 Inventory of TSF Binaries and Libraries
The list in this appendix 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.
Version: 1.1 Classification: Public Page 212 of 212
Last update: 2023-09-26 Copyright ©2023 Apple Inc.