Before fully booting into iOS, there is low-level code that runs from the Boot ROM. Its task is to verify that the Low-Level Bootloader is signed by the Apple RootCA public key before running it. This process is to ensure that no malicious or otherwise unauthorized software can be run on an iOS device. After the Low-Level Bootloader finishes its tasks, it runs the higher level bootloader, known as iBoot. If all goes well, iBoot will then proceed to load the iOS kernel as well as the rest of the operating system.[1]
Secure Enclave
The Secure Enclave is a coprocessor found in iOS devices part of the A7 and newer chips used for data protection. It includes the user data pertaining to Touch ID, Face ID, and Apple Pay, among other sensitive data.[2] The purpose of the Secure Enclave is to handle keys and other info such as biometrics that is sensitive enough to not be handled by the Application Processor (AP). It is isolated with a hardware filter so the AP cannot access it.[2] It shares RAM with the AP, but its portion of the RAM (known as TZ0) is encrypted. The secure enclave itself is a flashable 4 MB AKF processor core called the secure enclave processor (SEP) as documented in Apple Patent Application 20130308838. The technology used is similar to ARM's TrustZone/SecurCore but contains proprietary code for Apple KF cores in general and SEP specifically. It is also responsible for generating the UID key on A9 or newer chips that protects user data at rest.[citation needed]
It has its own secure boot process to ensure that it is completely secure. A hardware random number generator is also included as a part of this coprocessor. Each device's Secure Enclave has a unique ID that is fused into the SoC at manufacturing time and cannot be changed. Starting with A9 devices, the unique ID is generated by the Secure Enclave's random number generator and is never exposed outside of the device. This identifier is used to create a temporary key that encrypts the memory in this portion of the system. The Secure Enclave also contains an anti-replay counter to prevent brute force attacks.[1]
The SEP is located in the devicetree under IODeviceTree:/arm-io/sep and managed by the AppleSEPManager driver.[3]
In 2020, security flaws in the SEP were discovered, causing concerns about Apple devices such as iPhones.[4]
iOS devices can have a passcode that is used to unlock the device, make changes to system settings, and encrypt the device's contents. Until recently, these were typically four numerical digits long. However, since unlocking the devices with a fingerprint by using Touch ID has become more widespread, six-digit passcodes are now the default on iOS with the option to switch back to four or use an alphanumeric passcode.[1]
Touch ID is a fingerprint scanner that is embedded in the home button and can be used to unlock the device, make purchases, and log into applications among other functions. When used, Touch ID only temporarily stores the fingerprint data in encrypted memory in the Secure Enclave, as described above. Like Face ID, there is no way for the device's main processor or any other part of the system to access the raw fingerprint data that is obtained from the Touch ID sensor.[1]
Address Space Layout Randomization (ASLR) is a low-level technique of preventing memory corruption attacks such as buffer overflows. It involves placing data in randomly selected locations in memory in order to make it more difficult to predict ways to corrupt the system and create exploits. ASLR makes app bugs more likely to crash the app than to silently overwrite memory, regardless of whether the behavior is accidental or malicious.[citation needed]
As mentioned above, one use of encryption in iOS is in the memory of the Secure Enclave. When a passcode is utilized on an iOS device, the contents of the device are encrypted. This is done by using a hardware AES 256 implementation that is very efficient because it is placed directly between the flash storage and RAM.[1]
iOS, in combination with its specific hardware, uses crypto-shredding when erasing all content and settings by obliterating all the keys in 'effaceable storage'. This renders all user data on the device cryptographically inaccessible.[6]
The iOS keychain is a database of login information that can be shared across apps written by the same person or organization.[1] This service is often used for storing passwords for web applications.[7]
App security
Third-party applications such as those distributed through the App Store must be code signed with an Apple-issued certificate. In principle, this continues the chain of trust all the way from the Secure Boot process as mentioned above to the actions of the applications installed on the device by users. Applications are also sandboxed, meaning that they can only modify the data within their individual home directory unless explicitly given permission to do otherwise. For example, they cannot access data owned by other user-installed applications on the device. There is a very extensive set of privacy controls contained within iOS with options to control apps' ability to access a wide variety of permissions such as the camera, contacts, background app refresh, cellular data, and access to other data and services. Most of the code in iOS, including third-party applications, runs as the "mobile" user which does not have root privileges. This ensures that system files and other iOS system resources remain hidden and inaccessible to user-installed applications.[1]
App Store bypasses
Companies can apply to Apple for enterprise developer certificates. These can be used to sign apps such that iOS will install them directly (sometimes called "sideloading"), without the app needing to be distributed via the App Store.[8] The terms under which they are granted make clear that they are only to be used for companies who wish to distribute apps directly to their employees.[8]
Circa January–February 2019, it emerged that a number of software developers were misusing enterprise developer certificates to distribute software directly to non-employees, thereby bypassing the App Store. Facebook was found to be abusing an Apple enterprise developer certificate to distribute an application to underage users that would give Facebook access to all private data on their devices.[9][10][11]Google was abusing an Apple enterprise developer certificate to distribute an app to adults to collect data from their devices, including unencrypted data belonging to third parties.[12][8]AltStore, AppValley, Panda Helper, TweakBox and TutuApp have all been abusing enterprise developer certificates to distribute apps that offer pirated software.[13]
Network security
iOS supports TLS with both low- and high-level APIs for developers. By default, the App Transport Security (ATS) framework requires that servers use at least TLS 1.2. However, developers are free to override this framework and utilize their own methods of communicating over networks. When Wi-Fi is enabled, iOS uses a randomized MAC address so that devices cannot be tracked by anyone sniffing wireless traffic.[1]
Two-factor authentication is an option in iOS to ensure that even if an unauthorized person knows an Apple ID and password combination, they cannot gain access to the account. It works by requiring not only the Apple ID and password, but also a verification code that is sent to an iDevice or mobile phone number that is already known to be trusted.[1] If an unauthorized user attempts to sign in using another user's Apple ID, the owner of the Apple ID receives a notification that allows them to deny access to the unrecognized device.[14]
Hardened memory allocation
iOS features a hardened memory allocator known as kalloc_type that was introduced in iOS 15. Since the XNU kernel is primarily written in memory unsafe languages such as C and C++,[15]kalloc_type is designed to mitigate the large amount of vulnerabilities that result from the use of these languages in the kernel. In order to achieve this, kalloc_type implements mitigations such as type isolation in order to prevent type confusion and buffer overflow vulnerabilities. Ultimately, the prevention of privilege escalation is intended.[16]
